pf kill switch ng macOS para sa OpenVPN: mga panuntunang nagsasara

Sa macOS, ang kill switch ay kasinghusay lamang ng patakaran ng packet filter sa likod nito, at ang pf ang bahaging nagpapatupad ng patakarang iyon. Dapat gawin ng patakaran ang dalawang magkasalungat na bagay nang sabay: hayaang maabot ng kliyente ang server nito upang magkaroon ng tunnel, at pigilan ang lahat ng iba sa direktang paglabas. Karamihan sa mga nailathalang set ng panuntunan ay nagtagumpay sa pangalawa at nakakalimutan ang una, kaya nawawalan ng koneksyon ang makina sa halip na magkaroon ng proteksyon. Ang bersyong gumagana ay pinangalanan ang dulong punto, ang resolver at ang tunnel, at wala nang iba.

Ano ang maaaring pasyahan ng packet filter, at ano ang hindi

Tinitingnan ng pf ang mga interface, address, numero ng protocol at port, at doon ito tumitigil. Hindi nito alam kailanman kung aling proseso ang nagbukas ng socket, kaya ang pahintulot na isinulat para sa isang programa ay nagiging pahintulot para sa bawat programang makakaabot sa parehong port. Ganito binabalik ng isang maluwag na pagbubukod sa UDP ang kill switch sa ordinaryong network. Ang pagharang na may kamalayan sa aplikasyon ay nauukol sa kliyente o sa extension ng system, hindi sa file na ito.

Hindi rin gumagawa ng ruta ang filter. Kapag bumagsak ang kliyente, maaaring nakaturo pa rin ang default na ruta sa patay na tunnel, at ginagawa ng pf iyon na mga harang na packet sa halip na tahimik na pagbabalik sa Wi-Fi. Ang harang ang sinasadyang resulta, hindi kakulangan na dapat laktawan.

Mas madalas na ang pagkakasunod-sunod ang nagpapasya sa resulta kaysa sa teksto ng panuntunan. Kung walang quick, patuloy na nagsusuri ang pf pagkatapos ng tugma at ang huling tumutugmang panuntunan ang nananalo, kaya ang malawak na daanan sa ilalim ay nanaig sa maingat na mga pagbubukod sa itaas. Ang pagmamarka sa mga daanan ng quick ay ginagawang pangwakas ang unang tugma, at iyon ang karaniwang ibig sabihin ng may-akda ng patakaran.

Basahin muna ang mga katotohanan ng interface at dulong punto

Hindi pareho ang pagnumero ng mga wireless interface sa bawat Mac, at ang device ng tunnel ay nakakakuha ng numerong maaaring magbago sa pagitan ng mga boot. Ang panuntunang nagpangalan ng device na wala ay nabigo sa pag-parse, na maingay at madaling mahuli, samantalang ang panuntunang nagpangalan ng maling existing na device ay malinis na na-parse at pinapayagan ang trapikong nais mong pigilan.

Kolektahin ang mga katotohanan habang nakakonekta ang kliyente, dahil ang device ng tunnel ay umiiral lamang noon. Kailangan mo ang interface na may hawak ng default na ruta, ang device na ginawa ng kliyente, at ang address at port ng server na tinatawagan nito. Ang huling halagang iyon ang madalas na iniiwan ng mga set ng panuntunan, at ang pag-iwan dito ang dahilan kung bakit hinaharang ng kopyadong set ang sarili nitong tunnel.

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

Pinangalanan ng unang utos ang interface na nananalo ngayon, inililista ng pangalawa ang bawat device na alam ng kernel, at ipinapakita ng pangatlo ang mga configuration ng VPN na kayang simulan ng system. Isulat ang mga sagot na iyon, pagkatapos basahin ang address at port ng server mula sa sariling configuration ng kliyente.

Isulat ang set ng panuntunan sa paligid ng landas ng tunnel

Ang file sa ibaba ay tumatanggi bilang default at muling tumatanggap ng limang bagay: loopback, ang device ng tunnel, ang landas ng kliyente patungo sa server nito, ang resolver na ginagamit bago umiral ang tunnel, at ang dalawang pagpapalitan na nagpapanatiling magagamit ang wireless na link. Ang mga pangalan ng interface at address ng server ay galing sa iyong makina, kaya palitan ang mga halagang napatunayan mo. Hindi rin tutugma ang numero ng tunnel sa iyo.

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

