pf-kill switch i macOS til OpenVPN: regler, der fejler lukket

På macOS er en kill switch kun så god som den pakkefilterpolitik, der ligger bag den, og pf er den del, der håndhæver politikken. Politikken skal gøre to modsatte ting på én gang: lade klienten nå sin server, så en tunnel kan eksistere, og stoppe alt andet fra at gå direkte ud. De fleste offentliggjorte regelsæt klarer det andet og glemmer det første, så maskinen mister forbindelsen i stedet for at vinde beskyttelse. Den version, der virker, navngiver endepunktet, resolveren og tunnelen, og intet mere.

Hvad et pakkefilter kan afgøre, og hvad det ikke kan

pf kigger på grænseflader, adresser, protokollnumre og porte, og der stopper det. Det finder aldrig ud af, hvilken proces der åbnede en socket, så en tilladelse skrevet til ét program bliver en tilladelse for hvert program, der kan nå samme port. Det er sådan en rundhåndet UDP-undtagelse gør en kill switch tilbage til et almindeligt netværk. Applikationsbevidst blokering hører til klienten eller en systemudvidelse, ikke til denne fil.

Filteret opretter heller ikke ruter. Når klienten falder, kan standardruten stadig pege på en død tunnel, og pf gør det til blokerede pakker i stedet for et stille fald tilbage til Wi-Fi. Blokeringen er det tilsigtede resultat, ikke en fejl, man skal rute uden om.

Rækkefølgen afgør udfaldet oftere, end reglens tekst gør. Uden quick bliver pf ved med at evaluere efter et match, og den sidste matchende regel vinder, så en bred tilladelse nær bunden tilsidesætter de omhyggelige undtagelser ovenover. At markere tilladelserne med quick gør det første match endeligt, hvilket en politikforfatter normalt mener.

Læs fakta om grænseflade og endepunkt først

Trådløse grænseflader nummereres ikke ens på hver Mac, og tunneleenheden får et nummer, der kan ændre sig mellem opstarter. En regel, der navngiver en enhed, der ikke findes, fejler ved parsing, hvilket er højt og let at fange, mens en regel, der navngiver den forkerte eksisterende enhed, parses rent og tillader trafik, du ville stoppe.

Indsaml fakta, mens klienten er tilsluttet, for tunneleenheden findes kun da. Du skal bruge grænsefladen, der holder standardruten, enheden klienten oprettede, og adressen og porten på den server, den ringer til. Den sidste værdi er den, de fleste regelsæt udelader, og at udelade den er grunden til, at et kopieret regelsæt blokerer sin egen tunnel.

route -n get default
ifconfig -l
scutil --nc list

Den første kommando navngiver den grænseflade, der vinder lige nu, den anden viser hver enhed, kernen kender, og den tredje viser de VPN-konfigurationer, systemet kan starte. Skriv svarene ned, og læs derefter serveradressen og porten fra klientens egen konfiguration.

Skriv regelsættet omkring tunnelens vej

Filen nedenfor afviser som standard og genindfører fem ting: loopback, tunneleenheden, klientens vej til sin server, den resolver der bruges, før tunnelen findes, og de to udvekslinger, der holder et trådløst link brugbart. Grænsefladenavne og serveradressen kommer fra din maskine, så erstat de værdier, du bekræftede. Tunnelnummeret vil heller ikke passe med dit.

set skip on lo0
block all
pass out quick on utun0
# maintain this line when the server address changes
pass out quick on en1 inet proto udp to 203.0.113.10 port 1194
# only the resolver the client uses before the tunnel exists
pass out quick on en1 inet proto udp to 192.0.2.53 port 53
pass out quick on en1 inet proto udp from any port 68 to any port 67
pass out quick on en1 inet proto udp to 224.0.0.251 port 5353

