Ръкостискане на WireGuard работи, но няма интернет: проследете пакета

Тунелът е вдигнат, wg show показва скорошно ръкостискане, можете да пингувате тунелния адрес на сървъра и нищо след него не отговаря. Първият импулс е да прегенерирате ключове или да споделите конфигурацията отново. Това променя точно онази част от пътя, която вече е доказано, че работи.

Завършеното ръкостискане казва, че двете страни са съгласни за ключовете, че UDP достига крайната точка и че криптомаршрутизацията приема пакета. То не казва нищо за това дали пакетът може да напусне сървъра след това.

Затова проследете един пакет вместо да гадаете. Има четири места, където той може да загине, и всяко оставя различна следа.

Какво всъщност доказва ръкостискането

WireGuard е UDP протокол, който установява сесия с ръкостискане Noise и след това криптира пакети за даден партньор. Когато wg show показва ръкостискане на няколко секунди и растящ брояч на прехвърлянето, крайната точка, ключовете и публичният ключ на партньора са всички правилни.

Това, което не доказва, е че вашият клиент изобщо изпраща интернет трафик в интерфейса, че сървърът е готов да го препраща или че отговорът може да намери пътя обратно. Това са решения на ядрото за маршрутизация и на защитната стена и се вземат извън тунела.

Ето защо пингът към тунелния адрес на сървъра е толкова подвеждащ тест. Този пакет е адресиран до самия сървър, затова приключва локално. Той никога не се нуждае от препращане, никога от транслация и никога от обратен маршрут от интернет.

AllowedIPs е решение за маршрутизация

При клиента AllowedIPs изпълнява две задачи. Това е таблицата за криптоключова маршрутизация, която решава кои адреси на местоназначение се изпращат в тунела на този партньор, и това е списъкът с адреси на източника, които партньорът ще приеме от вас. Ако конфигурацията на клиента изброява само 10.8.0.0/24, публичните местоназначения никога не влизат в интерфейса и обичайният ви маршрут по подразбиране ги носи извън тунела. Тогава тунелът работи безупречно и не прави нищо от това, което сте искали.

Вижте какво действително е инсталирал клиентът, а не какво казва конфигурационният файл:

wg show wg0 allowed-ips
ip route get 1.1.1.1

Втората команда е решаващата. Ако отговорът посочва физическия ви интерфейс и обичайния шлюз, пакетът не се тунелира и никаква промяна от страна на сървъра няма да го поправи. Добавете 0.0.0.0/0 за IPv4 и ::/0 за IPv6 поотделно; правило, което обхваща всичко за едното семейство, оставя другото по оригиналния му път, а това е честа причина за работещ IPv4 тунел и заседнало IPv6 търсене.

Къде пакетът загива на шлюза

Ако маршрутът е правилен, а пакетът все още не отива никъде, той пристига на сървъра и спира там. Четири проверки покриват повечето шлюзове.

Препращане. sysctl net.ipv4.ip_forward с отговор 0 е класическият случай и много дистрибуции все още са на 0 по подразбиране. Трябва да бъде 1 и да се задава трайно във файл на sysctl, а не с команда, която изчезва при рестарт. Препращането на IPv6 е отделен превключвател.

Политиката на филтриране. Верига FORWARD с политика по подразбиране за отхвърляне ще изхвърля тунелния трафик, докато пропуска трафика към самия хост, което съвпада точно със симптома. Четете живия набор от правила, а не записан файл: nft list ruleset или iptables -S.

Транслация или маршрутизация. Клиентите с частни тунелни адреси се нуждаят или от NAT на източника на изходния интерфейс на сървъра, или от маршрутизиран префикс, който горната мрежа умее да връща. Изборът между двете следва плана за адресиране. Добавянето на MASQUERADE към мрежа, която вече връща префикса ви по маршрут, е безвредно, но безсмислено, а пропускането му там, където няма маршрут, оставя отговорите адресирани към немаршрутизируем частен диапазон.

Обратният път. При маршрутизирани схеми горният рутер се нуждае от маршрут, сочещ към вашия сървър. Мрежата на доставчика също може да го блокира: няколко облака включват проверка на източника и местоназначението на инстанцията и тя тихо изхвърля пакети, чийто източник не е собственият адрес на инстанцията, докато проверката не бъде изключена.

DNS се проваля по различен начин от маршрутизацията

Пакет към известен адрес и търсене на име са различни откази и съобщенията за грешка подвеждат в противоположни посоки. Ако ping 1.1.1.1 работи, а браузърът не зарежда нищо, маршрутът е наред, а разрешаването на имена не е. Ако самият пинг се провали, DNS е без значение и вие сте обратно в предишния раздел.

wg-quick може да зададе resolver от реда DNS = в конфигурацията, а systemd-resolved има собствено поведение за всяка връзка. VPN, който презаписва resolver с адрес, достъпен само вътре в тунела, ще проваля всяко търсене в момента, в който тунелът падне, което изглежда като тунел, който чупи интернет.

Ред, който дава доказателства

Първо направете проверката от страна на клиента, защото това е една команда и тя елиминира половината възможности. След това потвърдете дали сървърът изобщо е предвиден като изход към интернет; шлюз, изграден за частен достъп, не е счупен, когато публичните местоназначения се провалят.

На сървъра наблюдавайте интерфейса, докато изпращате пинг от клиента: tcpdump -ni wg0 icmp трябва да покаже заявката, а tcpdump -ni eth0 icmp — че тя излиза, транслатена или не. Ако се появи на първия и никога на втория, спирането е локално за сървъра. Ако излезе и не се върне отговор, проблемът е по-горе и това е друг разговор.

Накрая направете така, че поправката да преживее рестарт. Препращането принадлежи във файл на sysctl, правилата на защитната стена — в услугата, която ги зарежда, а маршрутите на клиента — в конфигурацията, която вдига интерфейса, а не в шел, който ще забравите. Свържете се отново, повторете същите две проверки и потвърдете, че броячите се движат.