Maršrutizatoriaus kill switch, apimantis FORWARD, OUTPUT ir IPv6

Prisijungiate prie maršrutizatoriaus, įklijuojate kill switch taisyklių rinkinį iš forumo įrašo, ir LAN nustoja naršyti tą akimirką, kai tunelis nukrenta. Po dviejų dienų maršrutizatorius vis dar atnaujina savo dinaminį DNS įrašą per įprastą WAN, o svečių nešiojamasis vis dar pasiekia IPv6 svetaines. Abi elgsenos yra normalios, nes įklijuotos taisyklės apėmė vieną grandinę ir vieną adresų šeimą, ir nė viena jų nėra visas maršrutizatorius. Paketų kelių perėjimas eilės tvarka tiksliai parodo, kas buvo praleista.

Pradėkite nuo maršrutizatoriaus, ne nuo nešiojamojo

Maršrutizatoriaus lygio politika patraukli mažam biurui, nes kiekvienas įrenginys už jo paveldi tą pačią elgseną ir niekas negali pamiršti įjungti kliento jungiklio. Ji taip pat suteikia vieną vietą testuoti po kiekvieno programinės aparatinės įrangos atnaujinimo. Ko ji neduoda, tai automatinio maršrutizatoriaus paties srauto ar antros adresų šeimos padengimo, ir tai yra dvi spragos už daugumos nepavykusių diegimų.

Prieš ką nors keisdami, užsirašykite tris faktus ant popieriaus: WAN sąsajos pavadinimą, LAN tilto pavadinimą bei VPN galinio taško adresą ir prievadą. Visų trijų prireiks taisyklėse, o sąsajų pavadinimų spėliojimas yra dažniausia priežastis, kodėl teisingai atrodantis taisyklių rinkinys nieko nedaro.

Pereikite tris kelius, kuriuos gali rinktis paketas

Srautas iš nešiojamojo į internetą yra persiunčiamas, todėl praeina per FORWARD grandinę. Srautas, kurį generuoja pats maršrutizatorius, pavyzdžiui, DNS persiuntimas, NTP užklausos, DDNS atnaujinimai ir VPN valdymo kanalas, praeina per OUTPUT. Valdymo srautas, adresuotas maršrutizatoriui, ateina per INPUT.

Todėl kill switch, pastatytas tik FORWARD grandinėje, apsaugo klientus ir nieko daugiau. Lentelė parodo, kodėl nuotėkis pradinėje scenoje yra nuspėjamas, o ne paslaptingas.

Daugumoje projektų INPUT kill switch nereikia, bet valdymo prieigą reikia išlaikyti veikiančią, kol tunelis yra išjungtas. Priešingu atveju per pirmąjį VPN gedimą važiuosite į biurą su konsolės kabeliu.

Surikiuokite taisykles taip, kad tunelis vis dar galėtų pakilti

Veikiantis kill switch yra leidimų sąrašas, kuris baigiasi atmetimu, o tvarka paverčia jį kill switch, o ne plyta. Pirma leiskite loopback, VPN galinį tašką, atsakymus nusistovėjusiems srautams ir tunelio sąsają; likusius atmėskite paskutinius.

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

Šiame etape galinis taškas turi būti adresas, o ne pagrindinio kompiuterio vardas. Kai galutinis atmetimas užblokuoja DNS, taisyklė, nurodanti teikėjo pagrindinio kompiuterio vardą, nebegali būti išspręsta, ir tunelis niekada nebepasileidžia po perkrovimo. Jei teikėjas keičia galinius taškus, išspręskite vardą prieš taikant politiką ir atnaujinkite tą taisyklę iš to paties scenarijaus.

Pakartokite formą FORWARD grandinėje klientų srautui ir padėkite aiškią valdymo taisyklę virš atmetimo. Laikykite tą valdymo taisyklę siaurą, bet pasiekiamą, ir patvirtinkite ją atidarydami antrą SSH sesiją prieš uždarydami pirmąją. Užsirakinti per kill switch keitimą yra pakankamai įprasta, kad vertėtų planuoti. Maršrutizatoriuje su WireGuard peer allowed-ips nusprendžia, kas patenka į tunelį, o šios taisyklės nusprendžia, kam leidžiama išeiti be jo.

IPv6 reikia savo durų

Viskas aukščiau yra IPv4. Jei jūsų LAN veikia IPv6, o tunelis perduoda tik IPv4, kiekvienas padengtas įrenginys vis dar turi tiesioginį maršrutą į internetą, kurio jūsų naujos taisyklės niekada nemato. Dviejų protokolo krūvų nešiojamasis mielai jį rinksis, o kill switch atrodys sugedęs tik tam, kas testuoja su IPv4.

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

Čia tvarka taip pat svarbi: loopback leidimas turi eiti prieš WAN atmetimą, kitaip vietinės paslaugos maršrutizatoriuje pradės keistai gesti. Jei tinklas visiškai nenaudoja IPv6, jį išjungti WAN ir LAN yra paprasčiau ir nelieka nieko pamiršti.

Kai kurie VPN klientai įdiegia numatytąjį maršrutą tik IPv4 ir palieka esamą IPv6 numatytąjį maršrutą nepaliestą. Patikrinkite maršrutų lentelę po to, kai tunelis prisijungs, o ne manykite, kad klientas tuo pasirūpino.

Įrodykite tai su išjungtu tuneliu

Sustabdykite tunelį iš maršrutizatoriaus ir išbandykite iš trijų vietų šia tvarka:

# 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

Maršruto paieška pasako, kur paketas eitų, o skaitikliai pasako, ar jūsų taisyklės kada nors suveikė. Taisyklė su nuliu paketų po nepavykusio bandymo nieko neapsaugo, o įprasta priežastis yra sąsajos pavadinimas, besiskiriantis nuo įvesto. Aiškiai išbandykite maršrutizatoriaus generuojamą srautą, nes bandymas iš LAN pusės negali paveikti OUTPUT.

Nuspręskite gedimo režimą anksčiau, nei jo prireiks. Fail-closed laiko klientus neprisijungusius, kol tunelis grįš; fail-open atkuria įprastą WAN prieigą ir sugriauna tikslą tam srautui, kuris jums rūpėjo. Blackhole maršrutas į VPN baseiną su dideliu metrikos reikšmės skaičiumi yra naudingas antrasis sluoksnis fail-closed projektams, nes jis išlieka, kai tunelio maršrutas išnyksta, o ne grįžta prie numatytojo.

Priimkite sąranką tik tada, kai LAN klientas, maršrutizatoriaus generuota užklausa ir IPv6 užklausa visi nepavyksta su išjungtu tuneliu, ir visi trys vėl veikia, kai jis įjungtas.