Рукапацісканне 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 можа задаць рэзалвер з радка DNS = у канфігурацыі, а systemd-resolved мае свае паводзіны для кожнага злучэння. VPN, які перазапісвае рэзалвер адрасам, дасяжным толькі ўнутры тунэля, праваліць кожны пошук у момант падзення тунэля, і гэта выглядае як тунэль, што ламае інтэрнэт.

Парадак, які дае доказы

Спачатку правядзіце праверку на баку кліента, бо гэта адна каманда і яна адсякае палову магчымасцей. Затым пераканайцеся, што сервер наогул прызначаны быць выхадам у інтэрнэт; шлюз, пабудаваны для прыватнага доступу, не зламаны, калі публічныя прызначэнні не дасягальныя.

На серверы назірайце за інтэрфейсам, пакуль адпраўляеце пінг з кліента: tcpdump -ni wg0 icmp павінен паказаць запыт, а tcpdump -ni eth0 icmp — што ён выходзіць, трансляваны ён ці не. Калі ён з’яўляецца на першым і ніколі на другім, спыненне адбываецца лакальна на серверы. Калі ён выходзіць, а адказу няма, праблема вышэй, і гэта ўжо іншая размова.

Нарэшце зрабіце так, каб выпраўленне перажыло перазапуск. Перасылка належыць у файл sysctl, правілы файрвола — у службу, якая іх загружае, а маршруты кліента — у канфігурацыю, якая ўзнімае інтэрфейс, а не ў абалонку, якую вы забудзеце. Перападключыцеся, паўтарыце тыя ж два выпрабаванні і пераканайцеся, што лічыльнікі рухаюцца.