MTU i iPhone-VPN: välj ägaren innan du ändrar ett tal
Tre frågor avgör om appen, gateway-profilen eller ingen på telefonen kan ändra storleken. Svara på dem innan du lånar ett tal från en Mac.
Varje tråd om paketstorlek i iPhone-VPN erbjuder till slut samma Mac-kommando mot ett gränssnitt som heter ppp0, oftast med ett tal bifogat. Det överförs inte, och det skulle inte vara rätt kontroll ens på Macen om inte gränssnittet tillhörde den aktuella anslutningen. På telefonen ägs talet av den som implementerar tunneln: operativsystemet för en inbyggd profil, en pakettunnel-leverantör för en app, eller gatewayen när en dokumenterad egenskap förhandlas. Tre frågor avgör vilket av dessa fall du har att göra med.
Fråga ett: vilken klient körs
En inbyggd IKEv2-profil, den inbyggda Cisco IPsec-profilen och en Cisco-klient från tredje part är tre olika implementeringar med tre olika uppsättningar stödda egenskaper. Profiltypen i Inställningar berättar vilken telefonen faktiskt startade, och applistan berättar om det över huvud taget finns en leverantör i vägen. Börja där, eftersom resten av beslutet följer av det. Om ingen leverantör visas i applistan äger operativsystemet tunneln.
Härled inte implementeringen från gateway-leverantören. En Cisco-headend kan avsluta anslutningar från klienter som inte delar något annat än leverantörens namn. En skärmbild av ett gammalt bygge på en gammal utgåva berättar vad det paret stödde, inte vad telefonen i din hand gör.
Fråga två: vem äger värdet
Apple exponerar en MTU-egenskap för pakettunnelutvecklare via inställningsobjektet för nätverksutökningen. Det är ett API för leverantören som konfigurerar sin egen tunnel, inte en strömbrytare som en användare eller administratör kan slå på hos någon annans installerade klient. En tredjepartsapp kan välja att exponera den, ignorera den eller hårdkoda ett värde.
För en inbyggd profil väljer operativsystemet gränssnittets storlek, och telefonen exponerar ingen redigerare för den. För en Cisco-gateway för fjärråtkomst finns en dokumenterad egenskap för anslutningsprofilen, och om den gäller beror på klienten, utgåvan och den förhandlade transporten. Det gapet mellan dokumenterat och efterlevt är där ett kopierat tal går fel.
| Owner | Who can change it | Reachable from the phone |
|---|---|---|
| Packet-tunnel provider | The app vendor through its API | Only if the app exposes a setting |
| Native IKEv2 or Cisco IPsec profile | The operating system | No user control |
| Gateway group policy attribute | The gateway administrator | If the client honours it |
Fråga tre: beror symtomet över huvud taget på storleken
Storleksproblem har en signatur: små förfrågningar lyckas, stora uppladdningar eller stora svar hänger, och samma tjänst fungerar över ett annat åtkomstnät. Filtrering, en gräns för appens nyttolast och en fastnad server kan ge ett liknande klagomål, så registrera den ena operationen som misslyckas bredvid en som fungerar. Skriv ned båda med tider och storlekar om appen rapporterar dem. Utan det paret är varje senare ändring gissning.
Kör samma test på Wi-Fi och på mobilnät. Ett fel som följer nätet pekar på vägen; ett som följer enheten pekar på klienten eller profilen, och de två behöver olika ägare. Använd samma tjänst och samma konto för båda körningarna, annars säger jämförelsen dig ingenting.
Varför Mac-receptet fortsätter att dyka upp
År av PPP-baserade skrivbords-VPN gjorde en ändring av gränssnittets storlek till en legitim lokal lösning, och de instruktionerna kopierades vidare in i mobila trådar. På telefonen finns inget skal, inget sådant gränssnittsnamn och ingen beständighet efter en återanslutning. Ett recept som löste ett skrivbordsproblem 2011 reste mycket längre än de förhållanden som gjorde det sant. Mobila klienter accepterar inget skalkommando för detta, vad tråden än påstår.
Behandla det kopierade värdet som en hypotes om en väg, inte som en inställning. Om en mindre storlek får en överföring att fungera och en större misslyckas pålitligt, har du bevis om vägen; du måste fortfarande hitta komponenten som får agera på den. Den sökningen slutar vanligtvis vid gateway-profilen eller hos appleverantören, och sällan vid telefonen.
Transporten ändrar svaret
Om sessionen körs över TLS i stället för IPsec kan en TCP-segmenteringsjustering på gatewayen hjälpa, eftersom den skriver om den annonserade segmentstorleken för TCP-flöden. Den gör ingenting för UDP-trafik, som omfattar mer av det moderna nätet än folk förväntar sig. Kontrollera den förhandlade transporten innan du föreslår ändringen, och ange i ärendet vilken transport du förväntar dig påverkas.
Path MTU discovery finns så att ändpunkterna kan lära sig den verkliga gränsen i stället för att gissa. Att blockera återkopplingen och hårdkoda en liten storlek byter en fungerande stor överföring mot en permanent, dold kostnad på varje anslutning.
Vad du bör fråga gateway-teamet
Be om tre saker: det exakta egenskapsnamnet och dess omfattning, om de utplacerade klienterna följer det, och vilken transport sessionen förhandlade. En ändring som tillämpas på en grupprincip går att testa; en global redigering gör det inte, och den flyttar risk till användare som aldrig har rapporterat ett problem. Be också om dokumentreferensen, eftersom egenskapsnamn ändras mellan utgåvor.
Ändra sedan en sak och testa om den ursprungligen misslyckade operationen, inte en nedladdning från ett hastighetstest. Spara före- och efterregistreringen med klientversionen och åtkomstnätet, så att nästa rapport kan jämföras i stället för att tas upp på nytt.
Om operationen fortfarande misslyckas vid den ursprungliga storleken var storleken inte orsaken. Anteckna även den slutsatsen, så att nästa person inte öppnar samma hypotes igen.