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 држи по један опсег за сваки линк и бира међу њима по рути, док macOS чита опсежне резолвере из динамичког складишта и поштује редослед интерфејса. Клијент који инсталира сопствени резолвер такмичи се са оним са линка, а правила приоритета која нико не гледа одлучују победника. Тада се разрешавање имена може сломити док филтрирање пакета ради тачно оно за шта је написано.

Читајте резолвер који је активан, а не онај који је конфигуриран. На systemd домаћину подкоманда status показује са ког линка је дошао сваки опсег и да ли је име private-DNS на снази:

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

Ако упит излази кроз физички линк уместо кроз тунел, клијент је изгубио трку приоритета и никакво подешавање заштитног зида неће поправити именовање. Упоредите пут упита са обе стране преласка да видите који се померио. Име које се разрешава на приватну адресу коју нова мрежа не може рутирати је трећи случај, и појављује се као истек времена, а не као грешка.

Вежбајте прелазак и чувајте запис

Репродукујте промену намерно уместо да је чекате. Подигните тунел на првом линку, започните дуготрајан пренос и поновљену претрагу, затим пребаците линк и гледајте који преживљава. Запишите интервал између нестанка старог линка и извештаја тунела да је повезан, јер се у том прозору политика или одржала или није. Покрените секвенцу и у супротном смеру, да резултат не буде једностран.

Изузеци траже сопствени пролаз, јер заобилажење оправдано на старој мрежи није аутоматски оправдано на новој. Штампач, NAS или captive portal на кућном LAN-у нема пандан на мобилној мрежи, а изузетак који је до њих стизао постаје правило без пандана.

Запишите имена интерфејса, понуђене фамилије, резолвер на снази и дужину прекида за сваки смер. Поновно повезивање доказује да се транспорт опоравио, а не да је блокада издржала током празнине, и то су одвојене тврдње за тикет. Са тим записом следећи прелазак се пореди са познатим стањем, а не са памћењем.