MTU beim iPhone-VPN: Legen Sie den Eigentümer fest, bevor Sie eine Zahl ändern

Jeder Thread zur Paketgröße beim iPhone-VPN bietet irgendwann denselben Mac-Befehl gegen eine Schnittstelle namens ppp0 an, meist mit einer Zahl daneben. Er lässt sich nicht übertragen, und er wäre selbst auf dem Mac nicht die richtige Steuerung, es sei denn, diese Schnittstelle gehörte zur betreffenden Verbindung. Auf dem Telefon gehört die Zahl demjenigen, der den Tunnel implementiert: dem Betriebssystem bei einem nativen Profil, einem Packet-Tunnel-Anbieter bei einer App oder dem Gateway, wenn ein dokumentiertes Attribut ausgehandelt wird. Drei Fragen klären, welchen dieser Fälle Sie vor sich haben.

Frage eins: Welcher Client läuft

Ein natives IKEv2-Profil, das integrierte Cisco-IPsec-Profil und ein Cisco-Client eines Drittanbieters sind drei verschiedene Implementierungen mit drei verschiedenen Sätzen unterstützter Attribute. Der Profiltyp in den Einstellungen sagt Ihnen, welche das Telefon tatsächlich gestartet hat, und die App-Liste sagt Ihnen, ob überhaupt ein Anbieter im Pfad liegt. Beginnen Sie dort, denn der Rest der Entscheidung folgt daraus. Erscheint kein Anbieter in der App-Liste, gehört der Tunnel dem Betriebssystem.

Leiten Sie die Implementierung nicht vom Gateway-Hersteller ab. Ein Cisco-Headend kann Verbindungen von Clients beenden, die nichts außer dem Herstellernamen gemeinsam haben. Ein Screenshot eines alten Builds auf einer alten Version sagt Ihnen, was dieses Paar unterstützte, nicht was das Telefon in Ihrer Hand tut.

Frage zwei: Wem gehört der Wert

Apple stellt Paket-Tunnel-Entwicklern eine MTU-Eigenschaft über das Einstellungsobjekt der Netzwerkerweiterung bereit. Das ist eine API für den Anbieter, der seinen eigenen Tunnel konfiguriert, kein Schalter, den ein Benutzer oder Administrator am installierten Client eines anderen umlegen kann. Eine Drittanbieter-App kann sie bereitstellen, ignorieren oder einen Wert fest kodieren.

Bei einem nativen Profil wählt das Betriebssystem die Schnittstellengröße, und das Telefon bietet dafür keinen Editor an. Für ein Cisco-Gateway mit Fernzugriff gibt es ein dokumentiertes Attribut für das Verbindungsprofil, und ob es greift, hängt vom Client, von der Version und vom ausgehandelten Transport ab. Genau in dieser Lücke zwischen dokumentiert und eingehalten geht eine kopierte Zahl schief.

Frage drei: Hängt das Symptom überhaupt von der Größe ab

Größenprobleme haben eine Signatur: kleine Anfragen gelingen, große Uploads oder große Antworten hängen, und derselbe Dienst funktioniert über ein anderes Zugangsnetz. Filterung, ein Nutzlastlimit der Anwendung und ein hängender Server können eine ähnliche Beschwerde erzeugen, daher halten Sie den einen fehlschlagenden Vorgang neben einem funktionierenden fest. Schreiben Sie beide mit Zeiten und Größen auf, wenn die Anwendung sie meldet. Ohne dieses Paar ist jede spätere Änderung ein Ratespiel.

Führen Sie denselben Test im WLAN und im Mobilfunknetz durch. Ein Fehler, der dem Netz folgt, deutet auf den Pfad; einer, der dem Gerät folgt, deutet auf den Client oder das Profil, und beide brauchen unterschiedliche Eigentümer. Verwenden Sie für beide Läufe denselben Dienst und dasselbe Konto, sonst sagt Ihnen der Vergleich nichts.

Warum das Mac-Rezept immer wieder auftaucht

Jahre von PPP-basierten Desktop-VPNs machten eine Änderung der Schnittstellengröße zu einem legitimen lokalen Workaround, und diese Anleitungen wurden in mobile Threads weiterkopiert. Auf dem Telefon gibt es keine Shell, keinen solchen Schnittstellennamen und keine Persistenz über eine Neuverbindung hinweg. Ein Rezept, das 2011 ein Desktop-Problem löste, reiste viel weiter als die Bedingungen, die es wahr machten. Mobile Clients akzeptieren dafür keinen Shell-Befehl, was auch immer der Thread behauptet.

Behandeln Sie den kopierten Wert als Hypothese über einen Pfad, nicht als Einstellung. Wenn eine kleinere Größe eine Übertragung zum Laufen bringt und eine größere zuverlässig scheitert, haben Sie Belege zum Pfad; Sie müssen trotzdem die Komponente finden, die darauf reagieren darf. Diese Suche endet meist beim Gateway-Profil oder beim App-Anbieter und selten beim Telefon.

Der Transport ändert die Antwort

Läuft die Sitzung über TLS statt über IPsec, kann eine TCP-Segmentierungsanpassung am Gateway helfen, weil sie die angekündigte Segmentgröße für TCP-Ströme umschreibt. Für UDP-Verkehr bewirkt sie nichts, und dieser umfasst mehr des modernen Webs, als die Leute erwarten. Prüfen Sie den ausgehandelten Transport, bevor Sie die Änderung vorschlagen, und benennen Sie im Ticket, welchen Transport Sie betroffen erwarten.

Path MTU Discovery existiert, damit die Endpunkte die tatsächliche Grenze lernen, statt zu raten. Das Blockieren der Rückmeldung und das feste Kodieren einer kleinen Größe tauscht eine funktionierende große Übertragung gegen dauerhafte, versteckte Kosten bei jeder Verbindung.

Was Sie das Gateway-Team fragen sollten

Bitten Sie um drei Dinge: den genauen Attributnamen und seinen Geltungsbereich, ob die eingesetzten Clients ihn einhalten und welchen Transport die Sitzung ausgehandelt hat. Eine Änderung an einer Gruppenrichtlinie ist testbar; eine globale Änderung ist es nicht, und sie verlagert Risiko auf Benutzer, die nie ein Problem gemeldet haben. Bitten Sie auch um die Dokumentreferenz, weil Attributnamen zwischen Versionen wandern.

Ändern Sie dann eine Sache und testen Sie den ursprünglich fehlschlagenden Vorgang erneut, nicht einen Speedtest-Download. Bewahren Sie die Aufzeichnung vorher und nachher mit der Client-Version und dem Zugangsnetz auf, damit der nächste Bericht verglichen statt neu verhandelt werden kann.

Scheitert der Vorgang bei der ursprünglichen Größe weiterhin, war die Größe nicht die Ursache. Notieren Sie auch diese Schlussfolgerung, damit die nächste Person dieselbe Hypothese nicht erneut aufmacht.