Kill-switch пасля пераходу з Wi-Fi на сотавую сетку: што ламаецца

У адзін момант ноўтбук у офіснай сетцы Wi-Fi, у наступны ён падключаны да тэлефона, і індыкатар тунеля зноў зялёны, перш чым вы скончыце пераключаць вокны. Зялёнае святло паведамляе толькі пра тое, што тунель зноў падключыўся; што рабіла палітыка маршрутызацыі і блакіроўкі ў час разрыву — іншае пытанне. Гэтая палітыка — набор умоў супастаўлення, сабраных пры апошняй усталёўцы, і называе інтэрфейс, адрас і сямейства адрасоў, якія пераход толькі што выдаліў. Таму той самы пераход дае тры вынікі, што выглядаюць аднолькава: блакіроўка працягваецца, палітыка блакуе сваё ўласнае аднаўленне, або адкрываецца шлях, які нішто не пакрывае.

Нішто на экране не адрознівае гэтыя тры станы, таму пытайцеся, да якіх ідэнтыфікатараў былі прывязаныя правілы, а не які колер паказвае індыкатар. У Linux правіла можа называць інтэрфейс або ipset, запоўнены з яго; у Android VpnService можна сказаць, за якімі базавымі сеткамі ісці, праз setUnderlyingNetworks. Кожная прывязка паказвае на звён, які вось-вось заменяць, і кожную трэба пераацаніць пасля.

Што пераход насамрэч перапісвае

Калі старое звяно знікае, ядро выдаляе яго адрасы, адклікае маршруты, што вялі праз яго, і перабудоўвае выбар адраса крыніцы з таго, што засталося. Маршрут па змаўчанні пераходзіць на новы шлюз, а індэкс інтэрфейса, на які спасылаліся старыя правілы, знік або пераапрацаваны для іншай прылады. Рэзалверы на кожнае звяно таксама абнаўляюцца, хоць і не ў той самы момант, што маршруты. Усё гэта адбываецца ніжэй за кліент VPN, таму кліент, які сочыць толькі за станам свайго тунеля, нічога з гэтага не бачыць.

Бяда ў тым, што правіла кадуе пэўны ідэнтыфікатар замест намеру за ім. Правіла, якое адкідвае ўсё, што не выходзіць праз інтэрфейс тунеля, кадуе імя інтэрфейса; правіла, якое дазваляе канчатковы пункт, кадуе адрас, які новая сетка можа накіраваць у іншае месца. Калі ідэнтыфікатар знікае, правіла не робіцца бачна няправільным, яно або перастае супадаць з чым-небудзь, або пачынае супадаць з няправільным.

Перабудаваць знешні тунель, не прабіваючы дзірку

Знешні транспарт быў прывязаны да старога адраса крыніцы, таму ён мусіць адкрыць новы сокет з новага. Калі канчатковы пункт — імя хоста, а не літаральны адрас, пошук мусіць удацца, пакуль блакіроўка яшчэ дзейнічае. Вось пастка парадку: палітыка, дастаткова строгая, каб адкінуць усё, акрамя канчатковага пункта, адкіне і пошук, патрэбны, каб яго знайсці, калі развязанне не адбываецца да ўзняцця блакіроўкі або не праносіцца праз яшчэ жывы тунель. Любы з двух парадкаў можа спрацаваць, але толькі калі кліент ведае, у якім парадку ён знаходзіцца.

Кліенты адрозніваюцца тут так, што мае значэнне пры дыягностыцы. Адныя спачатку робяць развязанне і потым ставяць правілы, таму пераход каштуе бачнага перапынку і потым аднаўляецца сам; іншыя трымаюць блакіроўку і спадзяюцца на тунель, што выжыў, каб пранесці пошук, а гэта цалкам правальваецца, калі тунель памёр разам са звяном. Даданне шырокага прамога маршруту па змаўчанні для аднаўлення злучэння заўсёды робіць тэст паспяховым і заўсёды пакідае ўцечку, якую вы прадухілялі.

Маршрут, які ўсё яшчэ паказвае на стары шлюз, дае тое ж затарможанае аднаўленне з іншай прычыны, таму прачытайце табліцу, перш чым вінаваціць кліент. Каманды ніжэй называюць інтэрфейс і адрас крыніцы, якія ядро сапраўды выкарыстала б, і гэта вырашае ў адзін радок, ці стары шлях яшчэ ўсталяваны.

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

