MTU på iPhone-VPN: velg eieren før du endrer et tall

Hver tråd om pakkestørrelse på iPhone-VPN ender med å tilby den samme Mac-kommandoen mot et grensesnitt som heter ppp0, vanligvis med et tall vedlagt. Den overføres ikke, og den ville ikke være riktig kontroll selv på Macen med mindre grensesnittet tilhørte den aktuelle forbindelsen. På telefonen eies tallet av den som implementerer tunnelen: operativsystemet for en innebygd profil, en pakketunnel-leverandør for en app, eller gatewayen når en dokumentert egenskap forhandles. Tre spørsmål avgjør hvilken av disse du har med å gjøre.

Spørsmål én: hvilken klient kjører

En innebygd IKEv2-profil, den innebygde Cisco IPsec-profilen og en Cisco-klient fra tredjepart er tre forskjellige implementasjoner med tre forskjellige sett støttede egenskaper. Profiltypen i Innstillinger forteller deg hvilken telefonen faktisk startet, og applisten forteller deg om det i det hele tatt er en leverandør i banen. Start der, fordi resten av beslutningen følger av det. Hvis ingen leverandør vises i applisten, eier operativsystemet tunnelen.

Ikke utled implementasjonen fra gateway-leverandøren. En Cisco-headend kan avslutte forbindelser fra klienter som ikke deler noe annet enn leverandørens navn. Et skjermbilde av en gammel build på en gammel utgivelse forteller deg hva det paret støttet, ikke hva telefonen i hånden din gjør.

Spørsmål to: hvem eier verdien

Apple eksponerer en MTU-egenskap til pakketunnel-utviklere gjennom innstillingsobjektet for nettverksutvidelsen. Det er et API for leverandøren som konfigurerer sin egen tunnel, ikke en bryter en bruker eller administrator kan slå på hos andres installerte klient. En tredjepartsapp kan velge å eksponere den, ignorere den eller hardkode en verdi.

For en innebygd profil velger operativsystemet grensesnittstørrelsen, og telefonen eksponerer ingen redigerer for den. For en Cisco-gateway for fjernaksess finnes det en dokumentert egenskap for tilkoblingsprofilen, og om den gjelder avhenger av klienten, utgivelsen og den forhandlede transporten. Det gapet mellom dokumentert og etterlevd er der et kopiert tall går galt.

Spørsmål tre: avhenger symptomet i det hele tatt av størrelsen

Størrelsesproblemer har en signatur: små forespørsler lykkes, store opplastinger eller store svar henger, og den samme tjenesten virker over et annet aksessnett. Filtrering, en grense for appens nyttelast og en fastlåst server kan gi en lignende klage, så registrer den ene operasjonen som feiler ved siden av en som virker. Skriv begge ned med tider og størrelser hvis appen rapporterer dem. Uten det paret er enhver senere endring gjetting.

Kjør den samme testen på Wi-Fi og på mobilnett. En feil som følger nettet, peker på banen; en som følger enheten, peker på klienten eller profilen, og de to trenger forskjellige eiere. Bruk samme tjeneste og samme konto for begge kjøringene, ellers sier sammenligningen deg ingenting.

Hvorfor Mac-oppskriften fortsetter å dukke opp

År med PPP-baserte skrivebords-VPN-er gjorde en endring av grensesnittstørrelse til en legitim lokal omvei, og de instruksjonene ble kopiert videre inn i mobile tråder. På telefonen finnes det ingen shell, ingen slik grensesnittnavn og ingen vedvarende effekt etter en gjentilkobling. En oppskrift som løste et skrivebordsproblem i 2011, reiste mye lenger enn forholdene som gjorde den sann. Mobile klienter godtar ingen shell-kommando for dette, uansett hva tråden påstår.

Behandle den kopierte verdien som en hypotese om en bane, ikke som en innstilling. Hvis en mindre størrelse får en overføring til å virke og en større feiler pålitelig, har du bevis om banen; du må fortsatt finne komponenten som har lov til å handle på den. Den letingen ender vanligvis ved gateway-profilen eller app-leverandøren, og sjelden ved telefonen.

Transporten endrer svaret

Hvis økten kjører over TLS i stedet for IPsec, kan en TCP-segmenteringsjustering på gatewayen hjelpe, fordi den skriver om den annonserte segmentstørrelsen for TCP-strømmer. Den gjør ingenting for UDP-trafikk, som omfatter mer av det moderne nettet enn folk forventer. Sjekk den forhandlede transporten før du foreslår endringen, og navngi i saken hvilken transport du forventer blir påvirket.

Path MTU discovery finnes slik at endepunktene kan lære den virkelige grensen i stedet for å gjette. Å blokkere tilbakemeldingen og hardkode en liten størrelse bytter en fungerende stor overføring mot en permanent, skjult kostnad på hver forbindelse.

Hva du bør spørre gateway-teamet om

Be om tre ting: det nøyaktige egenskapsnavnet og omfanget, om de utrullede klientene etterlever det, og hvilken transport økten forhandlet. En endring brukt på én gruppepolicy er testbar; en global redigering er det ikke, og den flytter risiko over på brukere som aldri har rapportert et problem. Be også om dokumentreferansen, fordi egenskapsnavn endrer seg mellom utgivelser.

Endre så én ting og test den opprinnelige feilende operasjonen på nytt, ikke en hastighetstest-nedlasting. Ta vare på før- og etter-oppføringen sammen med klientversjonen og aksessnettet, slik at neste rapport kan sammenlignes i stedet for å bli tatt opp på nytt.

Hvis operasjonen fortsatt feiler ved den opprinnelige størrelsen, var ikke størrelsen årsaken. Noter også den konklusjonen, slik at neste person ikke åpner den samme hypotesen igjen.