Umiiral ang linyang DHCP dahil humihingi ng address ang Mac bago ito magkaroon, kaya lumalabas ang kahilingan mula sa port 68 patungo sa port 67 na walang magagamit na source address. Hinahayaan ng linyang multicast ang system na hatulan kung sulit gamitin ang wireless na link, at kapag inalis ito ay gumagawa ng makinang nag-uulat na walang koneksyon sa gumaganang network. Ang linyang dulong punto ang nagpapahintulot sa OpenVPN na maabot ang server nito; kung wala ito, itinatapon ng block all ang panlabas na handshake at hindi kailanman tumataas ang tunnel. Ang linyang resolver ay mas makitid kaysa sa pangkalahatang pahintulot sa DNS, dahil pinangalanan nito ang isang address at isang port sa halip na bawat query na ginagawa ng makina.

Ang mga pagbubukod sa dulong punto at resolver na iyon ang dalawang dapat umiral; lahat ng iba ay nananatiling harang. Kung tinatawagan ng kliyente ang literal na address, alisin ang linyang resolver at panatilihin ang linyang dulong punto. Kung nagbabago ang address ng server, i-update ang linyang iyon bago ang susunod na koneksyon, o punan ang isang table ng pf mula sa sariling hook ng kliyente at itugma ang table sa halip.

Ibaba ang tunnel, pagkatapos mag-reboot

I-parse bago mag-load, dahil ang error sa sintaks ay mura sa tuyong pagsubok at mahal sa malayong sesyon. Pagkatapos i-load ang file, i-enable ang filter kung patay ito, at basahin muli kung ano ang tunay na may bisa. Ang muling pagbasa ay hindi seremonya: maaaring magdagdag ng panuntunan ang ibang anchor na hindi mo isinulat, kaya ihambing ang nakalimbag na set sa iyong file.

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

Habang nakaload ang mga panuntunan, ibaba ang tunnel at subukang mag-load ng pahina. Dapat huminto ang ordinaryong trapiko, at dapat manatiling huminto pagkatapos matulog at magising ang makina, dahil sa pagbabagong iyon bumabalik ang lumang estado. Kumonekta muli at tiyakin na nagpapatuloy ang trapiko nang hindi hinahawakan ang set ng panuntunan. Kung gumagana pa rin ang browser habang nakababa ang tunnel, may panuntunang mas malawak kaysa inaakala mo, at karaniwang pinangalanan ito ng muling pagbasa.

Ang reboot ang bahaging nilalaktawan ng mga tao. Binabasa ng macOS ang /etc/pf.conf sa boot, ngunit ang pagbasa ng file ay hindi katulad ng pag-enable ng filter, kaya ang set ng panuntunang gumagana ngayon ay maaaring maging hindi aktibo pagkatapos ng restart. Pagkatapos ay patakbuhin ang sudo pfctl -s info at tiyakin na iniuulat ng linyang estado na naka-enable ang filter.

Panatilihing tapat ang labasan at ang landas ng restart

Ang set ng panuntunang humaharang sa lahat ay maaari ring magsara sa iyo mula sa makinang pinangangasiwaan mo nang malayuan. Mag-edit mula sa lokal na sesyon kapag kaya mo, itabi ang dating file sa tabi ng bago, at alamin ang pagbabalik bago mo ito kailanganin. Ang mga utos sa ibaba ay nagpapahinto sa filter at muling naglo-load ng kopyang itinabi mo, at iyon ang sekwensiyang patakbuhin mula sa console, hindi sa tunnel na kakatapos mo lang hiwain. Ang pagbabalik sa limang segundo ay nananaig sa matalinong panuntunan sa bawat pagkakataon.

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

Ang pagpapanatili ay nangangailangan ng launch daemon na nagpapatakbo ng pfctl -e at naglo-load ng iyong file sa boot. Tratuhin ito tulad ng anumang pribilehiyadong trabaho: ganap na mga landas, log na mababasa mo pagkatapos, at pagsubok sa makinang pisikal mong maabot. Ang daemon na tahimik na nabigo ay nag-iiwan sa makina na walang proteksyon at mukhang normal.

Idokumento ang mga puwang, simula sa ikalawang kliyente ng VPN na gumagawa ng sariling device ng tunnel. Pinangalanan ng iyong mga panuntunan ang isang interface ng tunnel, kaya ang pangalawa ay nananatiling harang o nahuhuli ng malawak na panuntunang idinagdag mamaya. Ang mga interface ng tethering at hotspot ay lumilitaw lamang kung minsan at karapat-dapat sa parehong tala. Wala sa mga puwang na iyon ang dahilan upang laktawan ang patakaran; ang mga ito ang mga kondisyon kung saan ito nananatiling may bisa.