Hängende Verbindung

Symptom: Ihr virtuelles Cloud-Netzwerk (VCN) ist über ein Site-to-Site-VPN oder Oracle Cloud Infrastructure FastConnect mit Ihrem vorhandenen On-Premise-Netzwerk verbunden. Hosts auf einer Seite der Verbindung können Hosts auf der anderen Seite pingen, der normale Traffic in der Verbindung hängt jedoch. Beispiel:

• Sie können SSH über die Verbindung hinweg zu einem Host führen, nachdem Sie sich jedoch bei dem Host angemeldet haben, hängt die Verbindung.
• Sie können eine Virtual Networking Computing-(VNC-)Verbindung starten, die Session hängt jedoch.
• Sie können einen SFTP-Download starten, der Download hängt jedoch.

Allgemeines Problem: PMTUD (Path Maximum Transmission Unit Discovery) funktioniert wahrscheinlich nicht auf einer oder beiden Seiten der Verbindung. Dies muss auf beiden Seiten der Verbindung funktionieren, damit beide Seiten jeweils erkennen, ob sie versuchen, Pakete zu senden, die zu groß für die Verbindung sind, und die Paketgröße entsprechend anpassen können. Einen kurzen Überblick über MTU (Maximum Transmission Unit) und PMTUD finden Sie unter MTU - Überblick und PMTUD - Überblick.

Lösungen zur Korrektur von PMTUD:

Das folgende Diagramm zeigt ein Beispielszenario, bei dem Ihr On-Premise-Netzwerk über ein Site-to-Site-VPN mit Ihrem VCN verbunden ist und Callouts für jeden Teil der Lösung enthält.

1. Stellen Sie sicher, dass Ihre Hosts PMTUD verwenden: Wenn die Hosts in Ihrem On-Premise-Netzwerk PMTUD nicht verwenden (wenn sie also das Flag "Don't Fragment" in den Paketen nicht setzen), können sie nicht erkennen, ob sie zu große Pakete für die Verbindung senden. Ihre Instanzen auf der Oracle-Seite der Verbindung verwenden standardmäßig PMTUD. Ändern Sie diese Konfiguration nicht in den Instanzen. Stellen Sie außerdem sicher, dass die Server über eine Firewallregel verfügen, die ICMP-Typ 3 Code 4 zulässt.

2. Stellen Sie sicher, dass die VCN-Sicherheitslisten und die Firewalls der Instanzen Nachrichten mit ICMP-Typ 3 Code 4 zulassen: Wenn PMTUD verwendet wird, erhalten die sendenden Hosts eine spezielle ICMP-Nachricht, wenn sie Pakete senden, die zu groß für die Verbindung sind. Nach Empfang der Nachricht kann der Host die Größe der Pakete dynamisch aktualisieren, um sie an die Verbindung anzupassen. Damit Ihre Instanzen jedoch diese wichtigen ICMP-Nachrichten empfangen können, müssen Sie die Sicherheitslisten für das Subnetz im VCN und die Firewalls der Instanzen so konfigurieren, dass sie diese Nachrichten akzeptieren.

   Tipp
   
   Wenn Sie Sicherheitslistenregeln für zustandsbehafteten Traffic verwenden (für TCP-, UDP- oder ICMP-Traffic), müssen Sie nicht sicherstellen, dass die Sicherheitsliste eine explizite Regel zur Zulassung von Nachrichten mit ICMP-Typ 3 Code 4 enthält, weil der Networking-Service die Verbindungen verfolgt und diese Nachrichten automatisch zulässt. Regeln für zustandslosen Traffic erfordern eine explizite Regel in der Ingress-Sicherheitsliste für ICMP-Typ-3-Code-4-Nachrichten. Vergewissern Sie sich, dass die Instanzfirewalls korrekt eingerichtet sind.

   Informationen zum Prüfen, ob ein Host die Nachrichten empfängt, finden Sie unter Herausfinden, wo PMTUD nicht funktioniert.

3. Stellen Sie sicher, dass Ihr On-Premise-Router das Kennzeichen Don't Fragment berücksichtigt: Wenn der Router das Kennzeichen nicht berücksichtigt und somit die Verwendung von PMTUD ignoriert, werden fragmentierte Pakete an die Instanzen im VCN gesendet. Dies ist ungünstig (siehe Warum Fragmentierung vermeiden?). Die Sicherheitslisten des VCN sind wahrscheinlich so konfiguriert, dass sie nur das erste Fragment erkennen und die restlichen Fragmente löschen. Dies führt zu einer hängenden Verbindung. Stattdessen sollte der Router PMTUD verwenden und das Kennzeichen "Don't Fragment" berücksichtigen, um die korrekte Größe nicht fragmentierter Pakete zu bestimmen, die über die Verbindung gesendet werden sollen.

