Mac PF VPN-lås: ein nettstadspolicy, ikkje ein funksjon du kan levera

Det fungerer på Mac-en din, så det ser ut som noko du kan gi til brukarar. Den føresetnaden er det første du må sleppa. Apple sin TN3165 seier klart at Packet Filter ikkje er eit støtta API for allment distribuerte produkt, og det rammar inn privilegert, kontrollert nettstadadministrasjon som det rimelege tilfellet. Ein VPN-lås bygd på PF er derfor ein lokal driftspolicy med ein eigar, ikkje ein funksjon du kan levera inne i ein app.

PF er ikkje ein pakkeflate

Skilnaden er ikkje akademisk. Eit distribuert produkt som er avhengig av PF, arvar kvar endring Apple gjer i det, kvar konflikt med eit anna verktøy som òg skriv reglar, og inga støtteforplikting om at ordninga vil halda fram med å virka. Ein nettstad som administrerer sine eigne maskinar, har eit anna tilhøve: han kan dokumentera avhengnaden, testa han mot kvar OS-utgåve og godta vedlikehaldet.

Nokre installasjonsråd kryssar ei grense som er verd å namngi. Å skriva over heile systemregelsettet for å få eitt anker til å lasta, redigera Apples systemoppstartskonfigurasjon eller slå av System Integrity Protection er ikkje akseptable krav for ein gjenbrukbar oppskrift. Viss ein publisert rettleiar treng noko av dette, skildrar han eit laboratorium, ikkje ein policy som kan rullast ut.

Skriv utgangsintensjonen før syntaksen

Avgjer kva som er tillate før du vel eitt einaste nøkkelord. Tre vegar må vanlegvis finnast: VPN-klienten sin eigen transport til serveren sin, den verna applikasjonstrafikken inne i tunnelen, og alt oppsett eller lokale tenester som faktisk treng ein direkte veg.

Gi kvart foreslått unntak ein destinasjon, ein transport og ein eigar. Å tillata alle portar til eitt endepunkt tillèt langt meir enn den eine transporten tunnelen brukar, og den ekstra eksponeringa oppstår utan at nokon har avgjort at det skal vera slik. Å tillata ein offentleg resolver er den same fella i ein venlegare drakt: han skaper ein direkte DNS-veg sjølv når tunnelen er nede, så namneoppslag lek òg.

Den nyttige testen for eit unntak er om du kan namngi personen som bad om det, og feilen det hindrar. Viss ingen av svara finst, er regelen truleg ein omveg rundt ein feilkonfigurasjon som elles ville halda seg usynleg.

utun-nummer er ikkje ein identitet

MacOS lagar tunnelgrensesnitt som utun-einingar, og nummeret som blir tildelt VPN-en din, er ikkje stabilt på tvers av omstartar, gjenoppkoplingar eller tilstadeveret av ein annan klient. Ein regel som listar opp fleire gjetta nummer, er ikkje ein policy; det er eit augeblinksbilete av ein ettermiddag.

Forankra regelen i noko som identifiserer den tiltenkte leverandøren: adresseplanen tunnelen tildeler, prosessen som eig grensesnittet, eller ein konfigurasjon VPN-klienten sjølv vedlikeheld. Deretter registrerer du korleis den identifikasjonen verkar, fordi personen som går gjennom regelen om eitt år, ikkje vil ha skal-historia di.

Gjer den lasta policyen tilskrivbar

Eit ankernamn ordnar reglar; det beviser ikkje at den effektive policyen er den du meinte. Prioritet mellom anker, reglar som annan programvare har lasta, og eksisterande tilstand kan alle endra resultatet. Gå gjennom det effektive settet saman med alle andre som eig PF på den maskinen, og dokumenter eigarskapet på same staden som konfigurasjonen. To eigarar som redigerer ulike anker med ulike føresetnader, er den vanlege måten ein lås utviklar eit hol på.

Hald regelverket i den støtta konfigurasjonsvegen til nettstaden, versjoner det, og noter kva macOS-utgåver som vart testa. Ei endring som blir brukt for hand og hugsa av éin person, er ikkje vedlikehalden infrastruktur, uansett kva filhovudet seier.

Test overgangane, ikkje den tilkopla tilstanden

Eit skjermbilete teke medan tunnelen er oppe, beviser nesten ingenting. Gå gjennom tilstandane i staden: oppstart før noka tilkopling, ein fungerande tunnel, ein tunnel som fell utan varsel, ei medviten fråkopling og ei flytting frå Wi-Fi til eit hotspot. Kvar tilstand har sitt eige svar, og dei interessante er feila, ikkje den lukkelege vegen.

I kvar tilstand registrerer du kva som med vilje er tilgjengeleg. Sjekk IPv4 og IPv6 kvar for seg, test namneoppslag, og ta med ein flyt som allereie var etablert før overgangen, sidan eksisterande tilkoplingar ikkje alltid følgjer den nye policyen. Ein nettlesar som feilar medan tunnelen er nede, er eitt datapunkt, ikkje bevis for at alle andre vegar er blokkerte.

Til slutt: hald ein gjenopprettingsmetode som ikkje er avhengig av nettverksvegen du endrar. Ein kjend god konfigurasjon på lokal lagring og ein dokumentert måte å lasta han på gjer ein lås til ein policy; utan dei låser éin dårleg revisjon administratoren ute frå maskinen som skulle vernast.