VPN pe iPhone după domeniu: decideți unde are loc refuzul
NeverConnect împiedică pornirea VPN-ului; nu blochează un site. Decideți dacă refuzul aparține graniței serviciului sau unei politici gestionate.
Două cerințe sunt scrise ca o singură propoziție și apoi implementate în locuri complet diferite. „Acest site trebuie să fie accesibil doar prin VPN” este o afirmație despre admitere, iar locul ei natural este rețeaua din fața serviciului. „Acest iPhone nu trebuie să contacteze niciodată direct acel domeniu” este o afirmație despre dispozitiv, iar doar o politică de client gestionată o poate exprima. Decideți pe care o aveți de fapt înainte de a deschide un editor de profiluri.
Două cerințe care sună identic
Luați gazda ilustrativă records.corp.example. În cazul admiterii o publicați doar către adrese din spatele VPN-ului, astfel încât o încercare directă de pe un telefon în rețeaua celulară eșuează în rețea, în timp ce aceeași cerere prin tunel reușește și încă solicită o autentificare reală în cont. În cazul dispozitivului, telefonul poate ajunge la internetul public, așa că gazda se rezolvă și răspunde oricui, iar singurul loc unde încercarea poate fi oprită este dispozitivul. Serviciul nu poate aplica o regulă pentru o cerere care nu ajunge niciodată la el.
Citirea greșită a cerinței se manifestă ca o implementare concretă. Înregistrarea rămâne publică, operatorul crede că VPN-ul este obligatoriu, iar un audit al unei încercări celulare arată că cererea nu a intrat niciodată în tunel. Nimic din jurnale nu pare stricat, pentru că nimic nu a fost blocat.
Citiți literal acțiunile de evaluare
Mecanismul la cerere are două straturi distincte de acțiuni, iar confundarea lor produce cea mai mare parte a confuziei aici. Acțiunea regulii exterioare decide ce se întâmplă cu tunelul când regula se potrivește, iar acțiunea de evaluare a conexiunii decide ce se întâmplă cu o potrivire de nume de gazdă în interiorul unei reguli de evaluare. Referința Never Connect a Apple descrie doar al doilea strat.
| Layer | Action | What it controls |
|---|---|---|
| Outer rule | connect | Bring the tunnel up when the rule matches |
| Outer rule | disconnect | Tear the tunnel down when the rule matches |
| Outer rule | evaluateConnection | Run a hostname evaluation instead of acting directly |
| Outer rule | ignore | Leave the current tunnel state alone |
| Connection evaluation | connectIfNeeded | Start the tunnel when the hostname cannot be resolved |
| Connection evaluation | neverConnect | Do not start the tunnel for that match |
neverConnect este valoarea citită greșit cel mai des, pentru că numele sugerează o blocare. Ea guvernează pornirea tunelului pentru un nume de gazdă potrivit, nu permisiunea telefonului de a ajunge la un nume, așa că o intrare Never Connect nu este o blocare de domeniu. A o numi astfel într-un document de proiectare este modul în care o implementare este aprobată cu o graniță de aplicare pe care nu o are.
Când serviciul este al dumneavoastră, aplicați la graniță
Restrângerea admiterii înseamnă publicarea numelui doar acolo unde calea VPN poate ajunge, apoi testarea faptului că calea dorită funcționează, iar alta nu. Acoperiți fiecare înregistrare publicată, ambele familii de adrese dacă le publicați, și orice nume intermediar sau alternativ folosit de aplicație. Un CNAME vechi care încă indică un balansator de încărcare public menține calea directă vie, oricât de îngrijită ar fi înregistrarea principală.
Aceasta protejează serviciul, nu dispozitivul. Nu împiedică telefonul să trimită o interogare DNS și nu împiedică aplicația să încerce. Dacă aceste încercări sunt acceptabile, aplicarea la graniță este alegerea mai ieftină și mai durabilă, pentru că se aplică fiecărui client, nu doar celor pe care i-ați configurat. Rezistă și unui telefon care nu a fost niciodată înregistrat.
Când telefonul nu trebuie nici măcar să încerce, aveți nevoie de o politică gestionată
Oprirea încercării necesită o politică de aplicare acceptată care acoperă aplicația sau destinațiile înainte de conectare, în timpul unei defecțiuni a tunelului și după o schimbare de rețea. Cereți furnizorului de VPN sau de gestionare a dispozitivelor să numească acea politică, să spună dacă necesită gestionare organizațională și să descrie ce altceva afectează. Un tunel pe aplicație plus o regulă la cerere nu sunt același lucru, iar o scurtătură de pe ecranul principal către o conexiune nici atât.
Testați cazul de defecțiune dezactivând tunelul și observând dacă cererea iese. Dacă iese, granița pe care ați documentat-o nu este granița pe care ați implementat-o.
Decideți cu trei întrebări
În primul rând, controlați serviciul sau doar telefonul? În al doilea rând, poate dispozitivul să folosească legitim internetul public pentru orice altceva? În al treilea rând, telefonul este gestionat și de către cine? Deținerea serviciului plus o flotă gestionată înseamnă că oricare strat este disponibil, în timp ce deținerea doar a telefonului face din politica de client singura opțiune, iar aceasta trebuie să fie acceptată.
Răspundeți la aceste trei înainte de a atinge un profil. Atunci configurația încetează să mai fie o presupunere despre ce înseamnă o casetă numită Never.