Allwedd ddiogelwch pf macOS ar gyfer OpenVPN: rheolau sy’n cau

Ar macOS, nid yw allwedd ddiogelwch yn well na’r polisi hidlo pecynnau y tu ôl iddi, a pf yw’r darn sy’n gorfodi’r polisi hwnnw. Rhaid i’r polisi wneud dau beth gwrthgyferbyniol ar unwaith: gadael i’r cleient gyrraedd ei weinydd fel y gall twnnel fodoli, a rhoi stop ar bopeth arall rhag gadael yn uniongyrchol. Mae’r rhan fwyaf o setiau rheolau cyhoeddedig yn llwyddo gyda’r ail ac yn anghofio’r cyntaf, felly mae’r peiriant yn colli cysylltedd yn lle ennill amddiffyniad. Mae’r fersiwn sy’n gweithio yn enwi’r pwynt terfyn, yr atebydd a’r twnnel, a dim mwy.

Beth all hidlydd pecynnau ei benderfynu, a beth na all

Mae pf yn edrych ar ryngwynebau, cyfeiriadau, rhifau protocol a phorthladdoedd, ac yn stopio yno. Nid yw byth yn dysgu pa broses a agorodd soced, felly mae caniatâd a ysgrifennwyd ar gyfer un rhaglen yn dod yn ganiatâd i bob rhaglen sy’n gallu cyrraedd yr un porthladd. Dyna sut mae eithriad UDP hael yn troi allwedd ddiogelwch yn rhwydwaith cyffredin eto. Mae blocio sy’n ymwybodol o’r rhaglen yn perthyn i’r cleient neu i estyniad system, nid i’r ffeil hon.

Nid yw’r hidlydd yn creu llwybrau chwaith. Pan fydd y cleient yn cwympo, gall y llwybr diofyn barhau i bwyntio at dwnnel marw, ac mae pf yn troi hynny’n becynnau wedi’u blocio yn hytrach na chwympo’n dawel yn ôl i Wi-Fi. Y bloc yw’r canlyniad a fwriadwyd, nid camweithrediad i’w osgoi.

Mae trefn yn penderfynu’r canlyniad yn amlach na thestun y rheol. Heb quick, mae pf yn parhau i werthuso ar ôl cyfateb a’r rheol olaf sy’n cyfateb sy’n ennill, felly mae pas eang ger y gwaelod yn trechu’r eithriadau gofalus uwch ei ben. Mae marcio’r pasus â quick yn gwneud y cyfateb cyntaf yn derfynol, sef yr hyn y mae awdur polisi fel arfer yn ei olygu.

Darllenwch ffeithiau’r rhyngwyneb a’r pwynt terfyn yn gyntaf

Nid yw rhyngwynebau di-wifr yn cael eu rhifo’r un ffordd ar bob Mac, ac mae’r ddyfais twnnel yn cael rhif a all newid rhwng cychwyniadau. Mae rheol sy’n enwi dyfais nad yw’n bodoli yn methu wrth ddadansoddi, sy’n uchel ac yn hawdd ei dal, tra bo rheol sy’n enwi’r ddyfais bresennol anghywir yn dadansoddi’n lân ac yn caniatáu traffig y gwnaethoch chi fwriadu ei stopio.

Casglwch y ffeithiau tra bo’r cleient wedi’i gysylltu, oherwydd dim ond yno y mae’r ddyfais twnnel. Rydych chi angen y rhyngwyneb sy’n dal y llwybr diofyn, y ddyfais a grëwyd gan y cleient, a chyfeiriad a phorthladd y gweinydd y mae’n ei ddeialu. Y gwerth olaf hwnnw yw’r un y mae’r rhan fwyaf o setiau rheolau yn ei hepgor, a hepgor hwnnw yw pam mae set a gopïwyd yn blocio ei thwnnel ei hun.

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

Mae’r gorchymyn cyntaf yn enwi’r rhyngwyneb sy’n ennill ar hyn o bryd, mae’r ail yn rhestru pob dyfais y mae’r cnewyllyn yn ei gwybod, ac mae’r trydydd yn dangos y cyfluniadau VPN y gall y system eu cychwyn. Ysgrifennwch yr atebion hynny, yna darllenwch gyfeiriad a phorthladd y gweinydd o gyfluniad y cleient ei hun.

Ysgrifennwch y set rheolau o amgylch llwybr y twnnel

Mae’r ffeil isod yn gwadu’n ddiofyn ac yn ail-dderbyn pump peth: loopback, y ddyfais twnnel, llwybr y cleient i’w weinydd, yr atebydd a ddefnyddir cyn bod twnnel, a’r ddau gyfnewid sy’n cadw cyswllt di-wifr yn ddefnyddiadwy. Daw enwau rhyngwynebau a chyfeiriad y gweinydd o’ch peiriant, felly disodlwch y gwerthoedd a gadarnhaodd. Ni fydd rhif y twnnel yn cyd-fynd â’r eiddo chi chwaith.

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

