Ich habe ein Problem mit Paketverlusten in einem Rechenzentrum eines Drittanbieters in Florida, USA. Das Problem tritt nur bei Azure Virtual Machines auf, unabhängig davon, in welchem Rechenzentrum sich die VM befindet. Ich habe dieselben Tests gleichzeitig von anderen Nicht-Azure-Netzwerken aus durchgeführt, und es gibt keinen Paketverlust. Die Azure Virtual Machines waren „Vanilla“ / Out of the Box, ohne geladene Software oder andere Anpassungen / Änderungen.
Ich habe bereits mit den Netzwerkadministratoren im Rechenzentrum gesprochen und die einzigen Pakete, die sie sehen, sind diejenigen, bei denen es kein Timeout gibt; die Pakete, bei denen ein Timeout auftritt, erreichen nie ihre Firewall, also klingt es nach etwas auf der Azure-Seite (insbesondere, da die Pakete aus mehreren Azure-Rechenzentren/-Regionen ständig gelöscht werden/ein Timeout auftritt). Weiß jemand, wie ich das lösen könnte?
Der Test, den ich durchführte, war ein kontinuierlicher TCP-Ping (mitHerunterladen) an Port 80 (da ICMP auf Azure blockiert ist):
tcping -t 216.155.111.149 80
tcping -t 216.155.111.151 80
tcping -t 216.155.111.146 80
Ein weiterer Beweis dafür, dass es nicht das Rechenzentrum eines Drittanbieters ist, ist, dass ich denselben kontinuierlichen TCP-Ping von meinem Heimcomputer/Arbeitscomputer aus ausführen kann und keine Pakete verloren gehen. Ich habe auch ein Tunnel-VPN von der Azure-VM zu einer VM in einem Nicht-Azure-Rechenzentrum eingerichtet und es werden keine Pakete verloren. Pakete werden nur dann verloren, wenn der Datenverkehr direkt über Azure ins Internet/WAN geht.
Ich weiß, dass der nächste Schritt einige Traceroute-Tests wären, aber da Azure ICMP blockiert, musste ich verwendennmap zum Ausführen einer TCP-Traceroute; unten sind die Screenshots dieser Tests eingefügt.
nmap -sS -p 80 -Pn --traceroute 216.155.111.149
Antwort1
Wie ich in meinem Kommentar erwähnt habe, stoßen Sie hier auf ein ähnliches Szenario wie inDieser Artikel.
Ich könnte Ihr Verhalten leicht reproduzieren:
Und ich könnte das Problem leicht umgehen, indem ich einÖffentliche IP auf Instanzebenezur VM:
Es ist schwer zu sagen, was genau vor sich geht, da wir keine gleichzeitigen Erfassungen haben, aber meines Wissens hält das Edge-Gerät (möglicherweise eine Firewall) auf der Remote-Site (www.oandp.com) geschlossene Verbindungen länger in seiner Verbindungstabelle als Azure. Wenn Azure also einen der freigegebenen (d. h. bereits verwendeten) Ports verwendet und die Remote-Seite immer noch denkt, dass die Verbindung nicht vollständig geschlossen ist, werden unsere SYN-Pakete gelöscht.
Das ILPIP wendet ein statisches NAT oder ein „Eins-zu-eins-NAT“ an, daher gibt es weder eine Port-Übersetzung noch eine Port-Wiederverwendung (es sei denn, Ihr Betriebssystem tut dies), wodurch das Problem vermieden wird.