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 заявка се провалят всички със спрян тунел, и трите отново работят, щом той се вдигне.