pf-kill switch i macOS for OpenVPN: reglar som feilar lukka

På macOS er ein kill switch berre så god som pakkefilterpolitikken bak han, og pf er delen som handhevar den politikken. Politikken må gjere to motsette ting samstundes: la klienten nå serveren sin slik at ein tunnel kan finnast, og stoppe alt anna frå å gå direkte ut. Dei fleste publiserte regelsetta får til det andre og gløymer det første, så maskinen mistar tilkoplinga i staden for å vinne vern. Versjonen som verkar nemner endepunktet, resolvaren og tunnelen, og ikkje noko meir.

Kva eit pakkefilter kan avgjere, og kva det ikkje kan

pf ser på grensesnitt, adresser, protokollnummer og portar, og stoppar der. Det lærer aldri kva prosess som opna ein socket, så ei tillating skriven for eitt program blir ei tillating for kvart program som kan nå same port. Det er slik eit rundhanda UDP-unntak gjer ein kill switch tilbake til eit vanleg nettverk. Applikasjonsmedviten blokkering høyrer til klienten eller ei systemutviding, ikkje til denne fila.

Filteret lagar heller ikkje ruter. Når klienten fell, kan standardruta framleis peike på ein død tunnel, og pf gjer det om til blokkerte pakkar i staden for eit stille fall tilbake til Wi-Fi. Blokkeringa er det tilsikta resultatet, ikkje ein feil ein skal rute utanom.

Rekkjefylgja avgjer utfallet oftare enn regelteksten. Utan quick held pf fram med å vurdere etter eit treff, og den siste matchende regelen vinn, så ein brei passasje nedst overstyrer dei grundige unntaka ovanfor. Å merke passasjane med quick gjer første treff endeleg, som er det ein politikkforfattar vanlegvis meiner.

Les fakta om grensesnitt og endepunkt først

Trådlause grensesnitt er ikkje nummererte likt på kvar Mac, og tunneleininga får eit nummer som kan endre seg mellom oppstartar. Ein regel som nemner ei eining som ikkje finst, feilar ved parsing, noko som er høgt og lett å fange, medan ein regel som nemner feil eksisterande eining blir parsa reint og slepp gjennom trafikk du ville stoppe.

Samle fakta medan klienten er tilkopla, for tunneleininga finst berre då. Du treng grensesnittet som held standardruta, eininga klienten laga, og adressa og porten til serveren han ringjer. Nettopp den siste verdien er den dei fleste regelsett utelèt, og å utelate han er grunnen til at eit kopiert regelsett blokkerer sin eigen tunnel.

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

Den første kommandoen nemner grensesnittet som vinn no, den andre listar kvar eining kjernen kjenner, og den tredje viser VPN-konfigurasjonane systemet kan starte. Skriv ned svara, og les deretter serveradressa og porten frå klienten si eiga konfigurasjon.

Skriv regelsettet rundt tunnelvegen

Fila nedanfor avviser som standard og slepp inn fem ting igjen: loopback, tunneleininga, vegen til klienten til serveren sin, resolvaren som blir brukt før tunnelen finst, og dei to utvekslingane som held ei trådlaus lenkje brukbar. Grensesnittnamn og serveradressa kjem frå maskinen din, så byt ut verdiane du stadfesta. Tunneltalet vil heller ikkje stemme med ditt.

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-linja finst fordi ein Mac ber om ei adresse før han har ei, så førespurnaden forlèt port 68 mot port 67 utan ei brukbar kjeldeadresse. Multicast-linja lèt systemet vurdere om den trådlause lenkja er verdt å bruke, og å fjerne ho gir ein maskin som melder inga tilkopling på eit fungerande nettverk. Endepunktlinja er det som OpenVPN når serveren sin i det heile; utan ho slepp block all det ytre handtrykket og tunnelen reiser seg aldri. Resolvarinja er smalare enn ei generell DNS-tillating, fordi ho nemner éi adresse og éin port i staden for kvar førespurnad maskinen gjer.

Dei endepunkt- og resolvarunntaka er dei to som må finnast; alt anna blir verande blokkert. Viss klienten ringjer ei bokstavleg adresse, fjern resolvarinja og hald endepunktlinja. Viss serveradressa endrar seg, oppdater den linja før neste tilkopling, eller fyll ein pf-tabell frå klienten sin eigen krok og match tabellen i staden.

Ta tunnelen ned, og start deretter på nytt

Pars før lasting, for ein syntaksfeil er billeg i ein tørrkøyring og dyr i ein fjernøkt. Last deretter fila, slå på filteret viss det var av, og les tilbake kva som faktisk er i kraft. Tilbakelesinga er ikkje seremoni: eit anna anker kan leggje til reglar du ikkje skreiv, så samanlikn det utskrivne settet med fila di.

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 reglane lasta, ta tunnelen ned og prøv å laste ei side. Vanleg trafikk skal stoppe, og han skal framleis vere stoppa etter at maskinen søv og vaknar, for det er i den overgangen gammal tilstand sig tilbake. Kopla til på nytt og stadfest at trafikken held fram utan å røre regelsettet. Viss ein nettlesar framleis verkar med tunnelen nede, er ein regel breiare enn du trudde, og tilbakelesinga nemner han vanlegvis.

Omstarten er den delen folk hoppar over. macOS les /etc/pf.conf ved oppstart, men å lese fila er ikkje det same som å slå på filteret, så eit regelsett som verkar no kan vere inaktivt etter ein omstart. Køyr deretter sudo pfctl -s info og stadfest at statuslinja melder filteret som påslege.

Hald utgangen og omstartvegen ærleg

Eit regelsett som blokkerer alt, kan også låse deg ute av ein maskin du administrerer eksternt. Rediger frå ein lokal økt når du kan, ha den førre fila ved sida av den nye, og kjenn tilbakevegen før du treng han. Kommandoane nedanfor deaktiverer filteret og lastar inn kopien du heldt på, og det er sekvensen for ein konsoll, ikkje over tunnelen du nettopp kutta. Ei tilbakeføring på fem sekund slår ein smart regel kvar gong.

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

Varigheit krev ein launch daemon som køyrer pfctl -e og lastar fila di ved oppstart. Behandle han som kvar annan privilegert jobb: absolutte stigar, ein logg du kan lese etterpå, og ein test på ein maskin du fysisk kan nå. Ein daemon som feilar stille, lèt maskinen stå uverna og sjå normal ut.

Dokumenter hòla, og start med ein annan VPN-klient som lagar si eiga tunneleining. Reglane dine nemner eitt tunnelgrensesnitt, så eit andre blir verande blokkert eller blir fanga av ein brei regel som blir lagt til seinare. Tethering- og hotspot-grensesnitt dukkar berre opp av og til og fortener same merknad. Ingen av desse hòla er grunn til å hoppe over politikken; dei er vilkåra han framleis held under.