Kill switch op de router dy’t FORWARD, OUTPUT en IPv6 dekt
In kill switch allinnich yn FORWARD lit de router frij lekke, en allinnich IPv4-regels litte IPv6 iepen. Oarderje de keatlingen en test mei de tunnel del.
Jo melde jo oan by de router, plakke in kill-switch-regelset út in forumberjocht, en it LAN hâldt op mei browsen op it momint dat de tunnel falt. Twa dagen letter fernijt de router noch hieltyd syn dynamyske DNS-record oer it gewoane WAN, en de gastlaptop berikt noch hieltyd IPv6-siden. Beide gedragingen binne normaal, want de plakte regels dekten ien keatling en ien adresfamylje, en gjin fan beide is de hiele router. Troch de pakketpaden yn oarder troch te rinnen wurdt krekt sjen litten wat mist waard.
Begjin by de router, net by de laptop
In belied op routernivo is oantreklik foar in lyts kantoar, om’t elk apparaat derachter itselde gedrach erft en nimmen ferjitte kin om in kliïntskakel yn te skeakeljen. It jout jo ek ien plak om te testen nei elke firmware-update. Wat it net jout, is automatyske dekking fan it eigen ferkear fan de router of fan in twadde adresfamylje, en dat binne de twa gatten efter de measte mislearre ynsetten.
Notearje foar’t jo eat bewurkje trije feiten op papier: de namme fan de WAN-ynterface, de namme fan de LAN-brêge, en it adres en de poarte fan it VPN-einpunt. Jo sille alle trije yn de regels nedich hawwe, en it rieden fan ynterfacenammen is de meast foarkommende reden dat in korrekt útsjende regelset neat docht.
Rin de trije paden troch dy’t in pakket nimme kin
Ferkear fan in laptop nei it ynternet wurdt trochstjoerd, dus it giet troch de FORWARD-keatling. Ferkear dat de router sels generearret, lykas DNS-trochstjoering, NTP-fragements, DDNS-updates en it VPN-kontrôlekanaal, giet troch OUTPUT. Behearferkear dat oan de router rjochte is, komt troch INPUT.
In kill switch dy’t allinnich yn FORWARD boud is, beskermet dus kliïnten en neat oars. De tabel lit sjen wêrom’t it lek yn de iepeningssêne foarsisber is en net mysterieus.
| Packet path | Example | Chain that sees it |
|---|---|---|
| LAN client to WAN or tunnel | Browser request | FORWARD |
| Router-originated | DDNS update, NTP | OUTPUT |
| Addressed to the router | SSH from the LAN | INPUT |
Yn de measte ûntwerpen hawwe jo gjin kill switch op INPUT nedich, mar jo moatte beheartagong oan ’e gong hâlde wylst de tunnel del is. Oars ride jo by de earste kear dat it VPN mislearret mei in konsoleskaabel nei it kantoar.
Oarderje de regels sa’t de tunnel noch omheech kin
In wurkjende kill switch is in tastanlist dy’t einiget yn in wegere, en de oarder makket it in kill switch yn stee fan in bakstien. Tastean earst loopback, it VPN-einpunt, antwurden foar besteande streams en de tunnel-ynterface; wiis it rest as lêste ôf.
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 REJECTIt einpunt moat op dit punt in adres wêze, gjin hostnamme. Sadree’t de lêste wegere DNS blokkearret, kin in regel dy’t de hostnamme fan de leveransier neamt net mear oplost wurde, en de tunnel start nei in werstart nea wer. As de leveransier einpunten rotearret, los de namme op foar’t it belied tapast wurdt en ferfarskje dy regel út itselde skript.
Spegelje de foarm yn FORWARD foar kliïntferkear, en pleatse in eksplisite behearregel boppe de wegere. Hâld dy behearregel smel mar berikber, en befêstigje him troch in twadde SSH-sesje te iepenjen foar’t jo de earste slute. Jinsels bûten slute by in kill-switch-wiziging is faak genôch om foar te plannen. Op in router mei WireGuard beslisse de allowed-ips fan de peer wat de tunnel yn giet, wylst dizze regels beslisse wat sûnder him út mei.
IPv6 hat syn eigen foardoar nedich
Alles hjirboppe is IPv4. As jo LAN wurkjend IPv6 hat en de tunnel ferfiert allinnich IPv4, hat elk dekt apparaat noch hieltyd in direkte rûte nei it ynternet dy’t jo nije regels nea sjogge. In dual-stack-laptop sil dy graach foarkar jaan, en de kill switch sil allinnich foar de persoan dy’t mei IPv4 testet as stikken lykje.
ip6tables -A FORWARD -i br-lan -j REJECT
ip6tables -A OUTPUT -o eth0 -j REJECT
ip6tables -A OUTPUT -o lo -j ACCEPTEk hjir jildt de oarder: de loopback-tastimming moat foar de WAN-wegere komme, oars begjinne lokale tsjinsten op de router op nuvere wizen te mislearren. As it netwurk hielendal gjin IPv6 brûkt, is it ienfâldiger om it op it WAN en it LAN út te skeakeljen en lit it neat oer om te ferjitten.
Guon VPN-kliïnten ynstallearje in standertrûte allinnich foar IPv4 en litte de besteande IPv6-standertrûte ûnferoerd. Kontrolearje de rûtetabel neidat de tunnel ferbûn is, yn stee fan oan te nimmen dat de kliïnt it regele hat.
Bewiis it mei de tunnel del
Stop de tunnel fan de router ôf en test fan trije plakken yn dizze oarder:
# 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 | headDe rûtesikerheit fertelt jo wêr’t in pakket hinne soe, en de tellers fertelle jo oft jo regels ea oerienkomd binne. In regel mei nul pakketten nei in mislearre test beskermet neat, en de gewoane oarsaak is in ynterfacenamme dy’t oars is as dy’t jo yntoetst hawwe. Test it troch de router generearre ferkear eksplisyt, om’t in test fan de LAN-kant OUTPUT net oefenje kin.
Beslis de mislearringsmodus foar’t jo him nedich hawwe. Fail-closed hâldt kliïnten offline oant de tunnel weromkomt; fail-open herstelt gewoane WAN-tagong en bedjert it doel foar it ferkear dêr’t jo jo soargen oer makken. In blackhole-rûte nei de VPN-pool mei in hege metryk is in nuttige twadde laach foar fail-closed-ûntwerpen, om’t dy oerlibbet as de tunnelrûte ferdwynt yn stee fan werom te fallen op de standert.
Akseptearje de opset pas as in LAN-kliïnt, in troch de router generearre fersyk en in IPv6-fersyk allegear mislearje mei de tunnel del, en alle trije wer wurkje as er omheech is.