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

Што кліент робіць паміж двума серверамі

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

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

Новай канцавой кропцы патрэбна дзірка ў блакіроўцы

Каб пабудаваць тунель, кліент павінен адпраўляць пакеты на адрас і порт новага сервера праз фізічны інтэрфейс, напрыклад UDP 51820 для тыповага профілю WireGuard або 1194 і 443 для OpenVPN — што б ні паказаў ваш уласны профіль. Гэты трафік не знаходзіцца ў тунелі, які вось-вось будзе створаны, таму блакіроўка на ўсю прыладу паглынае яго, калі няма адпаведнага правіла дазволу.

Профілі на аснове імені хоста дадаюць другую ўмову: сам пошук. Калі кліент разрознівае канцавую кропку да ўздыму блакіроўкі, ён можа скарыстаць кэшаваны адрас, але калі профіль змяняе адрасы ці кэшаваны запіс састарэе, рукапацісканне накіроўваецца на адрас, які правіла дазволу не пакрывае. IPv6 робіць гэта бачным, бо двухстэкавая канцавая кропка можа публікаваць і запіс A, і запіс AAAA, а правіла дазволу, якое пакрывае толькі адрас v4, пакідае кліента паўтараць спробу супраць заблакаванага адрасу v6.

Назвы параметраў і значэнні па змаўчанні адрозніваюцца ў залежнасці ад кліента і версіі, таму чытайце дакументаваны спіс для свайго, а не здагадвайцеся па здымках экрана. Даведка па наладах OpenVPN Connect на openvpn.net/connect-docs/app-settings-windows — адзін з прыкладаў таго, як кліент апісвае свае параметры блакавання і раздзеленага тунеля.

Fail-closed — гэта машына станаў, а не перамыкач

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

Механізм адрозніваецца па платформах, і збой таксама. Фільтры Windows Filtering Platform маюць вагі, таму блок-фільтр, які пераўзыходзіць дазвол, працягвае адкідаць пакеты, нават калі дазвол існуе, і фільтры, пакінутыя забітым працэсам кліента могуць трымаць машыну без сеткі пасля знікнення праграмы. Кліенты macOS звычайна запісваюць правілы pf у якар, дзе парадак правілаў і хуткія рашэнні вызначаюць, якое правіла дзейнічае. Кліенты Linux звычайна кіруюць ланцужком nftables або iptables з палітыкай drop і яўнымі дазволамі для канцавой кропкі, інтэрфейса тунеля і loopback. Android з always-on VPN і опцыяй блакаваць злучэнні без VPN — самы строгі ў групе, бо аперацыйная сістэма прымяняе блакіроўку на ўсю прыладу, а не на асобную праграму.

WireGuard патрабуе асобнай заўвагі, бо AllowedIPs — гэта селектар маршрутызацыі, а не блакіравальнік. Ён вырашае, якія прызначэнні трапляюць у тунель; ён нічога не робіць, каб пакет без тунеля не выйшаў праз Wi-Fi. У наладзе толькі з WireGuard без правіла міжсеткавага экрана kill switch — гэта насамрэч адсутнасць маршруту, і за адкінутым рукапацісканнем можа пайсці сапраўдны пакет, што выйдзе праз фізічны інтэрфейс.

Мерце прамежак, а не назірайце за значком

Сачыце за пакетамі, а не за індыкатарам стану. У Linux запусціце павольны ping да публічнага адрасу ў адным тэрмінале і перахапіце транспартны порт тунеля на фізічным інтэрфейсе ў другім:

ping -i 0.2 -c 100 1.1.1.1 | tail -5

sudo tcpdump -ni eth0 'udp port 51820'

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

У Windows netsh wfp show state запісвае здымак, у якім можна шукаць блок-фільтры, што ўсё яшчэ прысутнічаюць, пакуль кліент сцвярджае, што адключаны. У macOS sudo pfctl -sr пералічвае загружаныя правілы і іх парадак. Спалучыце любы здымак з уласным журналам кліента; храналогія з ping скажа, ці блакіроўка скончылася позна, ці не скончылася ніколі.

Звычайнае зацямненне супраць захраслай блакіроўкі

Пэўны перапынак — гэта і ёсць сэнс функцыі, таму спачатку ацаніце сітуацыю, перш чым змяняць любы параметр:

What you seeUsually meansNext check
Two or three seconds of timeouts, then normal browsingExpected fail-closed gapNothing to fix
State says connected, traffic stays deadBlock filter or route left behindFirewall snapshot, client log
One app dead while others workTCP session bound to the old exit addressRestart the app
LAN devices unreachable after the switchLAN exception not reappliedAllow-LAN or split-tunnel setting
New server hangs, the old one reconnectsPermit covers only the old addressResolved address of the new host, including AAAA

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

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

Падобныя артыкулы