Аварийният прекъсвач блокира 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 и маршрутизация за отделни приложения всяко дава свързан тунел със счупен трафик и всяко има различна първа проверка.