Vypínač pf v macOS pro OpenVPN: pravidla, která se zavírají

V macOS je vypínač jen tak dobrý, jak dobrá je politika paketového filtru za ním, a pf je část, která tuto politiku prosazuje. Politika musí dělat dvě protichůdné věci najednou: pustit klienta k jeho serveru, aby tunel mohl existovat, a zastavit všemu ostatnímu, aby neodcházelo přímo. Většina publikovaných sad pravidel zvládne druhou a zapomene na první, takže stroj ztratí připojení místo toho, aby získal ochranu. Verze, která funguje, pojmenuje koncový bod, resolver a tunel, a nic víc.

Co může paketový filtr rozhodnout a co ne

pf se dívá na rozhraní, adresy, čísla protokolů a porty, a tím to končí. Nikdy nezjistí, který proces otevřel socket, takže oprávnění napsané pro jeden program se stane oprávněním pro každý program, který dosáhne na stejný port. Tak se ze štědré výjimky UDP stane z vypínače zase obyčejná síť. Blokování s ohledem na aplikaci patří klientovi nebo systémovému rozšíření, ne tomuto souboru.

Filtr také nevytváří trasy. Když klient spadne, výchozí trasa může stále ukazovat na mrtvý tunel a pf to převede na blokované pakety místo tichého návratu k Wi-Fi. Blokování je zamýšlený výsledek, ne porucha, kterou je třeba obejít.

Pořadí rozhoduje o výsledku častěji než text pravidla. Bez quick pf pokračuje v hodnocení i po shodě a vyhrává poslední odpovídající pravidlo, takže široký průchod u dna přebije pečlivé výjimky nad ním. Označení průchodů jako quick udělá první shodu konečnou, což autor politiky obvykle myslí.

Nejprve si přečtěte údaje o rozhraní a koncovém bodu

Bezdrátová rozhraní nejsou na každém Macu číslována stejně a zařízení tunelu dostane číslo, které se mezi starty může změnit. Pravidlo, které pojmenuje neexistující zařízení, selže při parsování, což je hlasité a snadno zachytitelné, zatímco pravidlo pojmenující špatné existující zařízení se parsuje čistě a povolí provoz, který jste chtěli zastavit.

Sbírejte údaje, dokud je klient připojen, protože zařízení tunelu existuje jen tehdy. Potřebujete rozhraní, které drží výchozí trasu, zařízení, které klient vytvořil, a adresu a port serveru, na který se vytáčí. Právě tuto poslední hodnotu většina sad pravidel vynechává, a proto zkopírovaná sada zablokuje svůj vlastní tunel.

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

První příkaz pojmenuje rozhraní, které právě vyhrává, druhý vypíše každé zařízení, které jádro zná, a třetí ukáže konfigurace VPN, které systém umí spustit. Tyto odpovědi si zapište a potom přečtěte adresu a port serveru z vlastní konfigurace klienta.

Napište sadu pravidel kolem cesty tunelu

Soubor níže ve výchozím stavu odmítá a znovu povoluje pět věcí: loopback, zařízení tunelu, cestu klienta k jeho serveru, resolver používaný před vznikem tunelu a dvě výměny, které udržují bezdrátové spojení použitelné. Názvy rozhraní a adresa serveru pocházejí z vašeho stroje, takže dosaďte hodnoty, které jste potvrdili. Ani číslo tunelu nebude odpovídat tomu vašemu.

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

Řádek DHCP existuje proto, že Mac žádá o adresu dřív, než ji má, takže požadavek vychází z portu 68 směrem k portu 67 bez použitelné zdrojové adresy. Řádek multicast umožňuje systému posoudit, zda má smysl bezdrátové spojení používat, a jeho odebrání vytvoří stroj, který v fungující síti hlásí žádné připojení. Řádek koncového bodu je to, co umožňuje OpenVPN vůbec dosáhnout jeho serveru; bez něj block all zahodí vnější handshake a tunel nikdy nevstane. Řádek resolveru je užší než obecné oprávnění DNS, protože pojmenuje jednu adresu a jeden port místo každého dotazu, který stroj udělá.

Tyto výjimky pro koncový bod a resolver jsou dvě, které musí existovat; všechno ostatní zůstává blokované. Pokud klient vytáčí doslovnou adresu, řádek resolveru vynechte a řádek koncového bodu zachovejte. Pokud se adresa serveru změní, aktualizujte ten řádek před dalším připojením, nebo naplňte tabulku pf z vlastního hooku klienta a párujte místo toho tabulku.

Shoďte tunel a potom restartujte

Parsujte před načtením, protože syntaktická chyba je levná při zkušebním běhu a drahá ve vzdálené relaci. Potom soubor načtěte, zapněte filtr, pokud byl vypnutý, a přečtěte si, co je skutečně v platnosti. Zpětné čtení není ceremonie: jiná kotva může přidat pravidla, která jste nenapsali, takže porovnejte vytištěnou sadu se svým souborem.

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

S načtenými pravidly shoďte tunel a zkuste načíst stránku. Obyčejný provoz by měl přestat a měl by zůstat zastavený i po uspání a probuzení stroje, protože právě při tomto přechodu se vrací zastaralý stav. Připojte se znovu a potvrďte, že provoz pokračuje bez zásahu do sady pravidel. Pokud prohlížeč se shozeným tunelem stále funguje, některé pravidlo je širší, než jste mysleli, a zpětné čtení ho obvykle pojmenuje.

Restart je část, kterou lidé vynechávají. macOS čte /etc/pf.conf při startu, ale čtení souboru není totéž jako zapnutí filtru, takže sada pravidel, která teď funguje, může být po restartu neaktivní. Potom spusťte sudo pfctl -s info a potvrďte, že stavový řádek hlásí filtr jako zapnutý.

Udržujte cestu ven a restart čestné

Sada pravidel, která blokuje všechno, vás také může zamknout ze stroje, který spravujete vzdáleně. Upravujte z místní relace, kdykoli můžete, mějte předchozí soubor vedle nového a vězte cestu zpět dřív, než ji budete potřebovat. Příkazy níže vypnou filtr a znovu načtou kopii, kterou jste si nechali, a to je sled pro konzoli, ne pro tunel, který jste právě přestřihli. Návrat za pět sekund porazí chytré pravidlo pokaždé.

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

Trvalost vyžaduje launch daemon, který spouští pfctl -e a načítá váš soubor při startu. Berte ho jako každou jinou privilegovanou úlohu: absolutní cesty, log, který si potom přečtete, a test na stroji, ke kterému se fyzicky dostanete. Daemon, který tiše selže, nechá stroj nechráněný a vypadající normálně.

Zdokumentujte mezery, počínaje druhým klientem VPN, který si vytváří vlastní zařízení tunelu. Vaše pravidla pojmenovávají jedno tunelové rozhraní, takže druhé zůstává blokované nebo ho zachytí široké pravidlo přidané později. Rozhraní pro tethering a hotspot se objevují jen někdy a zaslouží si stejnou poznámku. Žádná z těchto mezer není důvod politikou pohrdnout; jsou to podmínky, za kterých stále platí.