WireGuard працуе толькі пасля таго, як сервер адправіць: веданне эндпоінта

Тунель выглядае так, быццам працуе толькі пасля таго, як сервер спачатку нешта адправіць. Пачніце з кліента — нічога не адбываецца, пачакайце некалькі секунд, паспрабуйце зноў — і ўсё атрымліваецца. Звычайны дыягназ — зламаны NAT, і звычайны дыягназ няправільны. Змянілася тое, што адзін бок даведаўся, дзе знаходзіцца другі.

Веданне эндпоінта, а не дасяжнасць

Бок WireGuard не пачне рукапоціск, пакуль не даведаецца, куды яго адпраўляць. Канфігурацыя падае гэта як эндпоінт з адраса і порта, а бягучы стан трымае эндпоінт, у які ён зараз верыць.

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

Як бок даведваецца пра эндпоінт

WireGuard наўмысна маўклівы. Калі правільна аўтэнтыфікаваны пакет прыходзіць з адраса, якога бок не чакаў, рэалізацыя абнаўляе эндпоінт гэтага боку на новую крыніцу, і менавіта так працуе роўмінг на ноўтбуку, які змяняе сеткі. Такія паводзіны тлумачаць залежнасць ад кірунку: калі сервер адпраўляе першым і яго пакет дасягае кліента, кліент даведваецца бягучы адрас сервера і можа адказаць. Да гэтага яму няма куды слаць. Механізм — гэта аўтэнтыфікаваны роўмінг, а не скарот «давер пры першым выкарыстанні», бо пакет павінен быў быць сапраўдным яшчэ да змены эндпоінта.

Дакументацыя да wg апісвае гэтае абнаўленне, і яе варта прачытаць адзін раз, калі вы збіраецеся праектаваць вакол гэтага.

Трансляцыя са станам дадае свой кірунак

Калі UDP праходзіць праз шлюз, які займаецца трансляцыяй, шлюз стварае стан для першага ўбачанага пакета. RFC 4787 апісвае гэтыя паводзіны і тайм-аўты, якія з цягам часу выдаляюць адлюстраванне. Прастойнае адлюстраванне сканчаецца, і ўваходны пакет з далёкага боку тады адкідаецца шлюзам яшчэ да таго, як дасягне хоста. Тунель, які працаваў усю раніцу, менавіта з гэтай прычыны перастае адказваць пасля абеду.

Гэта другі і незалежны механізм, які дае той самы сімптом па кірунку. І веданне эндпоінта, і стан трансляцыі павінны быць правільнымі, і выпраўленне аднаго не выпраўляе другога.

Наладзьце той кірунак, які вам сапраўды патрэбны

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

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

Параўнайце стан да і пасля трыгера

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

wg show
conntrack -L -p udp 2>/dev/null | grep 51820
tcpdump -ni any -c 20 'udp port 51820'
ip route get 198.51.100.7

Запішыце слупок эндпоінта і запіс трансляцыі разам. Бок без эндпоінта і шлюз без адлюстравання — дзве розныя няспраўнасці. Толькі адну з іх выпраўляе keepalive.