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 усе не ўдаюцца з выключаным тунелем, і ўсе тры зноў працуюць, як толькі ён падымаецца.