Kill switch на рутеру који покрива FORWARD, OUTPUT и IPv6
Kill switch само у FORWARD-у оставља рутер слободним да отекне, а правила само за IPv4 остављају IPv6 отворен. Поређајте ланце и тестирајте са спуштеним тунелом.
Пријавите се на рутер, залепите скуп kill switch правила са форумске објаве и LAN престаје да прегледа оног тренутка када тунел падне. Два дана касније рутер још увек ажурира свој динамички DNS запис преко обичног WAN-а, а гостујући преносни рачунар још увек достиже IPv6 странице. Оба понашања су нормална, јер су залепљена правила покривала један ланац и једну адресну фамилију, а ниједно од тога није цео рутер. Пролазак кроз путање пакета по реду показује тачно шта је пропуштено.
Почните од рутера, а не од преносног рачунара
Политика на нивоу рутера привлачна је за малу канцеларију јер сваки уређај иза њега наслеђује исто понашање и нико не може да заборави да укључи прекидач на клијенту. Она вам даје и једно место за тестирање након сваког ажурирања фирмвера. Оно што не даје јесте аутоматска покривеност сопственог саобраћаја рутера или друге адресне фамилије, а то су два јаза иза већине неуспешних имплементација.
Пре него што било шта уредите, запишите три чињенице на папир: назив WAN интерфејса, назив LAN моста и адресу и порт VPN крајње тачке. Сва три ће вам требати у правилима, а погађање назива интерфејса је најчешћи разлог зашто скуп правила који изгледа исправно не ради ништа.
Прођите кроз три пута која пакет може да узме
Саобраћај са преносног рачунара на интернет се прослеђује, па пролази кроз FORWARD ланац. Саобраћај који рутер сам генерише, попут прослеђивања DNS-а, NTP упита, DDNS ажурирања и контролног канала VPN-а, пролази кроз OUTPUT. Управни саобраћај упућен рутеру долази кроз INPUT.
Kill switch изграђен само у FORWARD-у зато штити клијенте и ништа друго. Табела показује зашто је цурење из уводне сцене предвидиво, а не тајанствено.
| 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 |
У већини пројеката вам не треба kill switch на INPUT-у, али морате да одржите управни приступ функционалним док је тунел спуштен. Иначе се при првом паду VPN-а возите у канцеларију са конзолним каблом.
Поређајте правила тако да тунел ипак може да се подигне
Исправан kill switch је листа дозвола која се завршава одбијањем, а редослед је оно што га чини kill switch-ом уместо циглом. Прво дозволите loopback, VPN крајњу тачку, одговоре за успостављене токове и тунелски интерфејс; на крају одбијте остало.
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Крајња тачка у овом тренутку мора бити адреса, а не име хоста. Када завршно одбијање блокира DNS, правило које наводи име хоста провајдера више не може да се разреши и тунел се никада више не покреће након поновног покретања. Ако провајдер мења крајње тачке, разрешите име пре него што се политика примени и освежите то правило из исте скрипте.
Пресликајте облик у FORWARD-у за саобраћај клијената и поставите изричито управно правило изнад одбијања. Држите то управно правило уским, али доступним, и потврдите га отварањем друге SSH сесије пре него што затворите прву. Закључавање себе током промене kill switch-а довољно је често да се планира. На рутеру са WireGuard-ом, allowed-ips партнера одлучују шта улази у тунел, док ова правила одлучују шта сме да изађе без њега.
IPv6-у су потребна сопствена врата
Све горе је IPv4. Ако ваш LAN има функционалан IPv6, а тунел преноси само IPv4, сваки покривени уређај и даље има директну руту до интернета коју ваша нова правила никада не виде. Преносни рачунар са двоструким стеком ће је радо преферирати, а kill switch ће изгледати покварен само особи која тестира са IPv4.
ip6tables -A FORWARD -i br-lan -j REJECT
ip6tables -A OUTPUT -o eth0 -j REJECT
ip6tables -A OUTPUT -o lo -j ACCEPTРедослед је и овде важан: дозвола за loopback мора да дође пре одбијања WAN-а, иначе локалне услуге на рутеру почињу чудно да отказују. Ако мрежа уопште не користи IPv6, једноставније је искључити га на WAN-у и LAN-у и не остаје ништа за заборављање.
Неки VPN клијенти инсталирају подразумевану руту само за IPv4 и остављају постојећу подразумевану руту IPv6 нетакнутом. Проверите табелу рутирања након што се тунел повеже, уместо да претпоставите да је клијент то решио.
Докажите то са спуштеним тунелом
Зауставите тунел са рутера и тестирајте са три места у овом реду:
# 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Претрага руте вам каже куда би пакет отишао, а бројачи кажу да ли су ваша правила икада погодила. Правило са нула пакета након неуспешног теста ништа не штити, а уобичајен узрок је назив интерфејса који се разликује од унетог. Тестирајте изричито саобраћај који генерише рутер, јер тест са LAN стране не може да активира OUTPUT.
Одлучите о режиму квара пре него што вам затреба. Fail-closed држи клијенте ван мреже док се тунел не врати; fail-open враћа обичан WAN приступ и промашује сврху за саобраћај који вам је био важан. Blackhole рута до VPN пула са високом метриком корисна је други слој за fail-closed пројекте, јер преживљава када тунелска рута нестане, уместо да се врати на подразумевану.
Прихватите подешавање само када LAN клијент, захтев који генерише рутер и IPv6 захтев сви откажу са спуштеним тунелом, и сва три поново раде када се подигне.