Калі новае звяно прыносіць IPv6, а правілы — не

Сотавыя і гасцявыя сеткі часта выдаюць глабальны прэфікс IPv6, нават калі правадная LAN офіса ніколі гэтага не рабіла. Палітыка, напісаная толькі як правілы IPv4, — тыповая форма большасці самаробных рэцэптаў iptables і nftables, — не пакрывае нічога з гэтага. Тунель застаецца падключаным, праграмы з дасяжнасцю IPv6 выходзяць па-за яго, і індыкатар не можа паказаць розніцу, бо тунель сапраўды ўзняты. Люстэркавы выпадак гэтак жа часты: набор правілаў толькі для IPv6 нічога не робіць у сетцы, якая не прапануе v6.

Параўнайце, што прапануе звяно, з тым, што згадвае палітыка, па абодва бакі пераходу. Гэтыя каманды друкуюць тыя ж факты, з якімі працуе кліент:

ip -4 route show default
ip -6 route show default
sudo nft list ruleset | grep -c 'ip6 '

Калі другая каманда друкуе маршрут па змаўчанні, а трэцяя вяртае нуль, новае звяно можа выпусціць машыну праз IPv6 без аніякага правіла, якое б за ім сачыла. Запусціце ўсе тры зноў пасля пераключэння, бо цікавая лічба — розніца паміж двума запускамі. Калі другая не друкуе нічога, дзейнічае адваротны выпадак, і любая палітыка, цяжкая на v6, там проста ўпрыгожванне.

Рэзалвер пераходзіць з рук у рукі пасярод сесіі

У сучасных сістэмах рэзалверы прывязаныя да звёнаў, таму новае звяно прыходзіць з новым наборам рэзалвераў і, магчыма, іншым выглядам split-DNS. systemd-resolved трымае па адным scope на звяно і выбірае паміж імі па маршруце, а macOS чытае scoped рэзалверы з дынамічнага сховішча і паважае парадак інтэрфейсаў. Кліент, які ставіць свой рэзалвер, канкуруе з рэзалверам звяна, і правілы прыярытэту, за якімі ніхто не сочыць, вырашаюць пераможцу. Тады развязанне імёнаў можа зламацца, хоць фільтраванне пакетаў робіць менавіта тое, для чаго яго напісалі.

Чытайце актыўны рэзалвер, а не наладжаны. На хасце systemd падкаманда status паказвае, ад якога звяна прыйшоў кожны scope і ці дзейнічае імя private-DNS:

resolvectl status --no-pager
resolvectl query intranet.example.com

Калі запыт выходзіць праз фізічнае звяно, а не праз тунель, кліент прайграў спаборніцтва прыярытэтаў, і ніякая наладка міжсеткавага экрана не выправіць імёны. Параўнайце шлях запыту па абодва бакі пераходу, каб убачыць, які з іх зрушыўся. Імя, якое развязваецца ў прыватны адрас, што новая сетка не можа маршрутызаваць, — трэці выпадак, і ён выглядае як тайм-аўт, а не як памылка.

Адпрацуйце пераход і захавайце запіс

Узнавіце змену наўмысна, а не чакайце яе. Узніміце тунель на першым звяне, пачніце доўгую перадачу і паўтаральны пошук, потым пераключыце звяно і паглядзіце, якое з іх выжыве. Занатуйце інтэрвал паміж знікненнем старога звяна і паведамленнем тунеля пра падключэнне, бо менавіта ў гэтым акне палітыка або ўтрымалася, або не. Прагоньце паслядоўнасць і ў адваротным кірунку, каб вынік не быў аднабаковым.

Выключэнні патрабуюць асобнага праходу, бо абыход, апраўданы ў старой сетцы, не апраўданы аўтаматычна ў новай. Прынтар, NAS або captive portal у хатняй LAN не мае адпаведніка ў сотавай сетцы, і выключэнне, якое да яго даходзіла, робіцца правілам без адпаведніка.

Запішыце імёны інтэрфейсаў, прапанаваныя сямействы, дзейны рэзалвер і працягласць перапынку для кожнага кірунку. Паўторнае злучэнне даказвае, што транспарт аднавіўся, а не што блакіроўка ўтрымалася ў час разрыву, і гэта асобныя сцвярджэнні для тыкета. З гэтым запісам наступны пераход параўноўваюць з вядомым станам, а не з памяццю.