Защо kill switch спира трафика при смяна на сървър
Защо kill switch блокира трафика по време на смяна на сървър, какво прави клиентът в този интервал и как да различим нормална пауза от заседнала блокада.
Избирате сървър, който изглежда по-близо, натискате свързване и браузърът спира да зарежда, преди новият тунел да е готов. Иконата преминава в състояние на свързване и остава там, докато всеки раздел изтече по време. Тази пауза обикновено е kill switch, който работи по проект: трафикът е блокиран, докато клиентът няма тунел, през който да го изпрати. Дали паузата е приемлива зависи от това какво прави клиентът в тези секунди и дали блокадата се вдига, когато твърди, че е вдигната.
Какво прави клиентът между два сървъра
Смяната на крайна точка е няколко стъпки, а не един превключвател. Клиентът разваля текущия тунел, обновява правилата си за блокиране, резолвва новата крайна точка и я достига извън тунела, после инсталира новите маршрути и вдига блокадата. Усещаната пауза е между първата и последната стъпка.
Редът тук е по-важен от скоростта. Ако правилата за блокиране се приложат преди изключението за новата крайна точка, клиентът не може да завърши ръкостискането и остава в състояние на свързване до изтичане на времето. Ако изключението е копие на адреса на стария сървър, новото ръкостискане изглежда като всеки друг изходящ пакет и се изхвърля. И двата случая изглеждат еднакво от браузъра, затова смяна, която се възстановява след шест секунди, и такава, която никога не се възстановява, могат да имат една и съща причина.
Новата крайна точка се нуждае от дупка в блокадата
За да изгради тунела, клиентът трябва да изпраща пакети до адреса и порта на новия сървър през физическия интерфейс, например UDP 51820 за типичен профил WireGuard или 1194 и 443 за OpenVPN, каквото и да указва вашият профил. Този трафик не е вътре в тунела, който предстои да се създаде, затова блокада за цялото устройство го поглъща, освен ако няма съответстващо правило за разрешение.
Профилите, базирани на име на хост, добавят второ изискване: самото търсене. Ако клиентът резолвне крайната точка преди вдигането на блокадата, може да използва кеширан адрес, но щом профилът смени адресите или кешираният запис остарее, ръкостискането се насочва към адрес, който правилото за разрешение не покрива. IPv6 прави това видимо, защото крайна точка с двоен стек може да публикува както A, така и AAAA запис, а правило за разрешение, което покрива само адреса v4, оставя клиента да повтаря опити срещу блокиран адрес v6.
Имената на опциите и стойностите по подразбиране се различават според клиента и версията, затова четете документирания списък за вашия, вместо да гадаете от екранни снимки. Справочникът с настройки на OpenVPN Connect на openvpn.net/connect-docs/app-settings-windows е един пример как клиентът описва своите опции за блокиране и разделен тунел.
Fail-closed е машина на състоянията, не превключвател
Повечето клиенти изразяват блокадата като firewall политика в три състояния: тунел вдигнат, трафикът минава през тунела и няма блокада; тунел свален, блокадата е активна; и преход, при който блокадата е активна плюс временни изключения за крайната точка. Точно в третото състояние живеят бъговете, защото то трябва да се смени два пъти в рамките на няколко секунди, а невъзможността да се излезе от него изглежда точно като постоянна блокада.
Механизмът се различава според платформата, а също и отказът. Филтрите на Windows Filtering Platform имат тегла, затова блокиращ филтър, който превъзхожда разрешението, продължава да изхвърля пакети, въпреки че разрешението съществува, и филтри, оставени от убит процес на клиента могат да държат машината офлайн, след като приложението го няма. Клиентите за macOS обикновено записват pf правила в anchor, където редът на правилата и бързите решения определят кое правило се прилага. Клиентите за Linux обикновено управляват верига nftables или iptables с политика drop и явни разрешения за крайната точка, интерфейса на тунела и loopback. Always-on VPN на Android с блокиране на връзки без VPN е най-строгият в групата, защото операционната система прилага блокадата за цялото устройство, а не за отделно приложение.
WireGuard заслужава отделна бележка, защото AllowedIPs е селектор за маршрутизиране, а не блокер. Той решава кои дестинации влизат в тунела; не прави нищо, за да спре пакет без тунел да излезе през Wi-Fi. При настройка само с WireGuard и без firewall правило 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 see | Usually means | Next check |
|---|---|---|
| Two or three seconds of timeouts, then normal browsing | Expected fail-closed gap | Nothing to fix |
| State says connected, traffic stays dead | Block filter or route left behind | Firewall snapshot, client log |
| One app dead while others work | TCP session bound to the old exit address | Restart the app |
| LAN devices unreachable after the switch | LAN exception not reapplied | Allow-LAN or split-tunnel setting |
| New server hangs, the old one reconnects | Permit covers only the old address | Resolved address of the new host, including AAAA |
Ако попаднете във втория или петия ред, не изключвайте kill switch за тест, защото това превръща маршрутна грешка в изтичане. Рестартирайте услугата на клиента или рестартирайте устройството там, където филтрите преживяват убиване на процес, после вижте дали блокадата се изчиства. Ако се изчисти, дефектът е в почистването при смяната, а не в блокадата.
Преди следващата смяна потвърдете четири неща: разрешението за крайната точка покрива всяко семейство адреси, което профилът ви резолвва; логът на клиента показва завършен преход; ping тестът измерва паузата, а не иконата; затварянето на клиента възстановява нормална свързаност. Kill switch, който държи по време на смяната и отпуска след това, си върши работата. Такъв, който отпуска рано или никога, заслужава дебъгване.