macOS:ssa turvakytkin on vain niin hyvä kuin sen takana oleva pakettisuodattimen käytäntö, ja pf on se osa, joka sitä käytäntöä valvoo. Käytännön on tehtävä kaksi vastakkaista asiaa yhtä aikaa: päästettävä asiakas palvelimelleen, jotta tunneli voi olla olemassa, ja estettävä kaikkea muuta lähtemästä suoraan. Useimmat julkaistut sääntöjoukot hoitavat toisen ja unohtavat ensimmäisen, joten kone menettää yhteyden sen sijaan, että saisi suojaa. Toimiva versio nimeää päätepisteen, ratkaisijan ja tunnelin, eikä mitään muuta.

Mitä pakettisuodatin voi päättää ja mitä ei

pf katsoo rajapintoja, osoitteita, protokollanumeroita ja portteja, ja pysähtyy siihen. Se ei koskaan opi, mikä prosessi avasi pistokkeen, joten yhdelle ohjelmalle kirjoitettu lupa muuttuu luvaksi jokaiselle ohjelmalle, joka voi päästä samaan porttiin. Näin antelias UDP-poikkeus muuttaa turvakytkimen takaisin tavalliseksi verkoksi. Sovellustietoinen esto kuuluu asiakkaalle tai järjestelmälaajennukselle, ei tälle tiedostolle.

Suodatin ei luo reittejäkään. Kun asiakas kaatuu, oletusreitti voi yhä osoittaa kuolleeseen tunneliin, ja pf muuttaa sen estetyiksi paketeiksi hiljaisen Wi-Fi-paluun sijaan. Esto on tarkoitettu tulos, ei vika, jonka kiertäisi.

Järjestys ratkaisee tuloksen useammin kuin säännön teksti. Ilman quick pf jatkaa arviointia osuman jälkeen ja viimeinen täsmäävä sääntö voittaa, joten leveä läpäisy alhaalla kumoaa ylempänä olevat huolelliset poikkeukset. Läpäisyjen merkitseminen quick-merkinnällä tekee ensimmäisestä osumasta lopullisen, mitä käytännön kirjoittaja yleensä tarkoittaa.

Lue ensin rajapinnan ja päätepisteen tiedot

Langattomia rajapintoja ei numeroida samalla tavalla joka Macissa, ja tunnelilaite saa numeron, joka voi muuttua käynnistysten välillä. Sääntö, joka nimeää olemattoman laitteen, epäonnistuu jäsennyksessä, mikä on äänekästä ja helppo havaita, kun taas väärän olemassa olevan laitteen nimeävä sääntö jäsennetään puhtaasti ja sallii liikenteen, jonka halusit pysäyttää.

Kerää tiedot, kun asiakas on yhdistetty, koska tunnelilaite on olemassa vain silloin. Tarvitset rajapinnan, jolla on oletusreitti, asiakkaan luoman laitteen sekä palvelimen osoitteen ja portin, johon se soittaa. Juuri tämän viimeisen arvon useimmat sääntöjoukot jättävät pois, ja pois jättäminen on syy siihen, miksi kopioitu sääntöjoukko estää oman tunnelinsa.

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

Ensimmäinen komento nimeää rajapinnan, joka nyt voittaa, toinen luettelee jokaisen ytimen tunteman laitteen, ja kolmas näyttää VPN-määritykset, jotka järjestelmä voi käynnistää. Kirjoita vastaukset muistiin ja lue sitten palvelimen osoite ja portti asiakkaan omasta määrityksestä.

Kirjoita sääntöjoukko tunnelin reitin ympärille

Alla oleva tiedosto kieltää oletuksena ja päästää uudelleen läpi viisi asiaa: loopback, tunnelilaitteen, asiakkaan reitin palvelimelleen, ennen tunnelia käytetyn ratkaisijan ja kaksi vaihtoa, jotka pitävät langattoman linkin käyttökelpoisena. Rajapintojen nimet ja palvelimen osoite tulevat koneeltasi, joten korvaa vahvistamasi arvot. Tunnelin numerokaan ei vastaa omaasi.

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-rivi on olemassa, koska Mac pyytää osoitetta ennen kuin sillä on sellainen, joten pyyntö lähtee portista 68 porttiin 67 ilman käyttökelpoista lähdeosoitetta. Multicast-rivi antaa järjestelmän arvioida, kannattaako langatonta linkkiä käyttää, ja sen poistaminen tuottaa koneen, joka ilmoittaa, ettei yhteyttä ole toimivassa verkossa. Päätepisterivi on se, joka päästää OpenVPN ylipäätään palvelimelleen; ilman sitä block all pudottaa ulomman kättelyn eikä tunneli nouse koskaan. Ratkaisijarivi on kapeampi kuin yleinen DNS-lupa, koska se nimeää yhden osoitteen ja yhden portin sen sijaan, että se kattaisi jokaisen koneen tekemän kyselyn.

