Kill switch ar y llwybrydd sy’n cwmpasu FORWARD, OUTPUT ac IPv6

Rydych yn mewngofnodi i’r llwybrydd, yn gludo set o reolau kill switch o bost fforwm, ac mae’r LAN yn rhoi’r gorau i bori’r eiliad y bydd y twnnel yn disgyn. Ddeuddydd yn ddiweddarach mae’r llwybrydd yn dal i ddiweddaru ei gofnod DNS deinamig dros y WAN arferol, ac mae’r gliniadur ymwelwyr yn dal i gyrraedd safleoedd IPv6. Mae’r ddau ymddygiad yn normal, oherwydd bod y rheolau a gludwyd yn cwmpasu un gadwyn ac un teulu cyfeiriadau, ac nid oes yr un ohonynt yn gydradd â’r llwybrydd cyfan. Mae cerdded llwybrau’r pecynnau yn eu trefn yn dangos yn union beth a gafodd ei golli.

Dechreuwch wrth y llwybrydd, nid wrth y gliniadur

Mae polisi ar lefel llwybrydd yn apelio at swyddfa fach oherwydd bod pob dyfais y tu ôl iddo yn etifeddu’r un ymddygiad ac ni all neb anghofio galluogi switch cleient. Mae hefyd yn rhoi un man i chi brofi ar ôl pob diweddariad firmware. Yr hyn nad yw’n ei roi yw cwmpas awtomatig o draffig y llwybrydd ei hun nac o ail deulu cyfeiriadau, a dyna’r ddau fwlch y tu ôl i’r rhan fwyaf o ddefnyddiadau aflwyddiannus.

Cyn golygu unrhyw beth, nodwch dri ffaith ar bapur: enw rhyngwyneb y WAN, enw pont y LAN, a chyfeiriad a phorth y pwynt gorffen VPN. Bydd arnoch angen y tri yn y rheolau, a dyfalu enwau rhyngwyneb yw’r rheswm mwyaf cyffredin pam nad yw set o reolau sy’n edrych yn gywir yn gwneud dim.

Cerddwch y tair llwybr y gall pecyn eu cymryd

Mae traffig o gliniadur i’r rhyngrwyd yn cael ei anfon ymlaen, felly mae’n mynd drwy gadwyn FORWARD. Mae traffig y mae’r llwybrydd yn ei gynhyrchu ei hun, fel anfon DNS ymlaen, ymholiadau NTP, diweddariadau DDNS a sianel reoli’r VPN, yn mynd drwy OUTPUT. Mae traffig rheoli a gyfeirir at y llwybrydd yn cyrraedd drwy INPUT.

Felly mae kill switch a adeiledir yn FORWARD yn unig yn amddiffyn cleientiaid a dim arall. Mae’r tabl yn dangos pam mae’r gollyngiad yn yr olygfa agoriadol yn rhagweladwy yn hytrach na dirgel.

Yn y rhan fwyaf o gynlluniau nid oes angen kill switch ar INPUT, ond mae angen i chi gadw mynediad rheoli’n gweithio tra mae’r twnnel i lawr. Fel arall, y tro cyntaf y bydd y VPN yn methu, byddwch yn gyrru i’r swyddfa gyda chebl consol.

Trefnwch y rheolau fel y gall y twnnel godi o hyd

Mae kill switch sy’n gweithio yn rhestr caniatâd sy’n gorffen mewn gwrthod, a’r drefn sy’n ei wneud yn kill switch yn hytrach na bricsyn. Caniathewch loopback, pwynt gorffen y VPN, atebion ar gyfer ffrydiau sefydledig a rhyngwyneb y twnnel yn gyntaf; gwrthodwch y gweddill olaf.

iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 51820 -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o wg0 -j ACCEPT
iptables -A OUTPUT -o eth0 -j REJECT

Rhaid i’r pwynt gorffen fod yn gyfeiriad ar y pwynt hwn, nid yn enw gwesteiwr. Unwaith y bydd y gwrthodiad terfynol yn rhwystro DNS, ni ellir datrys rheol sy’n enwi enw gwesteiwr y darparwr mwyach, ac nid yw’r twnnel yn cychwyn eto ar ôl ailgychwyn. Os yw’r darparwr yn cylchdroi pwyntiau gorffen, datryswch yr enw cyn i’r polisi gael ei gymhwyso ac adnewyddwch y rheol honno o’r un sgript.

