Kill switch на рутерот што ги покрива FORWARD, OUTPUT и IPv6

Влегувате во рутерот, залепувате сет правила за kill switch од објава на форум и LAN престанува да прелистува во моментот кога тунелот паѓа. Два дена подоцна рутерот се уште го ажурира својот динамичен DNS запис преку обичниот WAN, а гостинскиот лаптоп се уште стигнува до страници на IPv6. Двете однесувања се нормални, затоа што залепените правила покриваа еден синџир и едно семејство адреси, и ниту едно од тоа не е целиот рутер. Поминувањето низ патеките на пакетите по ред покажува точно што е пропуштено.

Започнете од рутерот, не од лаптопот

Политиката на ниво на рутер е привлечна за мала канцеларија затоа што секој уред зад него го наследува истото однесување и никој не може да заборави да вклучи прекинувач на клиентот. Таа ви дава и едно место за тестирање по секое ажурирање на фирмверот. Она што не го дава е автоматско покривање на сопствениот сообраќај на рутерот или на второ семејство адреси, а тоа се двете празнини зад повеќето неуспешни распоредувања.

Пред да промените нешто, запишете три факти на хартија: името на WAN интерфејсот, името на LAN мостот и адресата и портата на крајната точка на VPN. Ќе ви требаат сите три во правилата, а погодувањето имиња на интерфејси е најчестата причина зошто сет правила што изгледа исправно не прави ништо.

Поминете низ трите патеки што може да ги земе пакетот

Сообраќајот од лаптоп кон интернет се препраќа, па минува низ синџирот FORWARD. Сообраќајот што рутерот сам го генерира, како препраќање на DNS, NTP барања, DDNS ажурирања и контролниот канал на VPN, минува низ OUTPUT. Управниот сообраќај упатен до рутерот пристигнува преку INPUT.

Затоа kill switch изграден само во FORWARD ги штити клиентите и ништо друго. Табелата покажува зошто истекувањето од воведната сцена е предвидливо, а не мистериозно.

Во повеќето проекти не ви треба 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 барање сите откажуваат со спуштен тунел, и сите три повторно работат штом тој се крене.