Blocare VPN PF pe Mac: o politică de site, nu o funcție livrabilă

Funcționează pe Mac-ul tău, așa că pare ceva ce poți preda utilizatorilor. Acea presupunere este primul lucru de care trebuie să scapi. Apple TN3165 afirmă clar că Packet Filter nu este un API acceptat pentru produsele distribuite în general, și tratează administrarea privilegiată și controlată a site-ului ca fiind cazul rezonabil. Prin urmare, o blocare VPN construită pe PF este o politică operațională locală cu un proprietar, nu o funcție pe care o poți livra într-o aplicație.

PF nu este o suprafață de ambalare

Distincția nu este academică. Un produs distribuit care depinde de PF moștenește fiecare modificare pe care Apple o face în el, fiecare conflict cu alt instrument care scrie și el reguli, și niciun angajament de suport că această aranjare va continua să funcționeze. Un site care își administrează propriile mașini are o relație diferită: poate documenta dependența, o poate testa pe fiecare versiune de sistem de operare și poate accepta întreținerea.

Unele sfaturi de instalare trec o linie care merită numită. Suprascrierea întregului set de reguli al sistemului pentru a încărca o singură ancoră, editarea configurației de pornire a sistemului Apple sau dezactivarea System Integrity Protection nu sunt cerințe acceptabile pentru o rețetă reutilizabilă. Dacă un ghid publicat are nevoie de vreuna dintre acestea, descrie un laborator, nu o politică implementabilă.

Scrieți intenția de ieșire înainte de sintaxă

Decideți ce este permis înainte de a alege un singur cuvânt-cheie. De obicei trebuie să existe trei căi: transportul propriu al clientului VPN către serverul său, traficul aplicației protejat în interiorul tunelului și orice configurare sau servicii locale care chiar au nevoie de o cale directă.

Dați fiecărei excepții propuse o destinație, un transport și un proprietar. Permiterea tuturor porturilor către un punct final permite mult mai mult decât singurul transport folosit de tunel, iar expunerea suplimentară apare fără ca cineva să fi decis că așa ar trebui să fie. Permiterea unui resolver public este aceeași capcană într-o haină mai prietenoasă: creează o cale DNS directă chiar și când tunelul este oprit, așa că interogările de nume încă se scurg.

Testul util pentru o excepție este dacă poți numi persoana care a cerut-o și defecțiunea pe care o previne. Dacă niciunul dintre răspunsuri nu există, regula este probabil o soluție de ocolire pentru o configurație greșită care altfel ar rămâne invizibilă.

Numerele utun nu sunt o identitate

MacOS creează interfețe de tunel ca dispozitive utun, iar numărul atribuit VPN-ului tău nu este stabil între reporniri, reconectări sau prezența altui client. O regulă care listează mai multe numere presupuse nu este o politică; este o fotografie a unei după-amiezi.

Ancorați regula în ceva ce identifică furnizorul dorit: planul de adrese pe care îl atribuie tunelul, procesul care deține interfața sau o configurație pe care o întreține clientul VPN însuși. Apoi notați cum funcționează acea identificare, pentru că persoana care va revizui regula peste un an nu va avea istoricul tău de shell.

Faceți politica încărcată atribuibilă

Un nume de ancoră organizează reguli; nu dovedește că politica efectivă este cea pe care ai intenționat-o. Precedența între ancore, regulile încărcate de alt software și starea existentă pot schimba toate rezultatul. Revizuiți setul efectiv împreună cu toți ceilalți care dețin PF pe acea mașină și documentați proprietatea în același loc cu configurația. Doi proprietari care editează ancore diferite cu presupuneri diferite este modul obișnuit în care o blocare capătă o gaură.

Țineți setul de reguli în calea de configurare acceptată a site-ului, versionați-l și notați ce versiuni macOS au fost testate. O modificare aplicată manual și ținută minte de o singură persoană nu este infrastructură întreținută, orice ar spune antetul fișierului.

Testați tranzițiile, nu starea conectată

O captură de ecran făcută cu tunelul activ nu dovedește aproape nimic. Parcurgeți stările: pornirea înainte de orice conexiune, un tunel funcțional, un tunel care cade fără avertisment, o deconectare deliberată și o trecere de la Wi-Fi la un hotspot. Fiecare stare are propriul răspuns, iar cele interesante sunt eșecurile, nu calea fericită.

În fiecare stare, notați ce este accesibil în mod intenționat. Verificați IPv4 și IPv6 separat, testați rezolvarea numelor și includeți un flux care era deja stabilit înainte de tranziție, deoarece conexiunile existente nu urmează întotdeauna noua politică. Un browser care eșuează când tunelul este oprit este un singur punct de date, nu dovada că toate celelalte căi sunt blocate.

În final, păstrați o metodă de recuperare care nu depinde de calea de rețea pe care o schimbați. O configurație bună cunoscută pe stocarea locală și o modalitate documentată de a o încărca transformă o blocare într-o politică; fără ele, o singură revizie proastă blochează administratorul în afara mașinii care trebuia protejată.