DHCP-linjen findes, fordi en Mac beder om en adresse, før den har en, så anmodningen forlader port 68 mod port 67 uden en brugbar kildeaddresse. Multicast-linjen lader systemet vurdere, om det trådløse link er værd at bruge, og at fjerne den giver en maskine, der melder ingen forbindelse på et fungerende netværk. Endepunktslinjen er det, der lader OpenVPN nå sin server overhovedet; uden den dropper block all det ydre håndtryk, og tunnelen rejser sig aldrig. Resolverlinjen er snævrere end en generel DNS-tilladelse, fordi den navngiver én adresse og én port i stedet for hver forespørgsel, maskinen laver.

De endepunkts- og resolverundtagelser er de to, der skal findes; alt andet forbliver blokeret. Hvis klienten ringer til en bogstavelig adresse, så fjern resolverlinjen og behold endepunktslinjen. Hvis serveradressen ændrer sig, opdater den linje før næste forbindelse, eller fyld en pf-tabel fra klientens egen hook og match tabellen i stedet.

Tag tunnelen ned, og genstart derefter

Parse før indlæsning, for en syntaksfejl er billig i en tør kørsel og dyr i en fjernsession. Indlæs derefter filen, aktivér filteret, hvis det var slukket, og læs tilbage, hvad der faktisk er i kraft. Tilbagelæsningen er ikke ceremoni: et andet anker kan tilføje regler, du ikke har skrevet, så sammenlign det udskrevne sæt med din fil.

sudo pfctl -n -v -f /etc/pf.conf
sudo pfctl -f /etc/pf.conf
sudo pfctl -e
sudo pfctl -s rules
sudo pfctl -s Anchors
sudo pfctl -a <anchor> -s rules
sudo pfctl -s info

Med reglerne indlæst tager du tunnelen ned og prøver at indlæse en side. Almindelig trafik bør stoppe, og den bør stadig være stoppet, efter maskinen sover og vågner, for netop den overgang er, hvor forældet tilstand siver tilbage. Genopret forbindelsen, og bekræft, at trafikken fortsætter uden at røre regelsættet. Hvis en browser stadig virker med tunnelen nede, er en regel bredere, end du troede, og tilbagelæsningen navngiver den normalt.

Genstarten er den del, folk springer over. macOS læser /etc/pf.conf ved opstart, men at læse filen er ikke det samme som at aktivere filteret, så et regelsæt, der virker nu, kan være inaktivt efter en genstart. Kør derefter sudo pfctl -s info, og bekræft, at statuslinjen melder filteret som aktiveret.

Hold udgangen og genstartsvejen ærlig

Et regelsæt, der blokerer alt, kan også låse dig ude af en maskine, du administrerer eksternt. Rediger fra en lokal session, når du kan, behold den forrige fil ved siden af den nye, og kend tilbagerulningen, før du får brug for den. Kommandoerne nedenfor deaktiverer filteret og genindlæser den kopi, du gemte, og det er sekvensen til en konsol, ikke over den tunnel, du lige har skåret. En tilbagerulning på fem sekunder slår en smart regel hver gang.

sudo pfctl -d
sudo pfctl -f /etc/pf.conf.previous
sudo pfctl -s rules

Vedholdenhed kræver en launch daemon, der kører pfctl -e og indlæser din fil ved opstart. Behandl den som enhver anden privilegeret opgave: absolutte stier, en log, du kan læse bagefter, og en test på en maskine, du fysisk kan nå. En daemon, der fejler lydløst, efterlader maskinen ubeskyttet og normalt seende ud.

Dokumentér hullerne, start med en anden VPN-klient, der opretter sin egen tunneleenhed. Dine regler navngiver én tunnelgrænseflade, så en anden forbliver blokeret eller bliver ramt af en bred regel, der tilføjes senere. Tethering- og hotspot-grænseflader dukker kun op nogle gange og fortjener samme note. Ingen af de huller er en grund til at springe politikken over; de er de betingelser, hvorunder den stadig holder.