pf-ŝaltilo de macOS por OpenVPN: reguloj kiuj fermas

En macOS, ŝaltilo de sekureco estas nur tiel bona kiel la politiko de paketa filtro malantaŭ ĝi, kaj pf estas la parto, kiu plenumas tiun politikon. La politiko devas fari du kontraŭajn aferojn samtempe: lasi la klienton atingi sian servilon por ke tunelo povu ekzisti, kaj haltigi ĉion alian de rekta eliro. Plej multaj publikigitaj regul-aroj sukcesas pri la dua kaj forgesas la unuan, do la maŝino perdas konektecon anstataŭ gajni protekton. La versio, kiu funkcias, nomas la finpunkton, la solvilon kaj la tunelon, kaj nenion pli.

Kion paketa filtro povas decidi, kaj kion ĝi ne povas

pf rigardas interfacojn, adresojn, protokolnumerojn kaj pordojn, kaj ĝi haltas tie. Ĝi neniam ekscias, kiu procezo malfermis soketon, do permeso skribita por unu programo fariĝas permeso por ĉiu programo, kiu povas atingi la saman pordon. Tiel malavara UDP-escepto retransformas ŝaltilon de sekureco en ordinaran reton. Aplik-konscia blokado apartenas al la kliento aŭ al sistema etendaĵo, ne al ĉi tiu dosiero.

La filtro ankaŭ ne kreas itinerajn vojojn. Kiam la kliento falas, la defaŭlta vojo povas ankoraŭ montri al morta tunelo, kaj pf ŝanĝas tion en blokitajn pakaĵojn anstataŭ silenta reiro al Wi-Fi. La blokado estas la celata rezulto, ne misfunkcio preterirenda.

La ordo decidas la rezulton pli ofte ol la teksto de la regulo. Sen quick, pf daŭre taksas post trafo kaj la lasta kongrua regulo venkas, do larĝa trapaso malsupre superregas la zorgemajn esceptojn supre. Marki la trapasojn per quick igas la unuan trafon fina, kion politik-aŭtoro kutime celas.

Legi unue la faktojn pri interfaco kaj finpunkto

Sendrataj interfacoj ne estas numeritaj same sur ĉiu Mac, kaj la tunela aparato ricevas numeron, kiu povas ŝanĝiĝi inter lanĉoj. Regulo, kiu nomas neekzistantan aparaton, fiaskas ĉe analizo, kio estas laŭta kaj facile kaptebla, dum regulo nomanta la malĝustan ekzistantan aparaton analiziĝas pure kaj permesas trafikon, kiun vi volis haltigi.

Kolektu la faktojn dum la kliento estas konektita, ĉar la tunela aparato ekzistas nur tiam. Vi bezonas la interfacon, kiu tenas la defaŭltan vojon, la aparaton kreitan de la kliento, kaj la adreson kaj pordon de la servilo, kiun ĝi vokas. Ĝuste tiun lastan valoron plej multaj regul-oj preterlasas, kaj preterlasi ĝin estas kial kopiita aro blokas sian propran tunelon.

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

La unua komando nomas la interfacon, kiu nun venkas, la dua listigas ĉiun aparaton, kiun la kerno konas, kaj la tria montras la VPN-agordojn, kiujn la sistemo povas lanĉi. Skribu tiujn respondojn, poste legu la servilan adreson kaj pordon el la propra agordo de la kliento.

Skribu la regul-aron ĉirkaŭ la tunela vojo

La dosiero sube rifuzas defaŭlte kaj re-akceptas kvin aferojn: loopback, la tunelan aparaton, la vojon de la kliento al sia servilo, la solvilon uzatan antaŭ ol ekzistas tunelo, kaj la du interŝanĝojn, kiuj tenas sendratan ligilon uzebla. Interfacaj nomoj kaj la servila adreso venas de via maŝino, do anstataŭigu la valorojn, kiujn vi konfirmis. Ankaŭ la tunela numero ne kongruos kun la via.

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