Im Folgenden finden Sie einen kurzen Überblick über MTU und PMTUD sowie Informationen, wie Sie prüfen können, ob PMTUD auf beiden Seiten der Netzwerkverbindung funktioniert.

Möglicherweise möchten Sie eine Fragmentierung vermeiden. Erstens wirkt sie sich negativ auf die Performance der Anwendung aus. Eine Fragmentierung erfordert eine Reassemblierung der Fragmente sowie eine erneute Übertragung verlorener Fragmente. Reassemblierung und erneute Übertragung nehmen Zeit und CPU-Ressourcen in Anspruch.

Zweitens enthält nur das erste Fragment die Informationen zu Quell- und Zielport. Das bedeutet, dass die anderen Pakete entweder durch Firewalls oder durch die VCN-Sicherheitslisten gelöscht werden, weil sie in der Regel für die Auswertung der Portinformationen konfiguriert sind. Damit die Fragmentierung mit Ihren Firewalls und Sicherheitslisten funktioniert, müssten Sie diese mit einer höheren Toleranz konfigurieren. Dies ist jedoch nicht wünschenswert.

Bei der Kommunikation zwischen zwei beliebigen Hosts über ein Internet Protocol-(IP-)Netzwerk werden Pakete verwendet. Jedes Paket verfügt über eine Quell- und Ziel-IP-Adresse sowie über eine Daten-Payload. Jedes Netzwerksegment zwischen den beiden Hosts besitzt eine MTU (Maximum Transmission Unit), die die Anzahl der Byte darstellt, die ein einzelnes Paket übertragen kann.

Die MTU-Standardgröße im Internet beträgt 1500 Byte. Dies gilt auch für die meisten Heimnetzwerke und viele Unternehmensnetzwerke (und deren WLANs). Einige Data Center, einschließlich der Data Center für Oracle Cloud Infrastructure, können eine größere MTU besitzen. Alle OCI-Compute-Instanzen verwenden standardmäßig eine MTU von 9000. Auf einem Oracle Linux 8-Host können Sie mit dem Befehl ip address show die MTU der Netzwerkverbindung dieses Hosts anzeigen (oder ip link unter Red Hat Linux verwenden). Beispiel: Die Ausgabe einer Oracle Linux 8-Instanz (die MTU ist rot kursiv hervorgehoben):

ip address show <interface-x>
<interface-x>: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 01:00:5E:90:10:10 brd ff:ff:ff:ff:ff:ff
    ... 

Im Vergleich dazu finden Sie im Folgenden die Ausgabe eines Oracle Linux 8-Hosts, der mit einem Unternehmensnetzwerk verbunden ist:

ip address show <interface-y>
<interface-y>: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 01:00:5E:90:10:20 brd ff:ff:ff:ff:ff:ff
    ...

Beachten Sie, dass es sich bei der MTU um die typischeren 1500 Byte handelt.

Wenn der Host über ein Unternehmens-VPN verbunden ist, ist die MTU noch kleiner, weil der VPN-Tunnel den Traffic innerhalb eines IPsec-Pakets kapseln und über das lokale Netzwerk senden muss. Beispiel:

ip address show <interface-z>
<interface-z>: flags=81d1<UP,POINTOPOINT,RUNNING,NOARP,PROMISC,MULTICAST> mtu 1300 
... 

Woran erkennen die beiden Hosts, wie groß die Pakete sein dürfen, die sie sich gegenseitig senden können? Bei vielen Arten von Netzwerktraffic, wie HTTP, SSH und FTP, verwenden die Hosts TCP zum Aufbau neuer Verbindungen. Während des anfänglichen Dreiwege-Handshakes zwischen zwei Hosts senden beide die Maximum Segment Size (MSS), die angibt, wie groß die Payload sein darf. Dieser Wert ist kleiner als die MTU. (TCP wird innerhalb des Internetprotokolls (IP) ausgeführt, weshalb es als TCP/IP bezeichnet wird. Was bei IP als Paket bezeichnet wird, läuft bei TCP unter dem Begriff Segment.)

Mit der tcpdump-Anwendung wird der MSS-Wert angezeigt, der beim Handshake ausgetauscht wird. Es folgt ein Beispiel aus tcpdump (wobei der MSS-Wert in roter Kursivschrift hervorgehoben ist):

12:11:58.846890 IP 192.168.0.25.22 > 10.197.176.19.58824: Flags [S.], seq
2799552952, ack 2580095593, win 26844, options [mss 1260,sackOK,TS val
44858491 ecr 1321638674,nop,wscale 7], length 0