Adlewyrchwch y siâp yn FORWARD ar gyfer traffig cleientiaid, a gosodwch reol reoli benodol uwchben y gwrthodiad. Cadwch y reol reoli honno’n gul ond yn gyrraeddadwy, a’i chadarnhau drwy agor ail sesiwn SSH cyn i chi gau’r gyntaf. Mae cloi eich hun allan yn ystod newid kill switch yn ddigon cyffredin i gynllunio ar ei gyfer. Ar lwybrydd sy’n rhedeg WireGuard, mae allowed-ips y cymar yn penderfynu beth sy’n mynd i mewn i’r twnnel, tra mae’r rheolau hyn yn penderfynu beth a ganiateir i fynd allan hebddi.

Mae angen drws ffrynt ei hun ar IPv6

Mae popeth uchod yn IPv4. Os oes gan eich LAN IPv6 sy’n gweithio ac mai dim ond IPv4 y mae’r twnnel yn ei gario, mae gan bob dyfais a gwmpesir lwybr uniongyrchol i’r rhyngrwyd nad yw eich rheolau newydd yn ei weld byth. Bydd gliniadur deu-stac yn ei ffafrio’n fodlon, a bydd y kill switch ond yn edrych yn doredig i’r person sy’n profi gydag IPv4.

ip6tables -A FORWARD -i br-lan -j REJECT
ip6tables -A OUTPUT -o eth0 -j REJECT
ip6tables -A OUTPUT -o lo -j ACCEPT

Mae trefn yn bwysig yma hefyd: rhaid i’r caniatâd loopback ddod cyn y gwrthodiad WAN, neu bydd gwasanaethau lleol ar y llwybrydd yn dechrau methu mewn ffyrdd rhyfedd. Os nad yw’r rhwydwaith yn defnyddio IPv6 o gwbl, mae ei analluogi ar y WAN a’r LAN yn symlach ac nid yw’n gadael dim i’w anghofio.

Mae rhai cleientiaid VPN yn gosod llwybr diofyn ar gyfer IPv4 yn unig ac yn gadael y llwybr diofyn IPv6 presennol yn ddigyffwrdd. Gwiriwch y tabl llwybro ar ôl i’r twnnel gysylltu yn hytrach na chymryd yn ganiataol fod y cleient wedi ymdrin ag ef.

Profwch hyn gyda’r twnnel i lawr

Stopiwch y twnnel o’r llwybrydd a phrofwch o dri man yn y drefn hon:

# systemctl stop wg-quick@wg0
# ip route get 203.0.113.1
# curl -m 5 -sS http://example.com || echo blocked
# iptables -vnL OUTPUT | head
# ip6tables -vnL OUTPUT | head

Mae’ch chwiliad llwybr yn dweud wrthych ble y byddai pecyn yn mynd, ac mae’r cownteri’n dweud wrthych a yw eich rheolau wedi paru erioed. Nid yw rheol â dim pecynnau ar ôl prawf aflwyddiannus yn amddiffyn unrhyw beth, a’r achos arferol yw enw rhyngwyneb sy’n wahanol i’r un y gwnaethoch ei deipio. Profwch draffig a gynhyrchir gan y llwybrydd yn benodol, oherwydd ni all prawf o ochr y LAN arfer OUTPUT.

Penderfynwch ar y modd methu cyn i chi fod ei angen. Mae fail-closed yn cadw cleientiaid all-lein nes i’r twnnel ddychwelyd; mae fail-open yn adfer mynediad WAN arferol ac yn trechu’r pwrpas ar gyfer y traffig yr oedd ots gennych amdano. Mae llwybr blackhole i’r pwll VPN â metrig uchel yn ail haen ddefnyddiol ar gyfer cynlluniau fail-closed, gan ei fod yn goroesi pan fydd llwybr y twnnel yn diflannu yn lle cwympo’n ôl i’r llwybr diofyn.

Derbyniwch y gosodiad yn unig pan fydd cleient LAN, cais a gynhyrchir gan y llwybrydd a chais IPv6 i gyd yn methu gyda’r twnnel i lawr, ac mae’r tri yn gweithio eto unwaith y bydd i fyny.