MTU iPhone VPN-en: előbb jelölje ki a tulajdonost, aztán módosítson számot
Három kérdés dönti el, hogy az alkalmazás, az átjáró profil vagy senki a telefonon módosíthatja-e a méretet. Válaszoljon rájuk, mielőtt számot kölcsönöz egy Macről.
Az iPhone VPN csomagméretéről szóló minden beszélgetés végül ugyanazt a Mac-parancsot kínálja egy ppp0 nevű interfész ellen, általában egy számmal mellette. Ez nem vihető át, és még a Macen sem lenne a helyes szabályzó, hacsak az az interfész nem a szóban forgó kapcsolathoz tartozott. A telefonon a szám annak a tulajdona, aki az alagutat megvalósítja: az operációs rendszeré natív profilnál, egy csomagalagút-szolgáltatóé alkalmazásnál, vagy az átjáróé, amikor dokumentált attribútumot egyeztetnek. Három kérdés tisztázza, melyik esettel áll szemben.
Első kérdés: melyik kliens fut
Egy natív IKEv2-profil, a beépített Cisco IPsec-profil és egy harmadik féltől származó Cisco-kliens három különböző megvalósítás, három különböző támogatott attribútumkészlettel. A Beállításokban látható profiltípus megmondja, melyiket indította el valójában a telefon, az alkalmazáslista pedig azt, hogy egyáltalán van-e szolgáltató az útvonalon. Innen induljon, mert a döntés többi része ebből következik. Ha nem jelenik meg szolgáltató az alkalmazáslistában, az alagút az operációs rendszeré.
Ne az átjáró gyártójából következtessen a megvalósításra. Egy Cisco központ képes olyan kliensek kapcsolatait lezárni, amelyek csak a gyártó nevét osztják. Egy régi buildekről készült képernyőkép azt mondja meg, mit támogatott az a páros, nem azt, mit tesz a kezében lévő telefon.
Második kérdés: kié az érték
Az Apple a hálózati kiterjesztés beállítási objektumán keresztül MTU-tulajdonságot tesz elérhetővé a csomagalagút-fejlesztők számára. Ez API a saját alagútját beállító szolgáltatónak, nem olyan kapcsoló, amelyet egy felhasználó vagy rendszergazda más telepített kliensén átkapcsolhat. Egy harmadik féltől származó alkalmazás dönthet úgy, hogy közzéteszi, figyelmen kívül hagyja vagy fix értéket kódol.
Natív profilnál az interfész méretét az operációs rendszer választja, és a telefon ehhez semmilyen szerkesztőt nem kínál. A Cisco távoli hozzáférésű átjáróhoz dokumentált attribútum tartozik a kapcsolati profilhoz, és hogy érvényes-e, a kliensről, a kiadástól és az egyeztetett átviteltől függ. Éppen a dokumentált és a betartott közötti résben hibázik el egy másolt szám.
| 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 |
Harmadik kérdés: függ-e egyáltalán a mérettől a tünet
A méretproblémáknak van aláírásuk: a kis kérések sikerülnek, a nagy feltöltések vagy nagy válaszok elakadnak, és ugyanaz a szolgáltatás más hozzáférési hálózaton működik. A szűrés, az alkalmazás hasznos terhelési korlátja és egy elakadt kiszolgáló hasonló panaszt kelthet, ezért jegyezze fel az egyik meghiúsuló műveletet egy működő mellett. Ha az alkalmazás jelzi, írja fel mindkettőt időkkel és méretekkel. E pár nélkül minden későbbi változtatás találgatás.
Futtassa ugyanazt a tesztet Wi-Fi-n és mobilhálózaton. A hálózatot követő hiba az útvonalra mutat; az eszközt követő a kliensre vagy a profilra, és a kettőhöz különböző tulajdonos kell. Mindkét futáshoz ugyanazt a szolgáltatást és ugyanazt a fiókot használja, különben az összehasonlítás semmit sem mond.
Miért bukkan fel újra meg újra a Mac-recept
A PPP-alapú asztali VPN-ek évei tették az interfészméret módosítását legitim helyi kerülőúttá, és ezek az utasítások átmásolódtak a mobilbeszélgetésekbe. A telefonon nincs shell, nincs ilyen interfésznév, és nincs tartósság az újracsatlakozás után. Egy 2011-ben asztali problémát megoldó recept sokkal messzebbre jutott, mint azok a feltételek, amelyek igazzá tették. A mobilkliensek erre semmilyen shell-parancsot nem fogadnak el, bármit is állít a beszélgetés.
Kezelje a másolt értéket útvonalra vonatkozó hipotézisként, nem beállításként. Ha egy kisebb méret működésre bír egy átvitelt, egy nagyobb pedig megbízhatóan meghiúsul, bizonyítéka van az útvonalról; még meg kell találnia azt az összetevőt, amelynek engedélye van rá hatni. Ez a keresés általában az átjáró profiljánál vagy az alkalmazás gyártójánál ér véget, és ritkán a telefonnál.
Az átvitel megváltoztatja a választ
Ha a munkamenet IPsec helyett TLS fölött fut, az átjárón végzett TCP-szegmentálási beállítás segíthet, mert átírja a TCP-folyamokhoz hirdetett szegmensméretet. Az UDP-forgalommal semmit nem tesz, pedig abban több van a modern webből, mint az emberek gondolják. A változtatás javaslata előtt ellenőrizze az egyeztetett átvitelt, és a jegyben nevezze meg, melyik átvitelre számít hatással.
Az útvonal-MTU felderítés azért létezik, hogy a végpontok kitalálás helyett megtanulják a valódi határt. A visszajelzés blokkolása és egy kis méret fixálása működő nagy átvitelt vált fel állandó, rejtett költségre minden kapcsolatnál.
Mit kérdezzen az átjáró csapatától
Három dolgot kérjen: az attribútum pontos nevét és hatókörét, hogy a telepített kliensek betartják-e, és hogy melyik átvitelt egyeztette a munkamenet. Az egy csoportházirendre alkalmazott változtatás tesztelhető; a globális szerkesztés nem, és kockázatot tol azokra a felhasználókra, akik soha nem jelentettek problémát. Kérje a dokumentumhivatkozást is, mert az attribútumnevek kiadások között változnak.
Utána változtasson egy dolgot, és tesztelje újra az eredeti meghiúsuló műveletet, ne egy sebességteszt-letöltést. Őrizze meg az előtte-utána feljegyzést a kliensverzióval és a hozzáférési hálózattal, hogy a következő jelentés összehasonlítható legyen, ne pedig újratárgyalt.
Ha a művelet az eredeti méreten is meghiúsul, nem a méret volt az ok. Ezt a következtetést is jegyezze fel, hogy a következő ember ne nyissa ki újra ugyanazt a hipotézist.