Warum OpenConnect-Seiten hängen, bis Sie die Tunnel-MTU senken

Die Anmeldung gelingt, die Portalseite wird gezeichnet, und dann bleibt ein Dashboard-Widget oder ein Bericht bei waiting for host stehen, bis der Browser aufgibt. Öffentliche Websites laden die ganze Zeit normal, und keine Zugangsdaten haben sich geändert. Dass kleine Antworten ankommen, während große stocken, ist die Signatur einer Paketgrößen-Obergrenze und nicht einer Zugriffsregel. Bestätigen Sie diese Lesart, bevor Sie sonst etwas im Profil ändern.

Trennen Sie ein Größenproblem von einem Richtlinienproblem

Beginnen Sie damit, eine Ablehnung auszuschließen. Hätte das Gateway Sie abgewiesen, wäre die Verbindung sofort gescheitert, statt eine Seite halb zu laden. Ein Tunnel, der hochkommt und dann nur bei größeren Übertragungen stockt, sagt Ihnen, dass der äußere Pfad das innere Paket nicht tragen kann.

Der Mechanismus ist Kapselung. Jedes innere Paket erhält Tunnel-Header, sodass eine Nutzlast, die in den physischen Link passt, zu einem äußeren Paket wird, das nicht mehr passt, und alles, was das do-not-fragment-Bit trägt, wird verworfen, ohne dass der Browser eine Antwort deuten kann.

Messen Sie die Obergrenze mit do-not-fragment-Sonden

Messen Sie die Obergrenze, statt sie zu raten. Senden Sie Sonden, die Fragmentierung verweigern, und senken Sie die Nutzlast schrittweise, bis eine Antwort zurückkommt, beginnend mit einem Befehl wie ping -M do -s 1472 host. Eine Antwort, die beklagt, dass Fragmentierung nötig sei, obwohl DF gesetzt ist, bedeutet, dass der Wert noch zu hoch ist. Wiederholen Sie bei 1462, dann bei 1452, und hören Sie bei der ersten Größe auf, die antwortet. Notieren Sie die Zahl zusammen mit dem Host, den Sie geprüft haben, denn die Antwort gehört zu diesem Pfad und nicht zum Protokoll im Allgemeinen.

Prüfen Sie die Adresse, an die der Tunnel tatsächlich Verkehr schickt. Eine äußere Sonde gegen den öffentlichen Namen des Gateways und eine innere Sonde gegen einen internen Server messen verschiedene Hops, und ICMP-Filterung auf einer von beiden kann einen gesunden Pfad kaputt aussehen lassen.

Wenden Sie den Wert auf das Tunnelgerät an

Wenden Sie das Ergebnis auf das Interface an, das der Client angelegt hat, nicht auf den WLAN-Adapter. Bei einem Linux-Client ist das ip link set dev tun0 mtu 1300 gefolgt von ip link show tun0, um zu bestätigen, dass der Wert übernommen wurde. Verwenden Sie den Gerätenamen, den der Client meldet, denn er hängt von der Implementierung und davon ab, wie der Tunnel aufgebaut wurde.

Eine niedrigere Tunnel-MTU verkleinert die Nutzlast, die jedes Paket trägt, also sinkt der Massendurchsatz ein wenig, und das ist der Preis dafür, große Antworten nicht ins schwarze Loch zu schicken. Eine kleinere Zahl ist nicht automatisch sicherer. Stattdessen den physischen Adapter zu ändern verteilt den Schaden über jede Verbindung auf diesem Link, während überdimensionierte innere Pakete genauso überdimensioniert bleiben.

Nutzen Sie zuerst die MTU-Anfragen des Clients

Wenn Sie den Aufruf steuern, kann der Client eine Größe anfragen, statt nachträglich gepatcht zu werden. --mtu fordert eine Tunnel-MTU vom Server an, und --base-mtu erklärt die MTU des darunterliegenden Pfads, damit das Gateway den Tunnelwert ableiten kann. Beides sind Anfragen, und das Handbuch des Clients verspricht nicht, dass das Gateway eine davon befolgt.

Diese Unterscheidung bestimmt Ihre Arbeitsreihenfolge. Versuchen Sie zuerst die Anfrage und prüfen Sie das Interface, das sie erzeugt, und fallen Sie dann auf das lokale Setzen des Geräts zurück, wenn der vom Gateway gewählte Wert weiterhin stockt.

Prüfen Sie mit der Übertragung, die fehlgeschlagen ist, und machen Sie es dann dauerhaft

Eine lokale ip link-Änderung hält, bis der Client den Tunnel neu aufbaut, was beim nächsten Reconnect oder Resume passiert. Setzen Sie den Wert dorthin, wo die Verbindung beginnt: ein Wrapper, der den Client startet und danach das Gerät anpasst, eine systemd-Unit mit einem ExecStartPost-Schritt oder die Client-Option, wenn das Gateway sie akzeptiert. Halten Sie ihn neben dem Profil in der Versionskontrolle, damit die nächste Person sieht, warum die Zahl dort steht.

Testen Sie mit der Anfrage, die fehlgeschlagen ist, nicht mit der Startseite. Öffnen Sie den Bericht, laden Sie den Anhang, oder führen Sie den Repository-Abruf aus, der hing, und notieren Sie genau, wo er stoppt, falls er es noch tut. Eine Seite, die nach der Änderung rendert, beweist wenig, denn sie hat auch vorher gerendert.

Wenn dieselbe Übertragung an derselben Stelle stockt, ist die MTU-Theorie unbewiesen. Zeichnen Sie Verkehr auf dem Tunnel auf und prüfen Sie, welche Seite aufhört zu senden, bevor Sie die Zahl erneut ändern, und halten Sie den vorherigen Wert fest, damit ein Rollback ein einziger Befehl bleibt.