Mac PF VPN-lås: en nettstedspolicy, ikke en funksjon du kan levere

Det fungerer på Mac-en din, så det ser ut som noe du kan gi til brukere. Den antakelsen er det første du må gi slipp på. Apples TN3165 sier klart at Packet Filter ikke er et støttet API for allment distribuerte produkter, og det rammer inn privilegert, kontrollert nettstedsadministrasjon som det rimelige tilfellet. En VPN-lås bygget på PF er derfor en lokal drifts-policy med en eier, ikke en funksjon du kan levere inne i en app.

PF er ikke en pakkeflate

Forskjellen er ikke akademisk. Et distribuert produkt som avhenger av PF, arver hver endring Apple gjør i det, hver konflikt med et annet verktøy som også skriver regler, og ingen støtteforpliktelse om at ordningen vil fortsette å virke. Et nettsted som administrerer sine egne maskiner, har et annet forhold: det kan dokumentere avhengigheten, teste den mot hver OS-utgivelse og godta vedlikeholdet.

Enkelte installasjonsråd krysser en grense som er verdt å navngi. Å overskrive hele systemregelsettet for å få én anker til å laste, redigere Apples systemoppstartskonfigurasjon eller deaktivere System Integrity Protection er ikke akseptable krav for en gjenbrukbar oppskrift. Hvis en publisert veiledning trenger noe av dette, beskriver den et laboratorium, ikke en policy som kan utrulles.

Skriv utgangsintensjonen før syntaksen

Bestem hva som er tillatt før du velger et eneste nøkkelord. Tre veier må vanligvis finnes: VPN-klientens egen transport til serveren, den beskyttede applikasjonstrafikken inne i tunnelen, og alt oppsett eller lokale tjenester som faktisk trenger en direkte vei.

Gi hvert foreslåtte unntak en destinasjon, en transport og en eier. Å tillate alle porter til et endepunkt tillater langt mer enn den ene transporten tunnelen bruker, og den ekstra eksponeringen oppstår uten at noen har bestemt at den skal det. Å tillate en offentlig resolver er den samme fellen i en vennligere drakt: den skaper en direkte DNS-vei selv når tunnelen er nede, så navneoppslag lekker fortsatt.

Den nyttige testen for et unntak er om du kan navngi personen som ba om det, og feilen det forhindrer. Hvis ingen av svarene finnes, er regelen sannsynligvis en omvei rundt en feilkonfigurasjon som ellers ville forbli usynlig.

utun-numre er ikke en identitet

MacOS oppretter tunnelgrensesnitt som utun-enheter, og nummeret som tildeles VPN-en din, er ikke stabilt på tvers av omstarter, gjenoppkoblinger eller tilstedeværelsen av en annen klient. En regel som lister opp flere gjettede numre, er ikke en policy; det er et øyeblikksbilde av en ettermiddag.

Forankre regelen i noe som identifiserer den tiltenkte leverandøren: adresseplanen tunnelen tildeler, prosessen som eier grensesnittet, eller en konfigurasjon VPN-klienten selv vedlikeholder. Deretter registrerer du hvordan den identifikasjonen fungerer, fordi personen som gjennomgår regelen om et år, ikke vil ha skallhistorikken din.

Gjør den lastede policyen tilskrivbar

Et ankernavn organiserer regler; det beviser ikke at den effektive policyen er den du mente. Prioritet mellom ankre, regler som annen programvare har lastet, og eksisterende tilstand kan alle endre resultatet. Gå gjennom det effektive settet sammen med alle andre som eier PF på den maskinen, og dokumenter eierskapet på samme sted som konfigurasjonen. To eiere som redigerer forskjellige ankre med forskjellige antakelser, er den vanlige måten en lås utvikler et hull.

Hold regelverket i nettstedets støttede konfigurasjonsvei, versjoner det, og noter hvilke macOS-utgivelser som ble testet. En endring som brukes for hånd og huskes av én person, er ikke vedlikeholdt infrastruktur, uansett hva filhodet sier.

Test overgangene, ikke den tilkoblede tilstanden

Et skjermbilde tatt mens tunnelen er oppe, beviser nesten ingenting. Gå gjennom tilstandene i stedet: oppstart før noen tilkobling, en fungerende tunnel, en tunnel som faller uten varsel, en bevisst frakobling og en flytting fra Wi-Fi til et hotspot. Hver tilstand har sitt eget svar, og de interessante er feilene, ikke lykkeveien.

I hver tilstand registrerer du hva som med vilje er tilgjengelig. Sjekk IPv4 og IPv6 separat, test navneoppslag, og ta med en flyt som allerede var etablert før overgangen, siden eksisterende tilkoblinger ikke alltid følger den nye policyen. En nettleser som feiler mens tunnelen er nede, er ett datapunkt, ikke bevis for at alle andre veier er blokkert.

Til slutt: hold en gjenopprettingsmetode som ikke avhenger av nettverksveien du endrer. En kjent god konfigurasjon på lokal lagring og en dokumentert måte å laste den på gjør en lås til en policy; uten dem låser én dårlig revisjon administratoren ute fra maskinen som skulle beskyttes.