Mae’r llinell DHCP yn bodoli oherwydd bod Mac yn gofyn am gyfeiriad cyn bod ganddo un, felly mae’r cais yn gadael porthladd 68 tuag at borthladd 67 heb gyfeiriad ffynhonnell defnyddiadwy. Mae’r llinell multicast yn gadael i’r system farnu a yw’r cyswllt di-wifr yn werth ei ddefnyddio, ac mae ei dynnu’n creu peiriant sy’n adrodd dim cysylltiad ar rwydwaith sy’n gweithio. Y llinell pwynt terfyn yw’r hyn sy’n gadael i OpenVPN gyrraedd ei weinydd o gwbl; hebddi, mae block all yn gollwng yr ysgwyd llaw allanol ac ni fydd y twnnel byth yn codi. Mae’r llinell atebydd yn gulach na chaniatâd DNS cyffredinol, oherwydd ei bod yn enwi un cyfeiriad ac un porthladd yn lle pob ymholiad y mae’r peiriant yn ei wneud.

Yr eithriadau pwynt terfyn ac atebydd hynny yw’r ddau y mae’n rhaid iddynt fodoli; mae popeth arall yn aros wedi’i flocio. Os yw’r cleient yn deialu cyfeiriad llythrennol, hepgorwch y llinell atebydd a chadwch y llinell pwynt terfyn. Os yw cyfeiriad y gweinydd yn newid, diweddarwch y llinell honno cyn y cysylltiad nesaf, neu llenwch dabl pf o fachyn y cleient ei hun a chyfatebwch y tabl yn lle hynny.

Tynnwch y twnnel i lawr, yna ailgychwyn

Dadansoddwch cyn llwytho, oherwydd mae gwall cystrawen yn rhad mewn prawf sych ac yn ddrud mewn sesiwn o bell. Yna llwythwch y ffeil, galluogwch y hidlydd os oedd i ffwrdd, a darllenwch yn ôl yr hyn sydd mewn grym mewn gwirionedd. Nid yw’r darllen yn ôl yn seremonïol: gall angor arall ychwanegu rheolau na ysgrifennoch, felly cymharwch y set a argraffwyd â’ch ffeil.

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

Gyda’r rheolau wedi’u llwytho, tynnwch y twnnel a cheiswch lwytho tudalen. Dylai traffig cyffredin stopio, a dylai barhau wedi stopio ar ôl i’r peiriant gysgu a deffro, oherwydd dyna’r trawsnewid lle mae cyflwr hen yn dychwelyd. Ailgysylltwch a chadarnhewch fod traffig yn ailddechrau heb gyffwrdd â’r set rheolau. Os yw porwr yn dal i weithio gyda’r twnnel i lawr, mae rheol yn ehangach nag y meddyliasoch, ac mae’r darllen yn ôl fel arfer yn ei henwi.

Yr ailgychwyn yw’r rhan y mae pobl yn ei hepgor. Mae macOS yn darllen /etc/pf.conf wrth gychwyn, ond nid yw darllen y ffeil yr un peth â galluogi’r hidlydd, felly gall set rheolau sy’n gweithio nawr fod yn anweithredol ar ôl ailgychwyn. Rhedwch sudo pfctl -s info wedyn a chadarnhewch fod y llinell statws yn adrodd bod y hidlydd wedi’i alluogi.

Cadwch y ffordd allan a’r llwybr ailgychwyn yn onest

Gall set rheolau sy’n blocio popeth eich cloi allan o beiriant rydych chi’n ei weinyddu o bell. Golygwch o sesiwn leol pan allwch, cadwch y ffeil flaenorol wrth ymyl y newydd, a gwybyddwch y ffordd yn ôl cyn i chi ei hangen. Mae’r gorchmynion isod yn analluogi’r hidlydd ac yn ail-lwytho’r copi a gadwoch, a dyna’r dilyniant i’w redeg o gonsol yn hytrach nag dros y twnnel yr ydych newydd ei dorri. Mae dychwelyd mewn pum eiliad yn curo rheol glyfar bob tro.

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

Mae parhau yn gofyn am ddaemon cychwyn sy’n rhedeg pfctl -e ac yn llwytho eich ffeil wrth gychwyn. Triniwch ef fel unrhyw swydd freiniol arall: llwybrau absoliwt, log y gallwch ei ddarllen wedyn, a phrawf ar beiriant y gallwch gyrraedd yn gorfforol. Mae daemon sy’n methu’n dawel yn gadael y peiriant heb ei amddiffyn ac yn edrych yn normal.

Dogfennwch y bylchau, gan ddechrau gydag ail gleient VPN sy’n creu ei ddyfais twnnel ei hun. Mae eich rheolau’n enwi un rhyngwyneb twnnel, felly mae’r ail yn aros wedi’i flocio neu’n cael ei ddal gan reol eang a ychwanegwyd yn ddiweddarach. Mae rhyngwynebau tethering a hotspot yn ymddangos weithiau’n unig ac yn haeddu’r un nodyn. Nid oes yr un o’r bylchau hynny’n rheswm i hepgor y polisi; nhw yw’r amodau y mae’n dal i fod yn wir o dano.