Зашто 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 је машина стања, а не прекидач

Већина клијената изражава блокаду као политику заштитног зида у три стања: тунел подигнут, саобраћај иде кроз тунел и блокаде нема; тунел спуштен, блокада је активна; и прелаз, када је блокада активна плус привремени изузеци за крајњу тачку. Баш у трећем стању живе грешке, јер оно мора да се промени двапут у неколико секунди, а немогућност изласка из њега изгледа тачно као трајна блокада.

Механизам се разликује по платформи, а и отказ. Филтери Windows Filtering Platform имају тежине, па блокирајући филтер који надјачава вашу дозволу наставља да одбацује пакете иако дозвола постоји, и филтери које је оставио убијени процес клијента могу да држе машину ван мреже пошто апликација нестане. Клијенти на macOS обично пишу pf правила у сидро, где редослед правила и брзе одлуке одређују које правило важи. Клијенти на Linux-у обично управљају nftables или iptables ланцем са drop политиком и експлицитним дозволама за крајњу тачку, интерфејс тунела и loopback. Always-on VPN на Android-у са опцијом блокирања веза без 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-а каже да ли је блокада завршена касно или никада.

Нормално замрачење наспрам заглављене блокаде

Известан прекид је смисао ове функције, зато прво направите тријажу пре него што промените било које подешавање:

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

Пре следеће промене потврдите четири ствари: дозвола за крајњу тачку покрива сваку фамилију адреса коју ваш профил разрешава, дневник клијента показује завршен прелаз, ваш ping тест мери празнину, а не икону, и затварање клијента враћа нормалну повезаност. Kill switch који издржи промену и затим отпусти обавља свој посао. Онај који отпусти рано или никада вреди дебагирати.