Always On VPN sau VPN On Demand pe iPhone: ce să implementezi

On Demand deschide un tunel când regulile sale se potrivesc; Always On administrat impune acoperirea pe dispozitivele supravegheate. Un ghid pentru alegere și pentru a dovedi că funcționează.

Două iPhone-uri pot spune amândouă VPN și totuși să se comporte complet diferit. On Demand deschide un tunel când o regulă se potrivește, iar utilizatorul îl poate opri în continuare din Setări. Always On administrat menține acoperirea impusă pe un dispozitiv supravegheat, inclusiv în momentele în care tunelul nu poate urca. Alege întrebând ce trebuie să fie adevărat când utilizatorul nu face nimic, apoi testează tranzițiile, nu starea stabilă. Pașii de mai jos urmează ordinea în care un implementare eșuează cu adevărat.

Pasul 1: stabiliți ce poate impune dispozitivul

Always On este o funcție pentru dispozitive supravegheate. Dacă parcul nu este supravegheat, discuția se termină înainte de a începe, și nicio cheie payload nu transformă un telefon nesupravegheat într-unul impus. Confirmați supravegherea din partea administrării și de pe dispozitiv, apoi confirmați cine a semnat profilul.

Pe telefon: Setări, apoi General, apoi VPN și administrarea dispozitivului. Intrarea profilului îi numește proprietarul, iar un profil personal instalat manual arată diferit de unul livrat de un serviciu de administrare. Nu deduceți impunerea din numele profilului sau dintr-o etichetă de marketing a furnizorului; eticheta nu este politica platformei.

Notați trei fapte înainte de a atinge configurația: supravegheat sau nu, profil administrat sau personal, și ce client poartă tunelul. Fiecare pas ulterior depinde de acestea trei, iar transferul comportamentului de pe un telefon personal pe un profil administrat este modul în care un implementare este aprobat pe o bază greșită.

Pasul 2: citiți regulile on-demand, nu numele funcției

On Demand este o listă de reguli evaluate în ordine. Fiecare regulă numește o acțiune și condițiile care o selectează, iar condițiile sunt partea interesantă: tipul interfeței, SSID-ul Wi-Fi, sufixul de domeniu DNS sau un URL de sondare. Un set de reguli care nu se potrivește niciodată este o funcție care nu se conectează niciodată.

<key>OnDemandRules</key>
<array>
  <dict>
    <key>Action</key><string>EvaluateConnection</string>
    <key>InterfaceTypeMatch</key><string>WiFi</string>
    <key>SSIDMatch</key><array><string>Office-WiFi</string></array>
  </dict>
</array>

Citiți întregul tablou și puneți două întrebări pentru fiecare regulă: poate această condiție să fie vreodată adevărată în acest parc, și ce se întâmplă când nicio regulă nu se potrivește? Rețelele de întreprindere redenumesc punctele de acces, fuzionează SSID-uri și schimbă sufixe DNS, iar fiecare dintre aceste modificări desprinde în tăcere o regulă de realitate.

Condiția de sufix DNS este cea care greșește cel mai des pe teren, pentru că sufixul pe care un telefon îl raportează într-o rețea de oaspeți nu este cel pe care îl servește resolverul corporativ. Verificați numele pe care dispozitivul îl rezolvă efectiv înainte de a avea încredere în regulă.

Pasul 3: testați tranzițiile, nu conexiunea statică

Un tunel care este sus în timp ce vă uitați la el dovedește foarte puțin. Executați fiecare tranziție deliberat și notați ce face dispozitivul, folosind aceeași resursă privată de fiecare dată pentru ca rezultatele să fie comparabile:

  • Conectați-vă la o rețea în care o regulă ar trebui să se potrivească, apoi cereți resursa privată și confirmați că se încarcă.
  • Treceți pe rețeaua mobilă cu aplicația în fundal, apoi aduceți-o în față și repetați cererea.
  • Conectați-vă la un Wi-Fi cu portal captiv și vedeți dacă portalul este accesibil sau dacă impunerea îl blochează înainte de autentificare.
  • Dezactivați tunelul manual pe un dispozitiv supravegheat și verificați dacă revine singur și cât de repede.

Rulați aceeași listă pe un dispozitiv nesupravegheat dacă aveți unul. Diferența dintre cele două rezultate este comportamentul real al implementării, și exact asta nu arată niciodată o captură de ecran cu un tunel conectat.

Pasul 4: cunoașteți cele două forme de eșec

Acoperirea impusă eșuează blocând. Când tunelul nu se stabilește, dispozitivul pierde accesul obișnuit la internet împreună cu resursele private, iar utilizatorul trăiește un telefon online, dar incapabil să navigheze. Reconectarea și blocarea sunt observații separate, așa că înregistrați ambele în loc să tratați lipsa internetului ca un singur simptom.

On Demand eșuează prin faptul că nu se declanșează. Regula nu se potrivește, nu apare niciun tunel, iar resursa privată pur și simplu expiră. Este ușor de diagnosticat greșit ca problemă de server, pentru că clientul se comportă exact cum este configurat.

Un portal captiv stă între cele două: are nevoie de conectivitate înainte ca tunelul să existe, așa că o politică ce blochează tot până când tunelul urcă are nevoie de o cale documentată prin portal. Decideți asta în proiectare, nu la biroul de asistență.

Pasul 5: verificați, apoi exersați revenirea

Verificarea se face pe calea reală cu trafic inofensiv: cereți o resursă privată care nu trebuie să fie publică, confirmați ce adresă prezintă dispozitivul spre exterior și repetați după o repornire ca să fi văzut secvența de pornire, nu doar starea caldă.

Apoi exersați eliminarea pe un dispozitiv de test înainte de a avea nevoie de ea în producție. Eliminarea profilului readuce dispozitivul la starea anterioară, iar a ști cât durează și ce vede utilizatorul face parte din runbook. Ghidul de securitate VPN al Apple este referința pentru ce documentează platforma despre aceste politici și merită citit înainte de a scrie o configurație care afirmă mai mult decât platforma.

Păstrați cele trei fapte de la primul pas lângă setul de reguli și rezultatele testelor. Când următoarea persoană întreabă de ce un telefon se conectează într-o rețea și în alta nu, acele notițe răspund într-un minut în loc de o reconstrucție.

Articole similare