Das vorangegangene Paket stammt von einer SSH-Verbindung zu einer Instanz auf einem Laptop, der mit einem Unternehmens-VPN verbunden ist. Das lokale Netzwerk, das der Laptop für seine Internetverbindung verwendet, hat eine MTU von 1500 Byte. Der VPN-Tunnel setzt eine MTU von 1300 Byte durch. Beim Versuch des SSH-Verbindungsaufbaus teilt TCP (aus der IP-Verbindung heraus) der Oracle Cloud Infrastructure-Instanz dann mit, dass TCP-Segmente mit maximal 1260 Byte unterstützt werden. Bei einer VPN-Unternehmensverbindung hat der Laptop, der mit dem VPN verbunden ist, in der Regel die kleinsten MTU- und MSS-Werte im Vergleich zu allen Geräten, mit denen er über das Internet kommuniziert.

Ein komplexerer Fall tritt auf, wenn die beiden Hosts eine größere MTU besitzen als ein intermediärer Netzwerklink zwischen ihnen, der nicht direkt mit einem dieser Hosts verbunden ist. Das folgende Diagramm zeigt ein Beispiel.

Im Beispiel werden zwei Server angezeigt, die jeweils direkt mit einem eigenen gerouteten Netzwerk verbunden sind, das eine MTU von 9000 Byte unterstützt. Die Server befinden sich in verschiedenen Data Centern. Jedes Data Center ist mit dem Internet verbunden, das eine MTU von 1500 Byte unterstützt. Ein Site-to-Site-VPN-IPsec-Tunnel verbindet die beiden Data Center. Dieser Tunnel verläuft durch das Internet. Im Tunnel gilt somit eine kleinere MTU als im Internet. In diesem Diagramm beträgt die MTU 1.380 Byte.

Wenn die beiden Server (z.B. über SSH) zu kommunizieren versuchen, einigen sie sich beim Dreiwege-Handshake auf einen MSS-Wert von ca. 8.960. Die anfängliche SSH-Verbindung kann möglicherweise erfolgreich aufgebaut werden, da die maximalen Paketgrößen beim anfänglichen Setup der SSH-Verbindung im Allgemeinen weniger als 1.380 Byte betragen. Wenn eine Seite versucht, ein Paket zu senden, das größer ist als der kleinste Link zwischen den beiden Endpunkten, wird PMTUD (Path MTU Discovery) zum entscheidenden Faktor.

Path MTU Discovery ist in RFC 1191 und RFC 88999 definiert. Dabei müssen die beiden kommunizierenden Hosts das Kennzeichen Don't Fragment in den Paketen, die sie senden, setzen. Wenn ein Paket von einem dieser Hosts einen Router erreicht, bei dem die Egress- (oder ausgehende) Schnittstelle eine MTU hat, die kleiner ist als die Paketlänge, löscht der Router dieses Paket. Der Router gibt außerdem eine ICMP-Nachricht vom Typ 3 Code 4 an den Host zurück. Diese Nachricht besagt explizit "Destination Unreachable, Fragmentation Needed and Don't Fragment Was Set" (definiert in RFC 792). Der Router teilt dem Host dadurch quasi mit: "Du hast mir gesagt, ich soll keine Pakete fragmentieren, die zu groß sind, und dieses ist zu groß. Ich sende es nicht." Der Router teilt dem Host außerdem die maximal zulässige Größe von Paketen über diese Egress-Schnittstelle mit. Der sendende Host passt daraufhin die Größe der ausgehenden Pakete an, sodass sie kleiner als der Wert sind, der vom Router in der Nachricht angegeben wurde.

Im Folgenden finden Sie ein Beispiel für das angezeigte Ergebnis, wenn eine Instanz versucht, einen Host (203.0.113.2) über das Internet mit einem 8000-Byte-Paket und gesetztem "Don't Fragment"-Flag (bei verwendetem PMTUD) zu pingen. Die zurückgegebene ICMP-Nachricht wird in roter Kursivschrift hervorgehoben:

ping 203.0.113.2 -M do -s 8000

PING 203.0.113.2 (203.0.113.2) 8000(8028) bytes of data.
From 10.0.0.2 icmp_seq=1 

Frag needed and DF set (mtu = 1500)

Die Antwort entspricht genau den Erwartungen. Der Zielhost befindet sich im Internet, dessen MTU 1500 Byte beträgt. Auch wenn die lokale Netzwerkverbindung des sendenden Hosts eine MTU von 9000 Byte hat, kann der Host den Zielhost mit dem 8000-Byte-Paket nicht erreichen und erhält eine entsprechende ICMP-Nachricht. PMTUD funktioniert ordnungsgemäß.

