Kill switch блокира VPN сервер пре него што крене било који саобраћај
Коју фазу блокира kill switch: тражење крајње тачке, спољашњу руту, повратни пут и застареле изузетке за партнере — са бројачима уместо претпоставки.
Kill switch отказују у смеру који људи не очекују: направљени су да блокирају саобраћај док је тунел пао, а пакети који граде тунел сами су саобраћај. У томе је цела грешка. Скуп правила који одбацује све што не излази кроз тунел одбацује и руковање које би га подигло, па клијент понавља у петљи, а грешка се приписује оној фази која се проверава прва. Пре него што проширите заштитни зид, утврдите која се од три фазе одбија: тражење имена, спољашњи пакет ка партнеру или одговор који се враћа.
Како тунел и његов сопствени транспорт зависе један од другог
Читајте VPN клијента као два мрежна стања која деле једну путању сокета. Пре него што тунел постоји, клијент отвара сокет на физичком адаптеру и шаље шифроване оквире на адресу и порт партнера. Тек након што та размена успе, ствара уређај тунела и инсталира руте. Kill switch је политика о другом стању, написана тако широко да важи за оба.
Правила заснована на интерфејсу су уобичајен облик: прихватите оно што излази кроз tun0 или wg0, одбаците остатак излазне путање. Та формулација не може да изузме сопствену везу клијента са сервером, зато је исправна имплементација додаје изричито, као и ви када правила пишете ручно. Правила по апликацији на Windows-у и macOS-у заобилазе део овога упаривањем процеса уместо интерфејса, али процес ипак мора да изађе пре него што тунел постоји.
Три фазе, редом којим се дешавају
Прва фаза је разрешавање. Када профил чува име хоста уместо дословне адресе, клијенту је потребан DNS одговор пре него што ишта пошаље. Профил који усмерава DNS на разрешивач тунела ствара застој: разрешивач је доступан само кроз тунел који је претрага требало да омогући. Разрешавање изван тунела или прикивање крајње тачке на адресу уклања ту двосмисленост.
Друга фаза је спољашњи пакет, који мора да преживи прво рутирање, а затим заштитни зид, тим редом. wireguard-tools обавља рутирајућу половину овога за WireGuard означавањем сопствених пакета и додавањем правила политике да прескоче подразумевану руту коју је управо инсталирао; страница приручника за wg-quick описује то правило и табелу коју користи. Обновите то рутирање ручно или пустите други алат да препише правила, па означени пакети могу бити послати назад у тунел који треба да успоставе.
Трећа фаза је повратни пут. Руковање без одговора није доказ одбацивања на излазу; једнако је спојиво са улазним правилом сервера или NAT уређајем који је забораво мапирање. Одвојите то пре него што дирате клијента.
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
Клијенти бележе симптом који открију, а не фазу која је пала, па је табела обично бржа од дневника.
Бројачи одлучују брже од дневника
На Linux-у, nft list ruleset или iptables -vnL OUTPUT исписује бројач пакета по правилу. Повежите се једном, пустите да падне, па поново прочитајте бројаче. Правило коме се бројач померио је правило у које је руковање ударило; ако се нигде ништа није померило, пакет никада није стигао до заштитног зида. Видео сам скуп правила да одбаци сопствено руковање, и то су рекли само бројачи.
Да раздвојите никада није стигао до заштитног зида од никада није напустио домаћина, посматрајте сам интерфејс. ip -s link show dev wlan0 пријављује послате пакете, а tcpdump -ni wlan0 udp port 51820 приказује оквире. Ако остане раван док клијент понавља, квар је изнад netfilter-а: недостаје рута до партнера, правило политике показује на уређај који још не постоји, или грешка сокета коју клијент гута.
Тестирајте изузетке на документационим адресама као што је 203.0.113.10, да грешка не би могла да испита туђи домаћин.
Застарео изузетак крајње тачке чита се као пад сервера
Најзаводљивија верзија појављује се након што се адреса партнера промени: сервис динамичких адреса ју је преместио, домаћин је поново изграђен или се излазна адреса ваше мреже разликује. Изузетак још наводи стару адресу, па пакети ка новој упадају у правило одбацивања. Иста конфигурација је радила јуче, и зато људи почињу дијагностиком сервера.
Име хоста унутар правила заштитног зида вас не спасава. У nftables-у име се разрешава при учитавању скупа правила, па прикива адресу која је тада постојала и застарева као дословна. Трајно решење је да ажурирате изузетак када се крајња тачка промени и да га држите уским: једна адреса партнера, један транспортни порт. Опсег довољно широк да преживи промену адресе довољно је широк и да пусти неповезан саобраћај.
Када kill switch ради на домаћину сервера
Иста зависност постоји на другом крају, и тамо ју је лакше пропустити. Ако машина која служи као ваш VPN сервер такође покреће десктоп клијента са kill switch-ом или профил заштитног зида копиран са лаптопа, његова правила одбацивања важе за сервис који завршава тунеле. Одговори на руковање клијента се одбацују, па сваки клијент не може да се повеже док сервер изгледа здраво, а његов интерфејс тунела стоји неискоришћен.
Тај домаћин захтева три уска прихватања пре одбацивања: порт за слушање на физичком интерфејсу, интерфејс тунела за дешифровани саобраћај и прослеђивање из тунела ка ономе што клијенти треба да достигну. Прочитајте инсталирани скуп помоћу nft list ruleset, iptables -S, или pfctl -sr , пре него што било шта промените, и запамтите да сачуван скуп правила преживљава рестарт, па грешка тамо надживљава процес који ју је направио.
Редослед опоравка који држи машину затвореном
Радите од профила ка споља. Прочитајте адресу и порт партнера које клијент користи, потврдите да се име хоста разрешава без тунела, па додајте један изузетак за ту адресу и порт само на физичком адаптеру. Повежите се поново и посматрајте бројач слања; завршено руковање је сигнал да је друга фаза поправљена.
Оставите остатак политике одбацивања на месту током тестирања. Безопасна провера је покушати везу са неповезаном документационом адресом и потврдити да још истиче, што показује да kill switch ради, а не да је искључен. Затегните изузетак када се тунел стабилизује, и не остављајте трајну дозволу за све за клијентски програм само зато што је згодно.
Ако се тунел подигне, а апликација и даље пада, преостале фазе нису ова: подељени DNS, MTU и рутирање по апликацији свако даје повезан тунел са поквареним саобраћајем, и свако има другачију прву проверу.