MTU la VPN pe iPhone: stabiliți proprietarul înainte de a schimba un număr

Fiecare discuție despre dimensiunea pachetelor VPN pe iPhone ajunge să ofere aceeași comandă Mac împotriva unei interfețe numite ppp0, de obicei cu un număr atașat. Nu se transferă, și nu ar fi controlul corect nici pe Mac dacă acea interfață nu ar aparține conexiunii respective. Pe telefon, numărul aparține celui care implementează tunelul: sistemul de operare pentru un profil nativ, un furnizor de tunel de pachete pentru o aplicație, sau gateway-ul când se negociază un atribut documentat. Trei întrebări stabilesc cu care dintre aceste cazuri aveți de-a face.

Prima întrebare: ce client rulează

Un profil IKEv2 nativ, profilul Cisco IPsec încorporat și un client Cisco de la terți sunt trei implementări diferite, cu trei seturi diferite de atribute acceptate. Tipul profilului din Setări vă spune care a pornit de fapt telefonul, iar lista de aplicații vă spune dacă există vreun furnizor pe traseu. Începeți de acolo, pentru că restul deciziei decurge din asta. Dacă în listă nu apare niciun furnizor, tunelul este al sistemului de operare.

Nu deduceți implementarea de la furnizorul gateway-ului. Un headend Cisco poate închide conexiuni de la clienți care nu au în comun nimic în afară de numele furnizorului. O captură de ecran a unei versiuni vechi pe o ediție veche vă spune ce accepta acea pereche, nu ce face telefonul din mâna dumneavoastră.

A doua întrebare: cine deține valoarea

Apple expune o proprietate MTU dezvoltatorilor de tuneluri de pachete prin obiectul de setări al extensiei de rețea. Este un API pentru furnizorul care își configurează propriul tunel, nu un comutator pe care un utilizator sau un administrator îl poate acționa pe clientul instalat al altcuiva. O aplicație terță poate alege să o expună, să o ignore sau să codifice dur o valoare.

Pentru un profil nativ, sistemul de operare alege dimensiunea interfeței, iar telefonul nu expune niciun editor pentru asta. Pentru un gateway Cisco de acces la distanță există un atribut documentat pentru profilul de conexiune, iar dacă se aplică depinde de client, de ediție și de transportul negociat. Exact în acel gol dintre documentat și respectat merge greșit un număr copiat.

A treia întrebare: simptomul depinde de dimensiune

Problemele de dimensiune au o semnătură: cererile mici reușesc, încărcările mari sau răspunsurile mari se blochează, iar același serviciu funcționează pe o altă rețea de acces. Filtrarea, o limită de payload a aplicației și un server blocat pot produce o plângere similară, așa că notați operațiunea care eșuează lângă una care funcționează. Scrieți ambele cu ore și dimensiuni dacă aplicația le raportează. Fără această pereche, fiecare schimbare ulterioară este o presupunere.

Rulați același test pe Wi-Fi și pe rețeaua mobilă. O defecțiune care urmează rețeaua indică traseul; una care urmează dispozitivul indică clientul sau profilul, iar cele două au nevoie de proprietari diferiți. Folosiți același serviciu și același cont pentru ambele rulări, altfel comparația nu vă spune nimic.

De ce rețeta Mac continuă să apară

Anii de VPN-uri desktop bazate pe PPP au făcut din schimbarea dimensiunii interfeței o soluție locală legitimă, iar instrucțiunile respective au fost copiate în discuțiile mobile. Pe telefon nu există shell, nu există un astfel de nume de interfață și nu există persistență după o reconectare. O rețetă care a rezolvat o problemă de desktop în 2011 a călătorit mult mai departe decât condițiile care o făceau adevărată. Clienții mobili nu acceptă nicio comandă shell pentru asta, orice ar susține discuția.

Tratați valoarea copiată ca pe o ipoteză despre un traseu, nu ca pe o setare. Dacă o dimensiune mai mică face un transfer să funcționeze și una mai mare eșuează în mod fiabil, aveți dovezi despre traseu; tot trebuie să găsiți componenta care are voie să acționeze asupra lui. Căutarea se termină de obicei la profilul gateway-ului sau la furnizorul aplicației, și rareori la telefon.

Transportul schimbă răspunsul

Dacă sesiunea rulează pe TLS în loc de IPsec, o ajustare a segmentării TCP pe gateway poate ajuta, pentru că rescrie dimensiunea de segment anunțată pentru fluxurile TCP. Nu face nimic pentru traficul UDP, care acoperă mai mult din web-ul modern decât se așteaptă oamenii. Verificați transportul negociat înainte de a propune schimbarea și numiți în tichet pe care transport vă așteptați să afecteze.

Descoperirea MTU de traseu există ca punctele terminale să afle limita reală în loc să ghicească. Blocarea feedback-ului și codificarea dură a unei dimensiuni mici schimbă un transfer mare funcțional pe un cost permanent și ascuns la fiecare conexiune.

Ce să întrebați echipa gateway-ului

Cereți trei lucruri: numele exact al atributului și sfera lui, dacă clienții implementați îl respectă și ce transport a negociat sesiunea. O schimbare aplicată unei singure politici de grup este testabilă; o editare globală nu este, și mută riscul asupra utilizatorilor care nu au raportat niciodată o problemă. Cereți și referința documentului, pentru că numele atributelor se schimbă între ediții.

Apoi schimbați un singur lucru și retestați operațiunea originală care eșuează, nu o descărcare de test de viteză. Păstrați înregistrarea înainte și după împreună cu versiunea clientului și rețeaua de acces, ca raportul următor să poată fi comparat în loc de a fi rediscutat.

Dacă operațiunea eșuează în continuare la dimensiunea originală, dimensiunea nu a fost cauza. Notați și această concluzie, ca următoarea persoană să nu redeschidă aceeași ipoteză.