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 и рутирање по апликација секое создава поврзан тунел со расипан сообраќај, и секое има различен прв чекор.