MTU op iPhone-VPN: bepaal de eigenaar voordat je een getal wijzigt

Elke discussie over de pakketgrootte van de iPhone-VPN biedt uiteindelijk hetzelfde Mac-commando tegen een interface met de naam ppp0, meestal met een getal erbij. Het gaat niet over, en het zou zelfs op de Mac niet de juiste regeling zijn, tenzij die interface bij de betreffende verbinding hoorde. Op de telefoon is het getal eigendom van wie de tunnel implementeert: het besturingssysteem voor een native profiel, een packet-tunnelprovider voor een app, of de gateway wanneer een gedocumenteerd attribuut wordt onderhandeld. Drie vragen bepalen met welk van die gevallen je te maken hebt.

Vraag één: welke client draait er

Een native IKEv2-profiel, het ingebouwde Cisco IPsec-profiel en een Cisco-client van derden zijn drie verschillende implementaties met drie verschillende sets ondersteunde attributen. Het profieltype in Instellingen vertelt je welke de telefoon werkelijk heeft gestart, en de app-lijst vertelt of er überhaupt een provider in het pad zit. Begin daar, want de rest van de beslissing volgt daaruit. Als er geen provider in de app-lijst verschijnt, is de tunnel eigendom van het besturingssysteem.

Leid de implementatie niet af van de gateway-leverancier. Een Cisco-headend kan verbindingen van clients beëindigen die niets anders delen dan de naam van de leverancier. Een schermafbeelding van een oude build op een oude release vertelt wat dat paar ondersteunde, niet wat de telefoon in je hand doet.

Vraag twee: wie bezit de waarde

Apple stelt een MTU-eigenschap beschikbaar aan packet-tunnelontwikkelaars via het instellingenobject van de netwerkuitbreiding. Dat is een API voor de provider die zijn eigen tunnel configureert, geen schakelaar die een gebruiker of beheerder bij de geïnstalleerde client van iemand anders kan omzetten. Een app van derden kan ervoor kiezen die beschikbaar te stellen, te negeren of een waarde hard te coderen.

Bij een native profiel kiest het besturingssysteem de interfacegrootte, en de telefoon biedt daarvoor geen editor. Voor een Cisco-gateway voor externe toegang is er een gedocumenteerd attribuut voor het verbindingsprofiel, en of dat geldt hangt af van de client, de release en het onderhandelde transport. Juist in die kloof tussen gedocumenteerd en nageleefd gaat een gekopieerd getal mis.

Vraag drie: hangt het symptoom eigenlijk van de grootte af

Grootteproblemen hebben een signatuur: kleine verzoeken slagen, grote uploads of grote antwoorden blijven hangen, en dezelfde dienst werkt via een ander toegangsnetwerk. Filtering, een limiet op de payload van de app en een vastgelopen server kunnen een vergelijkbare klacht opleveren, dus leg de ene mislukkende handeling naast een werkende. Schrijf beide op met tijden en groottes als de app die meldt. Zonder dat paar is elke latere wijziging giswerk.

Voer dezelfde test uit op Wi-Fi en op mobiel netwerk. Een storing die het netwerk volgt, wijst op het pad; een die het apparaat volgt, wijst op de client of het profiel, en die twee hebben verschillende eigenaren nodig. Gebruik dezelfde dienst en hetzelfde account voor beide runs, anders zegt de vergelijking je niets.

Waarom het Mac-recept blijft opduiken

Jaren van op PPP gebaseerde desktop-VPN's maakten een wijziging van de interfacegrootte tot een legitieme lokale omweg, en die instructies werden doorgekopieerd naar mobiele threads. Op de telefoon is er geen shell, geen dergelijke interfacenaam en geen persistentie na opnieuw verbinden. Een recept dat in 2011 een desktopprobleem oploste, reisde veel verder dan de omstandigheden die het waar maakten. Mobiele clients accepteren hiervoor geen enkel shell-commando, wat de thread ook beweert.

Behandel de gekopieerde waarde als een hypothese over een pad, niet als een instelling. Als een kleinere grootte een overdracht laat werken en een grotere betrouwbaar faalt, heb je bewijs over het pad; je moet nog steeds het onderdeel vinden dat erop mag ingrijpen. Die zoektocht eindigt meestal bij het gateway-profiel of bij de app-leverancier, en zelden bij de telefoon.

Het transport verandert het antwoord

Als de sessie over TLS loopt in plaats van IPsec, kan een TCP-segmentatieaanpassing op de gateway helpen, omdat die de aangekondigde segmentgrootte voor TCP-stromen herschrijft. Voor UDP-verkeer doet het niets, en dat omvat meer van het moderne web dan mensen verwachten. Controleer het onderhandelde transport voordat je de wijziging voorstelt, en noem in het ticket welk transport je verwacht te raken.

Path MTU discovery bestaat zodat de eindpunten de echte limiet leren in plaats van te gissen. Het blokkeren van de feedback en het hard coderen van een kleine grootte ruilt een werkende grote overdracht voor een permanente, verborgen kostenpost bij elke verbinding.

Wat je het gateway-team moet vragen

Vraag drie dingen: de exacte attribuutnaam en de reikwijdte ervan, of de uitgerolde clients die naleven, en welk transport de sessie heeft onderhandeld. Een wijziging op één groepsbeleid is testbaar; een globale aanpassing niet, en die verplaatst risico naar gebruikers die nooit een probleem hebben gemeld. Vraag ook de documentreferentie, want attribuutnamen verschuiven tussen releases.

Wijzig dan één ding en test de oorspronkelijk mislukkende handeling opnieuw, niet een snelheidstest-download. Bewaar het voor- en na-verslag met de clientversie en het toegangsnetwerk, zodat het volgende rapport kan worden vergeleken in plaats van opnieuw bediscussieerd.

Als de handeling bij de oorspronkelijke grootte nog steeds mislukt, was de grootte niet de oorzaak. Leg ook die conclusie vast, zodat de volgende persoon dezelfde hypothese niet opnieuw opent.