VPN-Ping funktioniert, aber die Website hängt: Prüfen Sie die Größe

Echo-Antworten kommen an, der Remotedesktop funktioniert, und der Browser bleibt auf einer leeren Seite, bis er aufgibt. Zwei Erklärungen passen zu diesem Muster, und sie sind keine Varianten eines Problems: eine Richtlinie, die den Dienst nie erlaubt hat, oder Pakete, die nicht mehr passen, sobald die Übertragung wächst. Die Echo-Antwort schließt keine von beiden aus.

Gehen Sie von der kleinsten Frage zur größten und notieren Sie, was jeder Schritt tatsächlich bewiesen hat.

Eine Echo-Antwort beantwortet eine viel kleinere Frage

Eine Echo-Antwort sagt, dass der IP-Stack des Ziels eine ICMP-Anfrage Ihrer Quelle beantwortet hat. Sie sagt nichts darüber, ob auf dem benötigten Port ein TCP-Listener existiert, ob eine Richtlinie diesen Port erlaubt oder ob der Zielhost den Verkehr unabhängig vom Gateway filtert. Ein Gateway, das einen Dienst erlaubt, kann einen anderen verwerfen, während beide Ziele auf Ping antworten. Lesen Sie die Antwort als eine Tatsache über ein Paket und eine Richtung.

Bestätigen Sie Ziel und Dienstport, bevor Sie irgendetwas anderes interpretieren. Die getestete Adresse und die von der Anwendung verwendete Adresse sind manchmal verschiedene Datensätze, und ein Name, der sich in zwei Adressen auflöst, macht das wahrscheinlich.

Finden Sie heraus, ob die Verbindung begonnen hat

Eine sofort abgelehnte Verbindung ist eine Antwort des Listeners oder der Richtlinie: Etwas hat geantwortet und nein gesagt. Eine Verbindung, die sich öffnet und dann stockt, wenn Daten zu fließen beginnen, deutet auf die Größe hin. Eine Verbindung, die den Handshake gar nicht abschließt, liegt meist an der Richtlinie oder am Routing und sieht wie eine Zeitüberschreitung aus, nicht wie eine Ablehnung.

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

Notieren Sie, welchen dieser drei Fälle Sie beobachtet haben, bevor Sie MTU-Einstellungen anfassen. Eine Tunnelgröße zu ändern, um eine abgelehnte Verbindung zu reparieren, verschwendet die Änderung und verbirgt die eigentliche Ursache eine Zeit lang.

Messen Sie die Größe mit einer genannten Zahl

Wenn der Stillstand unter Last auftritt, testen Sie eine Paketgröße mit gesetztem Don't-Fragment-Bit und nennen Sie die Rechnung, damit das Ergebnis etwas bedeutet. Unter Linux mit iputils ergibt eine Nutzlast von 1392 Bytes plus dem 8-Byte-ICMP-Header und dem 20-Byte-IPv4-Header ein inneres Paket von genau 1420 Bytes. Nennen Sie diese Rechnung im Ticket, denn ein nackter Ping, der das Gateway erreicht, beweist nichts über eine Anwendung.

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

Beide Proben sind Messpunkte, keine Empfehlungen für eine Tunnelgröße. Wenn ICMP irgendwo auf dem Pfad gefiltert wird, sagt eine Zeitüberschreitung nichts über die Größe, weil Filterung und ein zu großes Paket aus Sicht des Clients gleich aussehen. Ein Erfolg sagt auch nichts über die Gegenrichtung oder über ein anderes Ziel.

Berücksichtigen Sie den äußeren Pfad

Die Kapselung fügt eigene Header hinzu, sodass das Paket auf der Leitung größer ist als das Paket, das Sie im Tunnel gemessen haben. Die Lücke zwischen beiden ermöglicht gleichzeitig eine funktionierende kleine Anfrage und eine scheiternde große.

Die IPv4-Pfad-MTU-Erkennung hängt von Rückmeldungen über Pakete ab, die ohne Fragmentierung nicht weitergeleitet werden können, und IPv6 verwendet Packet-Too-Big-Nachrichten. Die IPv4-Spezifikation beschreibt diesen Mechanismus. Das Filtern der Rückmeldung zerstört die Lernfähigkeit des Senders und lässt ihn Pakete erneut senden, die nie passen werden. Deshalb können eine funktionierende kleine Anfrage und eine scheiternde große so bequem nebeneinander bestehen.

Ändern Sie eine Zahl und testen Sie die Anwendung erneut

Senken Sie die MTU des Tunnels oder begrenzen Sie die maximale Segmentgröße für TCP, und wiederholen Sie dann den ursprünglichen Anwendungstest statt der Probe. Eine Probe, die nach der Änderung erfolgreich ist, und eine Anwendung, die weiterhin hängt, sind ein anderes Problem mit ähnlicher Form, und nur der Anwendungstest unterscheidet sie.

Halten Sie die Rechnung im Änderungsdatensatz fest: die gemessene Größe, den angenommenen Overhead und den festgelegten Wert. Wer das später prüft, kann die Annahme kontrollieren, statt sie aus einem Screenshot eines Pings neu herzuleiten.

Wenn die Anwendung bei jeder getesteten Größe funktioniert, hören Sie auf, Zahlen anzupassen, und sehen Sie sich die Richtlinie an, die den funktionierenden Dienst vom scheiternden trennt.