Mac PF VPN zaključavanje: politika lokacije, a ne funkcija za isporuku
Packet Filter nije podržani API za distribuirane proizvode. Dajte skupu pravila vlasnika, imenujte svaki izuzetak i testirajte prelaze.
Radi na vašem Macu, pa izgleda kao nešto što možete predati korisnicima. Ta pretpostavka je prvo čega se treba odreći. Appleov TN3165 izričito navodi da Packet Filter nije podržani API za općenito distribuirane proizvode i privilegovanu, kontrolisanu administraciju lokacije predstavlja kao razuman slučaj. VPN zaključavanje izgrađeno na PF-u je stoga lokalna operativna politika s vlasnikom, a ne funkcija koju možete isporučiti unutar aplikacije.
PF nije površina za pakovanje
Razlika nije akademska. Distribuirani proizvod koji zavisi od PF-a nasljeđuje svaku promjenu koju Apple na njemu napravi, svaki sukob s drugim alatom koji takođe piše pravila, i nikakvu obavezu podrške da će taj aranžman nastaviti raditi. Lokacija koja sama administrira svoje mašine ima drugačiji odnos: može dokumentovati zavisnost, testirati je na svakom izdanju OS-a i prihvatiti održavanje.
Neki savjeti za instalaciju prelaze granicu koju vrijedi imenovati. Prepisivanje cijelog sistemskog skupa pravila da bi se učitao jedan anchor, uređivanje Appleove sistemske konfiguracije za pokretanje ili isključivanje System Integrity Protection nisu prihvatljivi zahtjevi za recept koji se može ponovno koristiti. Ako objavljeni vodič treba bilo šta od toga, on opisuje laboratoriju, a ne politiku koja se može implementirati.
Napišite namjeru izlaza prije sintakse
Odlučite šta je dozvoljeno prije nego što odaberete ijednu ključnu riječ. Obično moraju postojati tri puta: vlastiti transport VPN klijenta do njegovog servera, saobraćaj zaštićene aplikacije unutar tunela i sve što postavljanje ili lokalne usluge zaista zahtijevaju kao direktan put.
Dajte svakom predloženom izuzetku odredište, transport i vlasnika. Dozvoljavanje svih portova prema jednoj krajnjoj tački dopušta mnogo više od jedinog transporta koji tunel koristi, a dodatna izloženost dolazi bez toga da je iko odlučio da treba da postoji. Dozvoljavanje javnog resolvera ista je zamka u prijateljskijem kostimu: stvara direktan DNS put čak i dok je tunel pao, pa pretrage imena i dalje cure.
| Path | Destination | Owner |
|---|---|---|
| VPN transport | Gateway address, one UDP port | Network team |
| Tunnel traffic | Internal prefixes | Application owner |
| Resolver exception | Named internal resolver | Security team |
Koristan test za izuzetak je možete li imenovati osobu koja ga je tražila i kvar koji sprečava. Ako nijedan odgovor ne postoji, pravilo je vjerovatno zaobilazno rješenje za pogrešnu konfiguraciju koja bi inače ostala nevidljiva.
utun brojevi nisu identitet
MacOS stvara tunelske interfejse kao utun uređaje, a broj dodijeljen vašem VPN-u nije stabilan kroz restartovanja, ponovna povezivanja ili prisustvo drugog klijenta. Pravilo koje navodi nekoliko pretpostavljenih brojeva nije politika; to je snimak jednog popodneva.
Usidrite pravilo u nešto što identifikuje predviđenog provajdera: plan adresa koji tunel dodjeljuje, proces koji posjeduje interfejs ili konfiguraciju koju sam VPN klijent održava. Zatim zapišite kako to identifikovanje funkcioniše, jer osoba koja bude pregledala pravilo za godinu neće imati vašu historiju komandi.
Učinite učitanu politiku pripisivom
Ime anchora organizuje pravila; ono ne dokazuje da je efektivna politika upravo ono što ste namjeravali. Prioritet između anchora, pravila koja je učitao drugi softver i postojeće stanje mogu promijeniti ishod. Pregledajte efektivni skup s kim god još posjeduje PF na toj mašini i dokumentujte vlasništvo na istom mjestu kao i konfiguraciju. Dva vlasnika koja uređuju različite anchore s različitim pretpostavkama uobičajen je način na koji zaključavanje dobije rupu.
Držite skup pravila u podržanoj konfiguracijskoj putanji lokacije, verzionirajte ga i zabilježite koja su macOS izdanja testirana. Promjena koja se primjenjuje ručno i koju pamti jedna osoba nije održavana infrastruktura, šta god zaglavlje datoteke govorilo.
Testirajte prelaze, a ne povezano stanje
Snimak ekrana napravljen dok je tunel aktivan ne dokazuje gotovo ništa. Umjesto toga prođite kroz stanja: pokretanje prije bilo kakve veze, tunel koji radi, tunel koji padne bez upozorenja, namjerno prekidanje veze i prelazak s Wi-Fi na hotspot. Svako stanje ima svoj odgovor, a zanimljivi su kvarovi, a ne sretan put.
U svakom stanju zabilježite šta je namjerno dostupno. Provjerite IPv4 i IPv6 odvojeno, testirajte razrješavanje imena i uključite tok koji je već uspostavljen prije prelaza, jer postojeće veze ne slijede uvijek novu politiku. Pregledač koji padne dok je tunel pao jedna je tačka podataka, a ne dokaz da je svaki drugi put blokiran.
Na kraju, zadržite metod oporavka koji ne zavisi od mrežnog puta koji mijenjate. Poznata dobra konfiguracija na lokalnom nosaču i dokumentovan način da je učitate pretvaraju zaključavanje u politiku; bez njih jedna loša revizija zaključava administratora izvan mašine koja je trebalo da bude zaštićena.