Kill switch në router që mbulon FORWARD, OUTPUT dhe IPv6

Ju hyni në router, ngjitni një grup rregullash kill switch nga një postim forumi, dhe LAN-i ndalon së shfletuari në momentin që tuneli bie. Dy ditë më vonë routeri vazhdon të përditësojë regjistrin e tij dinamik DNS përmes WAN-it të zakonshëm, dhe laptopi i mysafirëve vazhdon të arrijë faqet IPv6. Të dyja sjelljet janë normale, sepse rregullat e ngjitura mbulonin një zinxhir dhe një familje adresash, dhe asnjëra prej tyre nuk është i gjithë routeri. Kalimi nëpër rrugët e paketave me radhë tregon saktësisht çfarë u la jashtë.

Filloni nga routeri, jo nga laptopi

Një politikë në nivel routeri është tërheqëse për një zyrë të vogël sepse çdo pajisje pas saj trashëgon të njëjtën sjellje dhe askush nuk mund të harrojë të aktivizojë një çelës në klient. Ajo ju jep gjithashtu një vend të vetëm për të provuar pas çdo përditësimi të firmware-it. Ajo që nuk ju jep është mbulim automatik i trafikut të vetë routerit ose i një familjeje të dytë adresash, dhe ato janë dy boshllëqet pas shumicës së vendosjeve të dështuara.

Përpara se të ndryshoni ndonjë gjë, shënoni tre fakte në letër: emrin e ndërfaqes WAN, emrin e urës LAN, dhe adresën dhe portin e pikës fundore të VPN. Do t’ju nevojiten të tre në rregulla, dhe hamendësimi i emrave të ndërfaqeve është arsyeja më e zakonshme pse një grup rregullash që duket i saktë nuk bën asgjë.

Kaluoni nëpër tre rrugët që mund të marrë një paketë

Trafiku nga një laptop në internet përcillet, kështu që kalon nëpër zinxhirin FORWARD. Trafiku që routeri gjeneron vetë, si përcjellja e DNS, kërkesat NTP, përditësimet DDNS dhe kanali i kontrollit të VPN, kalon nëpër OUTPUT. Trafiku i menaxhimit të drejtuar drejt routerit mbërrin përmes INPUT.

Pra, një kill switch i ndërtuar vetëm në FORWARD mbron klientët dhe asgjë tjetër. Tabela tregon pse rrjedhja në skenën hapëse është e parashikueshme dhe jo misterioze.

Në shumicën e projekteve nuk ju nevojitet një kill switch në INPUT, por duhet ta mbani aksesin e menaxhimit funksional ndërsa tuneli është i ulur. Përndryshe, herën e parë që VPN dështon shkoni në zyrë me një kabllo konsol.

Rradhitni rregullat që tuneli të mund të ngrihet përsëri

Një kill switch që funksionon është një listë lejimesh që përfundon me një refuzim, dhe radhitja është ajo që e bën kill switch dhe jo tullë. Lejoni së pari loopback, pikën fundore të VPN, përgjigjet për rrjedhat e vendosura dhe ndërfaqen e tunelit; refuzoni pjesën tjetër në fund.

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

Pika fundore në këtë moment duhet të jetë një adresë, jo një emër hosti. Pasi refuzimi përfundimtar bllokon DNS, një rregull që përmend emrin e hostit të ofruesit nuk mund të zgjidhet më, dhe tuneli nuk niset më kurrë pas një rindezjeje. Nëse ofruesi rrotullon pikat fundore, zgjidhni emrin përpara se politika të zbatohet dhe rifreskoni atë rregull nga i njëjti skript.

Pasqyroni formën në FORWARD për trafikun e klientëve, dhe vendosni një rregull të qartë menaxhimi mbi refuzimin. Mbajeni atë rregull menaxhimi të ngushtë por të arritshëm, dhe konfirmojeni duke hapur një sesion të dytë SSH përpara se të mbyllni të parin. Të mbyllesh jashtë gjatë një ndryshimi kill switch është mjaft i zakonshëm sa të planifikohet. Në një router që ekzekuton WireGuard, allowed-ips e partnerit përcaktojnë çfarë hyn në tunel, ndërsa këto rregulla përcaktojnë çfarë lejohet të dalë pa të.

IPv6 ka nevojë për derën e vet

Gjithçka më sipër është IPv4. Nëse LAN-i juaj ka IPv6 funksional dhe tuneli mbart vetëm IPv4, çdo pajisje e mbuluar ka ende një rrugë të drejtpërdrejtë drejt internetit që rregullat e reja nuk e shohin kurrë. Një laptop me dy stek do ta preferojë me kënaqësi, dhe kill switch do të duket i prishur vetëm për atë që provon me IPv4.

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

Edhe këtu radha ka rëndësi: lejimi i loopback duhet të paraprijë refuzimin e WAN, përndryshe shërbimet lokale në router fillojnë të dështojnë në mënyra të çuditshme. Nëse rrjeti nuk përdor fare IPv6, çaktivizimi i tij në WAN dhe LAN është më i thjeshtë dhe nuk lë asgjë për të harruar.

Disa klientë VPN instalojnë një rrugë të paracaktuar vetëm për IPv4 dhe e lënë rrugën e paracaktuar IPv6 ekzistuese të paprekur. Kontrolloni tabelën e rrugëzimit pasi tuneli të lidhet, në vend që të supozoni se klienti e ka rregulluar.

Provoni me tunelin e ulur

Ndaloni tunelin nga routeri dhe provoni nga tre vende në këtë radhë:

# 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

Kërkimi i rrugës ju tregon ku do të shkonte një paketë, dhe numëruesit ju tregojnë nëse rregullat tuaja ndonjëherë u përputhën. Një rregull me zero paketa pas një prove të dështuar nuk mbron asgjë, dhe shkaku i zakonshëm është një emër ndërfaqeje që ndryshon nga ai që shkruajtët. Provoni në mënyrë eksplicite trafikun e gjeneruar nga routeri, sepse një provë nga ana e LAN nuk mund të ushtrojë OUTPUT.

Vendosni modalitetin e dështimit para se t’ju duhet. Fail-closed i mban klientët jashtë linje derisa tuneli të kthehet; fail-open rikthen aksesin normal të WAN dhe prish qëllimin për trafikun që ju interesonte. Një rrugë blackhole drejt pishinës së VPN me metrikë të lartë është një shtresë e dytë e dobishme për projektet fail-closed, pasi mbijeton kur rruga e tunelit zhduket në vend që të bjerë përsëri në atë të paracaktuar.

Pranojeni konfigurimin vetëm kur një klient LAN, një kërkesë e gjeneruar nga routeri dhe një kërkesë IPv6 dështojnë të gjitha me tunelin e ulur, dhe të tre funksionojnë përsëri sapo ai ngrihet.