Nuo päätepisteen ja ratkaisijan poikkeukset ovat ne kaksi, joiden on oltava olemassa; kaikki muu pysyy estettynä. Jos asiakas soittaa kirjaimelliseen osoitteeseen, poista ratkaisijarivi ja pidä päätepisterivi. Jos palvelimen osoite muuttuu, päivitä rivi ennen seuraavaa yhteyttä, tai täytä pf-taulukko asiakkaan omasta koukusta ja täsmäytä sen sijaan taulukkoa.

Laske tunneli alas ja käynnistä sitten uudelleen

Jäsennä ennen lataamista, sillä syntaksivirhe on halpa kuivaharjoittelussa ja kallis etäistunnossa. Lataa sitten tiedosto, ota suodatin käyttöön, jos se oli pois, ja lue takaisin, mikä on todella voimassa. Takaisinluku ei ole seremoniallista: toinen ankkuri voi lisätä sääntöjä, joita et kirjoittanut, joten vertaa tulostettua joukkoa omaan tiedostoosi.

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 säännöt on ladattu, laske tunneli alas ja yritä ladata sivu. Tavallisen liikenteen pitäisi pysähtyä, ja sen pitäisi pysyä pysäytettynä myös sen jälkeen, kun kone nukkuu ja herää, koska juuri siinä siirtymässä vanhentunut tila hiipii takaisin. Yhdistä uudelleen ja vahvista, että liikenne jatkuu koskematta sääntöjoukkoon. Jos selain toimii yhä tunnelin ollessa alhaalla, jokin sääntö on laajempi kuin luulit, ja takaisinluku yleensä nimeää sen.

Uudelleenkäynnistys on se osa, jonka ihmiset ohittavat. macOS lukee /etc/pf.conf käynnistyksessä, mutta tiedoston lukeminen ei ole sama kuin suodattimen ottaminen käyttöön, joten nyt toimiva sääntöjoukko voi olla käyttämättömänä uudelleenkäynnistyksen jälkeen. Aja sen jälkeen sudo pfctl -s info ja vahvista, että tilarivi ilmoittaa suodattimen käyttöön otetuksi.

Pidä ulospääsy ja uudelleenkäynnistyksen polku rehellisinä

Sääntöjoukko, joka estää kaiken, voi myös lukita sinut ulos koneesta, jota hallinnoit etänä. Muokkaa paikallisesta istunnosta, kun voit, pidä edellinen tiedosto uuden vieressä ja tiedä paluu ennen kuin tarvitset sitä. Alla olevat komennot poistavat suodattimen käytöstä ja lataavat säilyttämäsi kopion uudelleen, ja se on konsolista ajettava sarja, ei juuri katkaisemasi tunnelin kautta. Viiden sekunnin paluu voittaa älykkään säännön joka kerta.

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

Pysyvyys vaatii launch daemonin, joka ajaa pfctl -e ja lataa tiedostosi käynnistyksessä. Kohtele sitä kuin mitä tahansa muuta etuoikeutettua työtä: absoluuttiset polut, loki, jonka voit lukea jälkeenpäin, ja testi koneella, johon pääset fyysisesti. Daemon, joka epäonnistuu hiljaisesti, jättää koneen suojaamatta ja näyttämään normaalilta.

Dokumentoi aukot, alkaen toisesta VPN-asiakkaasta, joka luo oman tunnelilaitteensa. Sääntösi nimeävät yhden tunnelirajapinnan, joten toinen pysyy estettynä tai jää myöhemmin lisätyn leveän säännön alle. Tethering- ja hotspot-rajapinnat ilmestyvät vain joskus ja ansaitsevat saman merkinnän. Mikään noista aukoista ei ole syy ohittaa käytäntöä; ne ovat ehtoja, joissa se yhä pätee.

Aiheeseen liittyvät artikkelit