Zum Vergleich finden Sie hier denselben Ping-Befehl, nur dass sich der Zielhost hier auf der anderen Seite eines Site-to-Site-VPN-IPsec-VPN-Tunnels befindet:

ping 192.168.6.130 -M do -s 8000
PING 192.168.0.130 (192.168.0.130) 8000(8028) bytes of data.
From 192.0.2.2 icmp_seq=1 Frag needed and DF set 

(mtu = 1358)

Hier erkennt der VPN-Router, dass die ausgehende Schnittstelle beim Versand des Pakets an das Ziel ein VPN-Tunnel ist. Dieser Tunnel führt durch das Internet und muss daher die MTU-Größe von maximal 1500 Byte des Internetlinks einhalten. Dementsprechend werden innerhalb des Tunnels nur Paketgrößen von maximal 1.360 Byte zugelassen. (Der Router hat diesen Wert dann wiederum auf 1.358 Byte verringert, was zu weiterer Verwirrung führen kann.)

Wenn PMTUD an einer Stelle entlang der Verbindung nicht funktioniert, müssen Sie die Ursache sowie diese Stelle ermitteln. Dies liegt in der Regel daran, dass das Paket mit ICMP-Typ 3 Code 4 (vom Router mit dem eingeschränkten Link, für den das Paket zu groß ist) nicht zum sendenden Host zurückkehrt. Dies kann passieren, wenn diese Art von Traffic zwischen Host und Router und auf beiden Seiten des VPN-Tunnels (oder einer anderen eingeschränkten MTU-Verbindung) blockiert wird.

-M pmtudisc_opt
Select Path MTU Discovery strategy. pmtudisc_option may be either do
(prohibit fragmentation, even local one), want (do PMTU discovery, fragment
locally when packet size is large), or dont (do not set DF flag).

ping -M do

 -s 1500 192.168.6.130
PING 192.168.0.130 (192.168.0.130) 1500(1528) bytes of data.
From 10.0.0.2 icmp_seq=1 

Frag needed and DF set (mtu = 1358)

Oracle empfiehlt die Verwendung von PMTUD. In einigen Fällen ist es jedoch möglich, Server so zu konfigurieren, dass sie nicht darauf angewiesen sind. Beispiel: Die Instanzen in Ihrem VCN kommunizieren über ein Site-to-Site-VPN mit Hosts in Ihrem On-Premise-Netzwerk. Sie kennen den IP-Adressbereich für Ihr On-Premise-Netzwerk. Sie können Ihren Instanzen eine spezielle Route hinzufügen, die angibt, welche MTU bei der Kommunikation mit Hosts in diesem Adressbereich maximal verwendet werden soll. Die Kommunikation zwischen den Instanzen im VCN verwendet weiterhin eine MTU von 9000 Byte.

Im Folgenden wird gezeigt, wie Sie diese Route auf einer Linux-Instanz festlegen.

Die Standardroutentabelle in der Instanz enthält in der Regel zwei Routen: die Standardroute (für das Standardgateway) und eine lokale Route (für das lokale Subnetz). Beispiel:

ip route show
default via 10.0.6.1 dev ens3
10.0.6.0/27 dev ens3  proto kernel  scope link  src 10.0.6.9

Sie können eine weitere Route hinzufügen, die auf dasselbe Standardgateway verweist, mit dem Adressbereich des On-Premise-Netzwerks und einer kleineren MTU. Beispiel: Im folgenden Befehl lautet das On-Premise-Netzwerk 1.0.0.0/8, das Standardgateway lautet 10.0.6.1, und die maximale MTU-Größe für Pakete, die an das On-Premise-Netzwerk gesendet werden, beträgt 1300 Byte.

ip route add 1.0.0.0/8 via 10.0.6.1 mtu 1300

Die aktualisierte Routentabelle sieht folgendermaßen aus:

ip route show
default via 10.0.6.1 dev ens3
1.0.0.0/8 via 10.0.6.1 dev ens3  mtu 1300
10.0.6.0/27 dev ens3  proto kernel  scope link  src 10.0.6.9

Innerhalb des VCN wird bei der Kommunikation zwischen den Instanzen weiterhin eine MTU von 9000 Byte verwendet. Bei der Kommunikation mit dem On-Premise-Netzwerk werden jedoch maximal 1300 Byte verwendet. In diesem Beispiel wird davon ausgegangen, dass die Verbindung zwischen dem On-Premise-Netzwerk und dem VCN in keinem Bereich eine MTU unter 1300 verwendet.