macOS pf-noodskakelaar vir OpenVPN: reëls wat toe misluk

Op macOS is ’n noodskakelaar net so goed soos die pakkiefilterbeleid daaronder, en pf is die stuk wat daardie beleid afdwing. Die beleid moet twee teenoorgestelde dinge gelyk doen: die kliënt na sy bediener laat kom sodat ’n tonnel kan bestaan, en alles anders keer om regstreeks uit te gaan. Die meeste gepubliseerde reëlstelle kry die tweede reg en vergeet die eerste, so die masjien verloor konnektiwiteit in plaas van om beskerming te kry. Die weergawe wat werk, noem die eindpunt, die resolusie en die tonnel, en niks meer nie.

Wat ’n pakkiefilter kan besluit, en wat nie

pf kyk na koppelvlakke, adresse, protokolgetalle en poorte, en dit stop daar. Dit leer nooit watter proses ’n sok oopgemaak het nie, so ’n toestemming wat vir een program geskryf is, word ’n toestemming vir elke program wat dieselfde poort kan bereik. Dis hoe ’n ruim UDP-uitsondering ’n noodskakelaar weer in ’n gewone netwerk verander. Toepassingbewuste blokkering hoort by die kliënt of by ’n stelseluitbreiding, nie by hierdie lêer nie.

Die filter skep ook nie roetes nie. Wanneer die kliënt val, kan die verstekroete steeds na ’n dooie tonnel wys, en pf verander dit in geblokkeerde pakkette eerder as ’n stille terugval na Wi-Fi. Die blokkering is die bedoelde uitslag, nie ’n fout om om te ry nie.

Volgorde besluit die uitslag dikwels meer as die reëlteks. Sonder quick hou pf aan evalueer nadat iets pas, en die laaste passende reël wen, so ’n breë deurlaat naby die onderkant oorskryf die sorgvuldige uitsonderings daarbo. Om die deurlatings quick te merk, maak die eerste passing finaal, wat ’n beleidskrywer gewoonlik bedoel.

Lees eers die koppelvlak- en eindpuntfeite

Draadlose koppelvlakke word nie op elke Mac dieselfde genommer nie, en die tonneltoestel kry ’n nommer wat tussen herlaai kan verander. ’n Reël wat ’n toestel noem wat nie bestaan nie, misluk tydens ontleding, wat hard en maklik is om te vang, terwyl ’n reël wat die verkeerde bestaande toestel noem, skoon ontleed en verkeer toelaat wat jy wou stop.

Versamel die feite terwyl die kliënt gekonnekteer is, want die tonneltoestel bestaan net dan. Jy het die koppelvlak nodig wat die verstekroete hou, die toestel wat die kliënt geskep het, en die adres en poort van die bediener wat dit skakel. Daardie laaste waarde is die een wat die meeste reëlstelle weglaat, en om dit weg te laat, is hoekom ’n gekopieerde reëlstel sy eie tonnel blokkeer.

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

Die eerste opdrag noem die koppelvlak wat tans wen, die tweede lys elke toestel wat die kern ken, en die derde wys die VPN-konfigurasies wat die stelsel kan begin. Skryf daardie antwoorde neer en lees dan die bedieneradres en sy poort uit die kliënt se eie konfigurasie.

Skryf die reëlstel rondom die tonnelpad

Die lêer hieronder weier by verstek en laat vyf dinge weer toe: loopback, die tonneltoestel, die kliënt se pad na sy bediener, die resolusie wat voor die tonnel bestaan gebruik word, en die twee uitruilings wat ’n draadlose skakel bruikbaar hou. Koppelvlakname en die bedieneradres kom van jou masjien, so vervang die waardes wat jy bevestig het. Die tonnelnommer sal ook nie met joune ooreenstem nie.

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