La DHCP-linio ekzistas ĉar Mac petas adreson antaŭ ol ĝi havas unu, do la peto forlasas pordon 68 al pordo 67 sen uzebla fonta adreso. La multicast-linio lasas la sistemon juĝi, ĉu la sendrata ligilo indas esti uzata, kaj forigi ĝin produktas maŝinon, kiu raportas neniun konekton en funkcianta reto. La finpunkta linio estas tio, kio lasas OpenVPN entute atingi sian servilon; sen ĝi, block all faligas la eksteran manpremon kaj la tunelo neniam leviĝas. La solvila linio estas pli mallarĝa ol ĝenerala DNS-permeso, ĉar ĝi nomas unu adreson kaj unu pordon anstataŭ ĉiu demando, kiun la maŝino faras.

Tiuj finpunkta kaj solvila esceptoj estas la du, kiuj devas ekzisti; ĉio alia restas blokita. Se la kliento vokas laŭvortan adreson, forigu la solvilan linion kaj konservu la finpunktan linion. Se la servila adreso ŝanĝiĝas, ĝisdatigu tiun linion antaŭ la sekva konekto, aŭ plenigu pf-tabelon el la propra hoko de la kliento kaj kongruigu anstataŭe la tabelon.

Mallevu la tunelon, poste restartigu

Analizu antaŭ ŝarĝado, ĉar sintaksa eraro estas malmultekosta en seka lanĉo kaj multekosta en fora seanco. Poste ŝarĝu la dosieron, ebligu la filtron se ĝi estis malŝaltita, kaj relegu, kio efektive validas. La relego ne estas ceremonio: alia ankro povas aldoni regulojn, kiujn vi ne skribis, do komparu la presitan aron kun via dosiero.

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

Kun la reguloj ŝarĝitaj, mallevu la tunelon kaj provu ŝarĝi paĝon. Ordinara trafiko devus halti, kaj ĝi devus resti haltigita post kiam la maŝino dormas kaj vekiĝas, ĉar ĝuste tiu transiro estas kie malnova stato reenŝteliĝas. Rekonektiĝu kaj konfirmu, ke trafiko rekomenciĝas sen tuŝi la regul-aron. Se retumilo ankoraŭ funkcias kun la tunelo mallevita, iu regulo estas pli larĝa ol vi pensis, kaj la relego kutime nomas ĝin.

La restartigo estas la parto, kiun homoj preterlasas. macOS legas /etc/pf.conf ĉe lanĉo, sed legi la dosieron ne samas kiel ebligi la filtron, do regul-aro, kiu funkcias nun, povas esti malaktiva post restartigo. Rulu poste sudo pfctl -s info kaj konfirmu, ke la stata linio raportas la filtron kiel ebligita.

Tenu la eliron kaj la restartigan vojon honestaj

Regul-aro, kiu blokas ĉion, ankaŭ povas ŝlosi vin ekster maŝinon, kiun vi administras fore. Redaktu el loka seanco kiam vi povas, tenu la antaŭan dosieron apud la nova, kaj sciu la revenon antaŭ ol vi bezonos ĝin. La subaj komandoj malŝaltas la filtron kaj reŝarĝas la kopion, kiun vi konservis, kaj tio estas la sinsekvo por konzolo, ne tra la tunelo, kiun vi ĵus tranĉis. Reveno en kvin sekundoj venkas inteligentan regulon ĉiufoje.

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

Daŭreco postulas lanĉan demonon, kiu rulas pfctl -e kaj ŝarĝas vian dosieron ĉe lanĉo. Traktu ĝin kiel ĉiun alian privilegian taskon: absolutaj vojoj, protokolo, kiun vi povas legi poste, kaj testo sur maŝino, kiun vi fizike povas atingi. Demono, kiu fiaskas silente, lasas la maŝinon neprotektita kaj aspektanta normale.

Dokumentu la mankojn, komencante per dua VPN-kliento, kiu kreas sian propran tunelan aparaton. Viaj reguloj nomas unu tunelan interfacon, do dua restas blokita aŭ estas kaptita de larĝa regulo aldonita poste. Tethering- kaj hotspot-interfacoj aperas nur foje kaj meritas la saman noton. Neniu el tiuj mankoj estas kialo preterlasi la politikon; ili estas la kondiĉoj, sub kiuj ĝi ankoraŭ validas.