Аварыйны выключальнік блакуе VPN-сервер да таго, як пойдзе любы трафік
Які этап блакуе аварыйны выключальнік: пошук канчатковага пункта, знешні маршрут, зваротны шлях і састарэлыя выключэнні для суразмоўцаў — з лічыльнікамі замест здагадак.
Аварыйныя выключальнікі зрываюцца ў кірунку, якога людзі не чакаюць: яны створаны блакаваць трафік, пакуль тунель не працуе, а пакеты, якія будуюць тунель, самі з’яўляюцца трафікам. У гэтым і ўся памылка. Набор правілаў, які адкідвае ўсё, што не выходзіць праз тунель, адкідвае таксама рукапацісканне, якое павінна яго ўзняць, таму кліент паўтарае спробу ў цыкле, і памылка належыць таму этапу, які правяраецца першым. Перш чым пашыраць міжсеткавы экран, высветліце, які з трох этапаў адхіляецца: пошук імя, знешні пакет да суразмоўцы або адказ, што вяртаецца.
Як тунель і яго ўласны транспарт залежаць адзін ад аднаго
Чытайце VPN-кліент як два сеткавыя станы, якія дзеляць адзін шлях сокета. Пакуль тунелю няма, кліент адкрывае сокет на фізічным адаптары і шле зашыфраваныя кадры на адрас і порт суразмоўцы. Толькі пасля паспяховага абмену ён стварае прыладу тунеля і ўсталёўвае маршруты. Аварыйны выключальнік — гэта палітыка пра другі стан, напісаная так шырока, што дзейнічае на абодва.
Правілы на аснове інтэрфейса — звычайная форма: прымайце тое, што выходзіць праз 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 імя развязаецца пры загрузцы набору правілаў, таму яно фіксуе той адрас, які існаваў у гэты момант, і састарэе, як літаральны. Трывалым рашэннем з’яўляецца абнаўленне выключэння пры змене канчатковага пункта і ўтрыманне яго вузкім: адзін адрас суразмоўцы, адзін транспартны порт. Дыяпазон, дастаткова шырокі, каб перажыць змену адраса, таксама дастаткова шырокі, каб выпускаць непатрэбны трафік.
Калі аварыйны выключальнік працуе на хосце сервера
Тая ж залежнасць існуе на другім канцы, і там яе лягчэй прапусціць. Калі машына, што служыць вашым VPN-серверам, таксама запускае настольны кліент з аварыйным выключальнікам або профіль міжсеткавага экрана, скапіяваны з ноўтбука, яе правілы адкідання дзейнічаюць на службу, якая завяршае тунелі. Адкідваюцца адказы на рукапацісканне кліента, таму кожны кліент не можа падключыцца, пакуль сервер выглядае здаровым, а яго інтэрфейс тунеля стаіць без ужытку.
Гэтаму хосцу патрэбны тры вузкія дазволы перад адкіданнем: порт праслухоўвання на фізічным інтэрфейсе, інтэрфейс тунеля для расшыфраванага трафіку і перасыланне з тунеля да таго, чаго павінны дасягаць кліенты. Прачытайце ўсталяваны набор з дапамогай nft list ruleset, iptables -S, або pfctl -sr перш чым нешта змяняць, і памятайце, што захаваны набор правілаў перажывае перазагрузку, таму памылка там перажывае працэс, які яе зрабіў.
Парадак аднаўлення, які трымае машыну закрытай
Рухайцеся ад профілю вонкі. Прачытайце адрас суразмоўцы і порт, якія выкарыстоўвае кліент, пацвердзіце, што імя хоста развязваецца без тунеля, затым дадайце адно выключэнне для гэтага адраса і порта толькі на фізічным адаптары. Перападключыцеся і назірайце за лічыльнікам адпраўкі; завершанае рукапацісканне — гэта сігнал, што другі этап выпраўлены.
Пакіньце астатнюю палітыку адкідання на месцы падчас праверкі. Бясшкодная праверка — паспрабаваць злучэнне з непатрэбным дакументацыйным адрасам і пераканацца, што ён усё яшчэ заканчваецца тайм-аўтам, што паказвае працу аварыйнага выключальніка, а не яго адключэнне. Пацясніце выключэнне, калі тунель стабілізуецца, і не пакідайце пастаяннага дазволу ўсяго для кліенцкай праграмы толькі таму, што так зручна.
Калі тунель уздымаецца, а праграма ўсё роўна зрываецца, астатнія этапы не гэты: падзелены DNS, MTU і маршрутызацыя для асобных праграм кожны стварае падключаны тунель са зламаным трафікам, і ў кожнага свая першая праверка.