Wie behebe ich den Paketverlust in meiner VPN-Verbindung?
Bei meiner VPN-Verbindung treten kontinuierliche oder zeitweilige Paketverluste und Probleme mit hoher Latenz auf.
Lösung
Auslastung der Ressourcen überprüfen
Eine hohe CPU-, Speicher- oder Netzwerkbandbreitennutzung trägt zum Paketverlust bei. Überwache die Amazon CloudWatch.Metriken CPUUtilization, NetworkIn, NetworkOut, NetworkPacketsIn und NetworkPacketsOut. Überprüfe die Ressourcenauslastung sowohl auf den Quell- als auch auf den Zielhosts.
Nach Netzwerkproblemen suchen
Installiere das mtr-Netzwerktool auf dem On-Premises-Computer, um nach ICMP- oder TCP-Paketverlust oder Latenz zu suchen. Installiere mtr auch auf einer Amazon Elastic Compute Cloud (Amazon EC2)-Instance.
Führe für Amazon Linux den folgenden Befehl aus:
sudo yum install mtr
Führe für Ubuntu den folgenden Befehl aus:
sudo apt-get install mtr
Verwende für Windows WinMTR von SourceForge.
Hinweis: WinMTR unterstützt keine TCP-basierte MTR.
Prüfe, ob im AWS VPN-Tunnel ein Paketverlust vorliegt. Teste die Verbindung vom On-Premises-Host, der den Tunnel verwendet, zur privaten IP-Adresse deiner Amazon EC2-Instance. Teste außerdem die Verbindung vom On-Premises-Kunden-Gateway zur öffentlichen IP-Adresse jedes Tunnels. Wenn du mtr auf deinem Kunden-Gateway-Gerät nicht verwenden kannst, verwende einen Host mit derselben Internetverbindung wie das Kunden-Gateway-Gerät.
Wichtig: Rufe mtr-Ergebnisse in beide Richtungen ab. Der Pfad zwischen Knoten in einem TCP- und IP-Adressnetzwerk kann sich ändern, wenn du die Richtung umkehrst.
Führe den folgenden Test auf einer privaten IP-Adresse mit ICMP aus:
mtr -b -c 50 -rw Host_Instance_Private_IP
Führe den folgenden Test auf einer privaten IP-Adresse mit TCP aus:
mtr -b -c 50 -rw -T -P 443 Host_Instance_Private_IP
Hinweis: Ersetze in den vorherigen Befehlen Host_instance_private_IP durch die private IP-Adresse deiner EC2-Instance oder deines On-Premises-Hosts und 443 durch deinen Port.
Führe den folgenden Test auf einer öffentlichen IP-Adresse mit ICMP aus:
mtr -b -c 50 -rw AWS_Tunnel_Public_IP
Führe die folgenden Tests auf einer öffentlichen IP-Adresse mit UDP aus:
mtr -b -c 50 -rw -u -P 500 AWS_Tunnel_Public_IP
mtr -b -c 50 -rw -u -P 4500 AWS_Tunnel_Public_IP
Hinweis: Ersetze in den vorherigen Befehlen AWS_Tunnel_Public_IP durch die öffentliche IP-Adresse des Tunnels und 500 und 4500 durch deine UDP-Ports.
Paketverlust und erhöhte Round-Trip-Zeit (RTT) bei einem einzelnen Hop werden erwartet. Paketverlust und eine erhöhte RTT sind nur dann ein Problem, wenn du sie bei jedem Hop siehst. Die folgende Beispielausgabe zeigt einen konsistenten Verlust, der bei Hop 3 beginnt und bis zum letzten Hop andauert:
HOST: localhost Loss% Snt Last Avg Best Wrst StDev 1. 63.247.74.43 0.0% 10 0.3 0.6 0.3 1.2 0.3 2. 63.247.64.157 0.0% 10 0.4 1.0 0.4 6.1 1.8 3. 209.51.130.213 60.0% 10 0.8 2.7 0.8 19.0 5.7 4. aix.pr1.atl.google.com 60.0% 10 6.7 6.8 6.7 6.9 0.1 5. 72.14.233.56 50.0% 10 7.2 8.3 7.1 16.4 2.9 6. 209.85.254.247 40.0% 10 39.1 39.4 39.1 39.7 0.2 7. 64.233.174.46 40.0% 10 39.6 40.4 39.4 46.9 2.3 8. gw-in-f147.1e100.net 40.0% 10 39.6 40.5 39.5 46.7 2.2
Das folgende Beispiel zeigt einen Test der öffentlichen IP-Adresse eines Tunnels, der den UDP-Port 500 verwendet. Zwischen den Hops 1 und 4 zeigt die Spalte Loss% einen prozentualen Verlust an. Da es jedoch keinen Paketverlust zwischen den Hops 5 und 13 gibt, gilt dieser Verlust nicht als erheblicher Paketverlust. Der Verlust zwischen Hop 14 und dem letzten Hop weist einen erheblichen Paketverlust auf, da es sich um einen anhaltenden Verlust handelt, der zu einem Verlust von 100 % führt. Das Problem in diesem Beispiel tritt auf Hop 14 auf.
sudo mtr -b -c 30 -rw -u -P 500 185.156.137.215 Start: 2024-08-28T18:59:49+0000 HOST: ip-10-100-20-25 Loss% Snt Last Avg Best Wrst StDev 1. |-- ??? 100.0 30 0.0 0.0 0.0 0.0 0.0 2. |-- 240.1.84.6 73.3% 30 0.5 0.5 0.5 0.5 0.0 3. |-- 242.3.160.33 63.3% 30 1.4 1.0 0.6 1.4 0.3 4. |-- 241.0.6.67 63.3% 30 0.5 6.7 0.5 12.4 5.9 5. |-- 100.100.6.39 0.0% 30 0.5 3.1 0.5 27.7 6.2 6. |-- 100.100.72.6 0.0% 30 1.1 9.9 0.5 96.0 17.6 7. |-- 100.91.209.81 0.0% 30 11.5 20.6 11.1 127.3 24.3 8. |-- 100.100.6.107 0.0% 30 12.8 19.9 11.6 127.8 22.6 9. |-- 99.83.70.223 0.0% 30 12.3 18.1 11.7 117.0 19.2 10.|-- 100.100.92.209 0.0% 30 11.9 13.7 11.6 50.6 7.0 11.|-- 100.100.16.88 0.0% 30 13.2 14.0 11.9 33.1 3.8 12.|-- gw-as249.retn.net (87.245.240.41) 0.0% 30 13.2 13.2 11.8 19.9 1.5 13.|-- thw.sw01.loudltd.net (185.156.136.14) 0.0% 30 11.4 12.5 11.4 14.2 1.0 14.|-- no-ptr.pckear.com (185.116.108.124) 20.0% 30 14.8 13.2 12.5 14.8 0.5 15.|-- thw.sw01.loudltd.net (185.156.136.14) 40.0% 30 14.1 13.6 12.5 15.5 0.8 16.|-- thw.sw01.loudltd.net (185.156.136.14) 40.0% 30 16.5 14.5 13.3 16.5 0.8 17.|-- ??? 100.0% 30 0.0 0.0 0.0 0.0 0.0
Suche nach Latenz- und Routing-Problemen
Das traceroute-Tool zeigt dir den Pfad, den Daten durch das Netzwerk nehmen. Verwende diese Informationen, um festzustellen, wo Verzögerungen auftreten.
Führe den folgenden Befehl aus, um traceroute auf Amazon Linux zu installieren:
sudo yum install traceroute
Führe den folgenden Befehl aus, um traceroute auf Ubuntu zu installieren:
sudo apt-get install traceroute
Verwende für Windows anstelle von traceroute das tracert-Tool. Dieses Tool ist standardmäßig auf allen Windows-Computern installiert. Beachte, dass tracert eine TCP-Ablaufverfolgung nicht zulässt. Für den vollen Funktionsumfang kannst du das Tool tracetcp installieren.
Führe die folgenden Tests zwischen der privaten und öffentlichen IP-Adresse der Amazon EC2-Instance und dem On-Premises-Host durch.
Wichtig: Rufe die Ergebnisse in beide Richtungen ab. Der Pfad zwischen Knoten in einem TCP- und IP-Adressnetzwerk kann sich ändern, wenn du die Richtung umkehrst.
Verwende für Linux den folgenden Befehl:
sudo traceroute -T -p 80 Host_IP
Hinweis: Ersetze Host_IP durch die private IP-Adresse deiner EC2-Instance oder deines On-Premises-Hosts und 80 durch deinen Port. Für eine bessere Genauigkeit verwendet das vorherige Beispiel eine TCP-basierte Ablaufverfolgung (T), um den Pfad des Verkehrs innerhalb des Tunnels zu testen. Ersetze Host_IP durch die öffentliche IP-Adresse des Tunnels, um den Pfad des Datenverkehrs über das Internet zu testen.
Du erhältst eine Ausgabe, die dem folgenden Beispiel ähnelt:
traceroute -T -p 443 aws.com traceroute to aws.com (3.161.213.43), 30 hops max, 60 byte packets 1 SEA-1801842641.mshome.net (172.28.96.1) 0.363 ms 0.346 ms 0.362 ms 2 192.168.50.1 (192.168.50.1) 5.514 ms 5.508 ms 5.501 ms 3 172.27.232.1 (172.27.232.1) 45.179 ms 52.879 ms 52.871 ms 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 server.yul62.r.ct.net (3.161.213.43) 57.452 ms 57.741 ms 62.604 ms
Diese Beispielausgabe zeigt Zwischen-Hops ohne Antwort. Obwohl die Geräte auf dem angeforderten 443-Port nicht geantwortet haben, gibt es kein Problem, da das Ziel immer noch wie erwartet antwortet.
Führe unter Windows tracert aus. Oder führe den folgenden PowerShell-Befehl aus, wenn du tracetcp installiert hast:
tracetcp.exe Host_IP:80
Hinweis: Ersetze Host_IP durch die private IP-Adresse deiner EC2-Instance oder deines On-Premises-Hosts und 80 durch deinen Port. Für eine bessere Genauigkeit verwendet das vorherige Beispiel eine TCP-basierte Ablaufverfolgung (T), um den Pfad des Verkehrs innerhalb des Tunnels zu testen. Ersetze Host_IP durch die öffentliche IP-Adresse des Tunnels, um den Pfad des Datenverkehrs über das Internet zu testen.
Du erhältst eine Ausgabe, die dem folgenden Beispiel ähnelt:
PS C:\Users\UserA> tracetcp.exe aws.com:443 Tracing route to 18.239.168.29 [server-18-239-168-29.bos50.r.cloudfront.net] on port 443 Over a maximum of 30 hops. 1 5 ms 7 ms 6 ms 192.168.50.1 2 41 ms 42 ms 44 ms 172.27.232.1 3 * * * Request timed out. 4 * * * Request timed out. 5 * * * Request timed out. 6 51 ms 43 ms 45 ms 241.0.11.143 7 62 ms 54 ms 43 ms 241.0.11.135 8 53 ms 53 ms 55 ms 240.4.8.24 9 52 ms 56 ms 53 ms 240.4.8.17 10 56 ms 59 ms 62 ms 240.64.239.162 11 57 ms 56 ms 61 ms 240.64.239.162 12 57 ms 55 ms 57 ms 240.64.239.162 13 58 ms Destination Reached in 54 ms. Connection established to 18.239.168.29 Trace Complete.
Testen der End-to-End-TCP-Leistung
Verwende hping3, um den Verlust und die Latenz von TCP-Paketen umfassend zu testen. Mit diesem Tool kannst du die TCP-Leistung direkt zwischen Hosts bewerten.
Führe den folgenden Befehl aus, um hping3 auf Amazon Linux zu installieren:
sudo yum --enablerepo=epel install hping3
Führe den folgenden Befehl aus, um hping3 auf Ubuntu zu installieren:
sudo apt-get install hping3
Führe den folgenden Befehl aus, um hping3 auszuführen:
hping3 -S -c 50 -V Host_IP
Hinweis: Ersetze Host_IP durch die private IP-Adresse deiner EC2-Instance oder deines On-Premises-Hosts oder durch die öffentliche IP-Adresse des Tunnels.
Die folgende Beispielausgabe zeigt einen Test gegen die öffentliche IP-Adresse eines VPN-Endpunkts, der Port TCP 8443 verwendet:
sudo hping3 -S -c 3 -p 8443 -V 34.233.155.9 using eth0, addr: 172.28.100.111, MTU: 1500 HPING 34.233.155.9 (eth0 34.233.155.9): S set, 40 headers + 0 data bytes len=44 ip=34.233.155.9 ttl=60 DF id=0 tos=0 iplen=44 sport=8443 flags=SA seq=0 win=26883 rtt=49.6 ms seq=2996814187 ack=1585541078 sum=22f7 urp=0 len=44 ip=34.233.155.9 ttl=60 DF id=0 tos=0 iplen=44 sport=8443 flags=SA seq=1 win=26883 rtt=49.6 ms seq=3555645549 ack=1207738370 sum=29a5 urp=0 len=44 ip=34.233.155.9 ttl=60 DF id=0 tos=0 iplen=44 sport=8443 flags=SA seq=2 win=26883 rtt=49.2 ms seq=4045561197 ack=742863285 sum=f78c urp=0
Ermitteln von Problemen mit dem Netzwerk oder der Anwendung
Erfasse Pakete gleichzeitig auf der EC2-Instance und auf dem On-Premises-Host, wenn das Problem auftritt. Verwende die Paketerfassung, um Probleme mit dem Netzwerk oder der Anwendung zu ermitteln.
Verwende tcpdump, um eine Paketerfassung für Linux-Instances zu erhalten.
Führe den folgenden Befehl aus, um tcpdump auf Amazon Linux zu installieren:
sudo yum install tcpdump
Führe den folgenden Befehl aus, um tcpdump auf Ubuntu zu installieren:
sudo apt-get install tcpdump
Verwende für Windows Wireshark anstelle von tcpdump. Informationen zum Herunterladen des Tools findest du unter Download Wireshark (Wireshark herunterladen) auf der Wireshark-Website.
Die Paketerfassung sieht dem folgenden Beispiel ähnlich aus:
tcpdump -i any -nnvv port 500 and port 4500 tcpdump: listening on any, link-type EN10MB (Ethernet), capture size 65535 bytes 18:12:54.944933 IP (tos 0x0, ttl 63, id 43082, offset 0, flags [DF], proto UDP (17), length 212) 10.20.20.80.500 > 23.20.145.20.500: [udp sum ok] isakmp 1.0 msgid 00000000 cookie 19e7adeabfefca84→0000000000000000: phase 1 I ident: (sa: doi=ipsec situation=identity (p: #1 protoid=isakmp transform=1 (t: #1 id=ike (type=lifetype value=sec)(type=lifeduration value=7080)(type=enc value=aes)(type=keylen value=0080)(type=auth value=preshared)(type=hash value=sha1)(type=group desc value=modp1024)))) (vid: len=16) (vid: len=16) (vid: len=16) (vid: len=16) (vid: len=16) out slot1/tmm0 lis=$_ike_1061b_out_23.20.145.20 port=1.0 trunk= 18:12:54.946069 IP (tos 0x0, ttl 253, id 56278, offset 0, flags [none], proto UDP (17), length 152) 23.20.145.20.500 > 10.20.20.80.500: [udp sum ok] isakmp 1.0 msgid 00000000 cookie 19e7adeabfefca84→cfa493578af1f691: phase 1 R ident: (sa: doi=ipsec situation=identity (p: #1 protoid=isakmp transform=1 (t: #1 id=ike (type=enc value=aes)(type=keylen value=0080)(type=hash value=sha1)(type=group desc value=modp1024)(type=auth value=preshared)(type=lifetype value=sec)(type=lifedura tion value=7080)))) (vid: len=16) (vid: len=16) in slot1/tmm0 lis= port=1.0 trunk= 18:12:54.949988 IP (tos 0x0, ttl 63, id 43084, offset 0, flags [DF], proto UDP (17), length 256) 10.20.20.80.500 > 23.20.145.20.500: [udp sum ok] isakmp 1.0 msgid 00000000 cookie 19e7adeabfefca84→cfa493578af1f691: phase 1 I ident: (ke: key len=128) (nonce: n len=16 data=(e84ae917994501b5b4f4...1a547b3cf720e35995f5b0c69198c9f796b5d9f9)) (pay20) (pay20) out slot1/tmm0 lis=$_ike_1061a_in_10.20.20.80 port=1.0 trunk= 18:12:54.951858 IP (tos 0x0, ttl 253, id 56279, offset 0, flags [none], proto UDP (17), length 272) 23.20.145.20.500 > 10.20.20.80.500: [udp sum ok] isakmp 1.0 msgid 00000000 cookie 19e7adeabfefca84→cfa493578af1f691: phase 1 R ident: (ke: key len=128) (nonce: n len=32 data=(c5170686e88069e33323...4448aaf06cc37d4b32d67df97e275e5756a534d8)) (pay20) (pay20) in slot1/tmm0 lis=$_ike_1061a_in_10.20.20.80 port=1.0 trunk=
(Nur Windows) Deaktivierung der ECN
Wenn die explizite Explicit Congestion Notification (ECN) für Windows-Instances aktiviert ist, kann es zu Paketverlusten oder Leistungsproblemen kommen.
Führe den folgenden PowerShell-Befehl aus, um zu überprüfen, ob ECN aktiviert ist:
netsh interface tcp show global
Führe den folgenden PowerShell-Befehl aus, um ECN zu deaktivieren:
netsh interface tcp set global ecncapability=disabled
Ähnliche Informationen
Netzwerkleistungsmetriken auf Amazon EC2-Instance-Ebene ermöglichen neue Erkenntnisse
Wie behebe ich Probleme mit niedriger Übertragungsgeschwindigkeit in meinem Site-to-Site-VPN?
Relevanter Inhalt
- AWS OFFICIALAktualisiert vor einem Jahr
- AWS OFFICIALAktualisiert vor 3 Jahren
- AWS OFFICIALAktualisiert vor einem Jahr
- AWS OFFICIALAktualisiert vor 2 Jahren