MTU en iPhone-VPN: elektu la posedanton antaŭ ol ŝanĝi nombron
Tri demandoj decidas ĉu la apo, la profilo de la kluzo aŭ neniu en la telefono povas ŝanĝi la grandecon. Respondu ilin antaŭ ol prunti nombron de Mac.
Ĉiu fadeno pri la grandeco de pakaĵoj en iPhone-VPN finfine proponas la saman Mac-komandon kontraŭ interfaco nomata ppp0, kutime kun nombro aldonita. Ĝi ne transiĝas, kaj ĝi ne estus la ĝusta regilo eĉ sur la Mac krom se tiu interfaco apartenis al la koncerna konekto. En la telefono, la nombron posedas tiu, kiu implementas la tunelon: la operaciumo por denaska profilo, pakaĵtunela provizanto por apo, aŭ la kluzo kiam oni interkonsentas dokumentitan atributon. Tri demandoj decidas, kiun el tiuj kazoj vi havas.
Demando unu: kiu kliento funkcias
Denaska IKEv2-profilo, la enkonstruita Cisco IPsec-profilo kaj triaparta Cisco-kliento estas tri malsamaj implementoj kun tri malsamaj aroj de subtenataj atributoj. La profila tipo en Agordoj diras al vi, kiun la telefono efektive lanĉis, kaj la aplika listo diras ĉu entute estas provizanto sur la vojo. Komencu tie, ĉar la resto de la decido sekvas el tio. Se neniu provizanto aperas en la aplika listo, la operaciumo posedas la tunelon.
Ne deduktu la implementon el la kluzvendisto. Cisco-kapo povas fini konektojn de klientoj, kiuj dividas nenion krom la vendista nomo. Ekrankopio de malnova konstruo sur malnova eldono diras al vi, kion tiu paro subtenis, ne kion faras la telefono en via mano.
Demando du: kiu posedas la valoron
Apple elmetas MTU-ecaĵon al pakaĵtunelaj programistoj per la agorda objekto de la reta etendaĵo. Tio estas API por la provizanto, kiu agordas sian propran tunelon, ne ŝaltilo, kiun uzanto aŭ administranto povas ŝalti ĉe aliula instalita kliento. Triaparta apo povas elekti elmeti ĝin, ignori ĝin aŭ malmole kodigi valoron.
Por denaska profilo la operaciumo elektas la interfacan grandecon, kaj la telefono elmetas neniun redaktilon por ĝi. Por Cisco-kluzo de fora aliro ekzistas dokumentita atributo por la konekta profilo, kaj ĉu ĝi aplikiĝas dependas de la kliento, la eldono kaj la interkonsentita transporto. Ĝuste en tiu breĉo inter dokumentita kaj observata malsukcesas kopiita nombro.
| 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 |
Demando tri: ĉu la simptomo entute dependas de la grandeco
Grandecaj problemoj havas signaturon: malgrandaj petoj sukcesas, grandaj alŝutoj aŭ grandaj respondoj pendas, kaj la sama servo funkcias tra alia alirreto. Filtrado, limo de utila ŝarĝo de la aplikaĵo kaj blokita servilo povas produkti similan plendon, do registru la unu operacion, kiu malsukcesas, apud unu, kiu funkcias. Skribu ambaŭ kun tempoj kaj grandecoj se la apo raportas ilin. Sen tiu paro, ĉiu posta ŝanĝo estas konjekto.
Rulu la saman teston en Wi-Fi kaj en poŝtelefona reto. Fiasko, kiu sekvas la reton, indikas la vojon; unu, kiu sekvas la aparaton, indikas la klienton aŭ la profilon, kaj la du bezonas malsamajn posedantojn. Uzu la saman servon kaj la saman konton por ambaŭ ruloj, alie la komparo diras al vi nenion.
Kial la Mac-recepto daŭre aperas
Jaroj da PPP-bazitaj surtablaj VPN-oj igis ŝanĝon de interfaca grandeco laŭleĝa loka provizora solvo, kaj tiuj instrukcioj estis kopiitaj en poŝtelefonajn fadenojn. En la telefono ne estas ŝelo, nek tia interfaca nomo, nek daŭreco post rekonekto. Recepto, kiu solvis surtablan problemon en 2011, vojaĝis multe pli malproksimen ol la kondiĉoj, kiuj igis ĝin vera. Poŝtelefonaj klientoj akceptas neniun ŝelan komandon por tio, kion ajn la fadeno asertas.
Traktu la kopiitan valoron kiel hipotezon pri vojo, ne kiel agordon. Se pli malgranda grandeco igas transigon funkcii kaj pli granda fidinde malsukcesas, vi havas pruvon pri la vojo; vi ankoraŭ devas trovi la komponanton, kiu rajtas agi sur ĝin. Tiu serĉo kutime finiĝas ĉe la kluzprofilo aŭ la apvendisto, kaj malofte ĉe la telefono.
La transporto ŝanĝas la respondon
Se la seanco funkcias tra TLS anstataŭ IPsec, ĝustigo de TCP-segmentado ĉe la kluzo povas helpi, ĉar ĝi reskribas la anoncitan segmentan grandecon por TCP-fluoj. Por UDP-trafiko ĝi faras nenion, kaj tiu inkluzivas pli da la moderna reto ol homoj atendas. Kontrolu la interkonsentitan transporton antaŭ ol proponi la ŝanĝon, kaj nomu en la bileto, kiun transporton vi atendas esti tuŝita.
Trovado de voja MTU ekzistas por ke la finpunktoj lernu la veran limon anstataŭ diveni. Bloki la retrokuplon kaj malmole kodigi malgrandan grandecon interŝanĝas funkciantan grandan transigon kontraŭ konstanta, kaŝita kosto ĉe ĉiu konekto.
Kion demandi la kluzan teamon
Petu tri aferojn: la precizan atributan nomon kaj ĝian amplekson, ĉu la deplojitaj klientoj observas ĝin, kaj kiun transporton la seanco interkonsentis. Ŝanĝo aplikata al unu grupa politiko estas testebla; tutmonda redakto ne estas, kaj ĝi translokas riskon al uzantoj, kiuj neniam raportis problemon. Petu ankaŭ la dokumentan referencon, ĉar atributaj nomoj drivas inter eldonoj.
Poste ŝanĝu unu aferon kaj retestu la originalan malsukcesan operacion, ne rapidec-testan elŝuton. Konservu la antaŭan kaj postan rikordon kun la klienta versio kaj la alirreto, por ke la sekva raporto povu esti komparita anstataŭ re-prilaborita.
Se la operacio ankoraŭ malsukcesas ĉe la originala grandeco, la grandeco ne estis la kaŭzo. Registru ankaŭ tiun konkludon, por ke la sekva persono ne remalfermu la saman hipotezon.