Die DHCP-reël bestaan omdat ’n Mac om ’n adres vra voordat hy een het, so die versoek verlaat poort 68 na poort 67 sonder ’n bruikbare bronadres. Die multicast-reël laat die stelsel oordeel of die draadlose skakel werd is om te gebruik, en om dit te verwyder, lewer ’n masjien wat geen verbinding op ’n werkende netwerk rapporteer nie. Die eindpuntreël is wat OpenVPN in staat stel om sy bediener hoegenaamd te bereik; sonder dit laat block all die buitenste handdruk val en die tonnel kom nooit op nie. Die resolusie-reël is smaller as ’n algemene DNS-toestemming, want dit noem een adres en een poort eerder as elke navraag wat die masjien maak.

Daardie eindpunt- en resolusie-uitsonderings is die twee wat moet bestaan; alles anders bly geblokkeer. As die kliënt ’n letterlike adres skakel, laat die resolusie-reël weg en hou die eindpuntreël. As die bedieneradres verander, werk daardie reël voor die volgende verbinding by, of vul ’n pf-tabel uit die kliënt se eie haak en pas eerder die tabel.

Neem die tonnel af en herbegin dan

Ontleed voordat jy laai, want ’n sintaksfout is goedkoop in ’n droë lopie en duur in ’n afgeleë sessie. Laai dan die lêer, aktiveer die filter as dit af was, en lees terug wat werklik van krag is. Die teruglees is nie seremonie nie: ’n ander anker kan reëls byvoeg wat jy nie geskryf het nie, so vergelyk die gedrukte stel met jou lêer.

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

Met die reëls gelaai, laat sak die tonnel en probeer ’n bladsy laai. Gewone verkeer behoort te stop, en dit behoort steeds gestop te wees nadat die masjien slaap en wakker word, want daardie oorgang is waar verouderde toestand terugkruip. Herverbind en bevestig dat verkeer hervat sonder om die reëlstel aan te raak. As ’n blaaier steeds werk met die tonnel af, is ’n reël breër as wat jy gedink het, en die teruglees noem dit gewoonlik.

Die herbegin is die deel wat mense oorslaan. macOS lees /etc/pf.conf by die opstart, maar om die lêer te lees is nie dieselfde as om die filter te aktiveer nie, so ’n reëlstel wat nou werk, kan ná ’n herbegin onaktief wees. Voer daarna sudo pfctl -s info uit en bevestig dat die statuslyn die filter as geaktiveer rapporteer.

Hou die uitgang en die herbeginpad eerlik

’n Reëlstel wat alles blokkeer, kan jou ook uitsluit uit ’n masjien wat jy op afstand bestuur. Wysig vanuit ’n plaaslike sessie wanneer jy kan, hou die vorige lêer langs die nuwe een, en ken die terugdraai voordat jy dit nodig het. Die opdragte hieronder deaktiveer die filter en laai die kopie wat jy gehou het, wat die reeks is om vanaf ’n konsole te hardloop eerder as oor die tonnel wat jy pas geknip het. ’n Terugdraai van vyf sekondes klop elke keer ’n slim reël.

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

Volhoubaarheid verg ’n launch-daemon wat pfctl -e hardloop en jou lêer by die opstart laai. Behandel dit soos enige ander bevoorregte taak: absolute paaie, ’n log wat jy daarna kan lees, en ’n toets op ’n masjien wat jy fisies kan bereik. ’n Daemon wat stil misluk, laat die masjien onbeskermd en normaal lyk.

Dokumenteer die gapings, begin met ’n tweede VPN-kliënt wat sy eie tonneltoestel skep. Jou reëls noem een tonnelkoppelvlak, so ’n tweede een bly geblokkeer of word deur ’n breë reël getref wat later bygevoeg word. Tethering- en hotspot-koppelvlakke verskyn net soms en verdien dieselfde nota. Nie een van daardie gapings is ’n rede om die beleid oor te slaan nie; dit is die voorwaardes waaronder dit steeds geld.