macOS pf turvaklüliti OpenVPN jaoks: reeglid, mis sulguvad

macOS-is on turvaklüliti ainult nii hea kui selle taga olev paketifiltri poliitika, ja pf on see osa, mis seda poliitikat jõustab. Poliitika peab tegema korraga kahte vastandlikku asja: laskma kliendil oma serverini jõuda, et tunnel saaks olemas olla, ja peatama kõik muu otse väljumise. Enamik avaldatud reeglistikke saab teisega hakkama ja unustab esimese, nii et masin kaotab ühenduse selle asemel, et kaitse võita. Töötav versioon nimetab lõpp-punkti, resolveri ja tunneli, ja mitte midagi enamat.

Mida paketifilter otsustada saab ja mida mitte

pf vaatab liideseid, aadresse, protokollinumbreid ja porte ning peatub seal. Ta ei saa kunagi teada, milline protsess socketi avas, seega ühele programmile kirjutatud luba muutub looks igale programmile, mis samale pordile pääseb. Nii muudab helde UDP erand turvaklüliti tagasi tavaliseks võrguks. Rakenduseteadlik blokeerimine kuulub kliendile või süsteemilaiendile, mitte sellele failile.

Filter ei loo ka marsruute. Kui klient kukub, võib vaikemarsruut endiselt surnud tunnelile osutada, ja pf muudab selle blokeeritud pakettideks, mitte vaikseks tagasilanguseks Wi-Fi-le. Blokeering on kavatsetud tulemus, mitte rike, millest mööda minna.

Järjekord otsustab tulemuse sagedamini kui reegli tekst. Ilma quick jätkab pf pärast vastet hindamist ja võidab viimane sobiv reegel, seega lai läbilase allosas tühistab ülal olevad hoolikad erandid. Läbilaskude märkimine quick-ga teeb esimese vasteen lõplikuks, mida poliitika autor tavaliselt mõtleb.

Lugege esmalt liidese ja lõpp-punkti faktid

Juhtmevabad liidesed ei ole igas Macis ühtemoodi nummerdatud ja tunneliseade saab numbri, mis võib käivituste vahel muutuda. Reegel, mis nimetab olematut seadet, ebaõnnestub parsimisel, mis on vali ja kergesti tabatav, samas kui vale olemasoleva seadme nimetamine parsitakse puhtalt ja lubab liiklust, mille te tahtsite peatada.

Koguge faktid, kui klient on ühendatud, sest tunneliseade on olemas ainult siis. Teil on vaja liidest, mis hoiab vaikemarsruuti, kliendi loodud seadet ning serveri aadressi ja porti, millele see helistab. Just selle viimase väärtuse jätavad enamik reeglistikke välja, ja selle väljajätmine on põhjus, miks kopeeritud reeglistik blokeerib omaenda tunneli.

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

Esimene käsk nimetab liidese, mis praegu võidab, teine loetleb iga seadme, mida kernel teab, ja kolmas näitab VPN-i konfiguratsioone, mida süsteem saab käivitada. Kirjutage need vastused üles ja lugege seejärel serveri aadress ja port kliendi enda konfiguratsioonist.

Kirjutage reeglistik tunneli tee ümber

Allolev fail keeldub vaikimisi ja lubab uuesti viit asja: loopback, tunneliseade, kliendi tee oma serverini, enne tunneli tekkimist kasutatav resolver ja kaks vahetust, mis hoiavad juhtmevaba ühenduse kasutatavana. Liidesenimed ja serveri aadress pärinevad teie masinast, seega asendage kinnitatud väärtused. Ka tunnelinumber ei ühti teie omaga.

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 rida on olemas, sest Mac küsib aadressi enne, kui tal see on, seega lahkub päring pordilt 68 pordi 67 suunas ilma kasutatava lähteaadressita. Multicast rida laseb süsteemil otsustada, kas juhtmevaba ühendust tasub kasutada, ja selle eemaldamine tekitab masina, mis teatab töötavas võrgus ühenduse puudumisest. Lõpp-punkti rida on see, mis laseb OpenVPN-il üldse oma serverini jõuda; ilma selleta viskab block all välimise käepigistuse ära ja tunnel ei tõuse kunagi. Resolveri rida on kitsam kui üldine DNS-luba, sest see nimetab ühte aadressi ja ühte porti, mitte iga päringut, mille masin teeb.

Need lõpp-punkti ja resolveri erandid on kaks, mis peavad olemas olema; kõik muu jääb blokeerituks. Kui klient helistab literaalsele aadressile, jätke resolveri rida välja ja hoidke lõpp-punkti rida. Kui serveri aadress muutub, värskendage seda rida enne järgmist ühendust või täitke pf tabel kliendi enda konksust ja sobitage selle asemel tabelit.

Võtke tunnel maha, seejärel taaskäivitage

Parsige enne laadimist, sest süntaksiviga on odav kuivas käivituses ja kallis kaugseansis. Seejärel laadige fail, lubage filter, kui see oli väljas, ja lugege tagasi, mis tegelikult kehtib. Tagasilugemine ei ole tseremoonia: teine ankur võib lisada reegleid, mida te ei kirjutanud, seega võrrelge prinditud komplekti oma failiga.

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

Laaditud reeglitega võtke tunnel maha ja proovige lehte laadida. Tavaline liiklus peaks seiskuma ja jääma seisma ka pärast seda, kui masin magab ja ärkab, sest just sellel üleminekul hiilib vananenud olek tagasi. Ühendage uuesti ja kinnitage, et liiklus taastub reeglistikku puutumata. Kui brauser töötab endiselt mahavõetud tunneliga, on mõni reegel laiem, kui arvasite, ja tagasilugemine nimetab selle tavaliselt.

Taaskäivitus on see osa, mille inimesed vahele jätavad. macOS loeb käivitamisel /etc/pf.conf, kuid faili lugemine ei ole sama mis filtri lubamine, seega praegu töötav reeglistik võib pärast taaskäivitust olla mitteaktiivne. Käivitage seejärel sudo pfctl -s info ja kinnitage, et olekurida teatab filtri lubatuks.

Hoidke väljapääs ja taaskäivitustee ausad

Reeglistik, mis blokeerib kõik, võib teid ka välja lukustada masinast, mida haldate kaugelt. Muutke kohalikust seansist, kui saate, hoidke eelmine fail uue kõrval ja teadke tagasipöördumist enne, kui seda vajate. Allolevad käsud lülitavad filtri välja ja laadivad uuesti teie hoiustatud koopia, ja see on järjekord konsoolist, mitte läbi tunneli, mille te just läbi lõikasite. Viie sekundi tagasipöördumine võidab iga kord nutika reegli.

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

Püsivuse jaoks on vaja launch daemonit, mis käivitab pfctl -e ja laadib teie faili käivitamisel. Käsitlege seda nagu iga teist privilegeeritud tööd: absoluutsed teed, logi, mida saate hiljem lugeda, ja test masinal, kuhu pääsete füüsiliselt. Daemon, mis ebaõnnestub vaikselt, jätab masina kaitsmata ja normaalsena näiva.

Dokumenteerige lüngad, alustades teisest VPN-kliendist, mis loob oma tunneliseadme. Teie reeglid nimetavad üht tunneliliidest, seega teine jääb blokeerituks või tabab seda hiljem lisatud lai reegel. Tetherduse ja hotspoti liidesed ilmuvad ainult mõnikord ja väärisvad sama märkust. Ükski neist lünkadest ei ole põhjus poliitikat vahele jätta; need on tingimused, mille korral see endiselt kehtib.