WireGuard працуе на мабільных даных, але не ў той самай wifi-сетцы
Запыт знутры LAN да публічнага адрасу роўтара ідзе іншым шляхам, чым запыт з мабільных даных. Праверце звонку, потым выберыце лакальны шлях.
Тунэль уздымаецца на мабільных даных і потым застаецца на падключэнні дома, з тым самым профілем, тым самым ключом peer і без змен канфігурацыі паміж імі. Розніца ў маршруце: запыт знутры LAN да публічнага адрасу роўтара — не тое самае падарожжа, што запыт, які прыходзіць з інтэрнэту. Большасць хатніх шлюзаў або зусім не рэалізуюць зваротны шлях, або робяць гэта толькі для пэўных пратаколаў. Праз гэта сімптом выглядае як зламаны ключ, хоць з ключом нічога не адбылося. Вызначце, які шлях адмовіў, перш чым чапаць ключ, пракід парта або профіль кліента.
Адзін адрас, два розныя шляхі
Звонку пакет дасягае публічнага адрасу роўтара, і правіла пракіду парта перадае яго слухачу WireGuard на ўнутраным хосце. Знутры кліент набірае той самы публічны адрас, таму пакет выходзіць ад кліента, прыходзіць на роўтар і мусіць быць развернуты назад у бок LAN. Менавіта на гэтым развароце два шляхі разыходзяцца, бо роўтар мусіць трансляваць паток, які адначасова выходзіць і зноў уваходзіць праз той самы інтэрфейс. Многія рэалізацыі адкідаюць яго замест трансляцыі, і кліент тады чакае рукапацісканне, якое так і не было адпраўлена.
Такія паводзіны звычайна называюць NAT loopback або hairpinning, і яны належаць роўтару, а не WireGuard; RFC 4787 апісвае выпадкі трансляцыі, у якіх шлюз можа падтрымліваць яе або не. Сам WireGuard не мае думкі пра шлях, бо бачыць толькі пакеты, што дасягаюць яго інтэрфейсу. Калі роўтар адкідае паток, дэман не атрымлівае нічога, кліент паведамляе пра тайм-аўт рукапаціскання, а журнал сервера застаецца пустым. Пусты журнал таму падказвае, дзе спыніўся пакет, а не даказвае, што сервер упаў. Гэта ж прычына, чаму пераўсталёўка нічога не змяняе.
Зваротнае таксама важнае: журнал сервера, што паказвае спробу рукапаціскання з адрасу LAN, даказвае, што пакет дайшоў і шлях у парадку, а гэта пераносіць расследаванне да ключоў і дазволеных адрасоў. Чытайце журнал дзеля таго, што ён даказвае, а не дзеля таго, што вы спадзяваліся ўбачыць.
Спачатку ўзнавіце, потым змяняйце
Праверце з аўтарызаванай знешняй сеткі з той самай прыладай і тым самым профілем, потым паўтарыце праверку ўнутры LAN, нічога не рэдагуючы. Завершанае рукапацісканне звонку і кліент, які знутры ніколі не пакідае прыладу, узнаўляюць стан замест здагадак. Абедзве спробы мусіць выкарыстоўваць адзін профіль, інакш параўнанне нічога не даказвае.
Потым паглядзіце, у што развязваецца імя канчатковага пункта для гэтай прылады. Тры наступныя каманды таксама паказваюць, які адрас кліент насамрэч набраў:
wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.netПершая каманда паведамляе канчатковы пункт, які інтэрфейс выкарыстоўвае зараз, а дзве іншыя паказваюць, у што імя развязваецца на гэтай машыне. Кліент, які набірае публічны адрас, знаходзячыся ў той самай сетцы, што і сервер, выкарыстоўвае шлях hairpin. Кліент, які набірае адрас LAN, гэтага не робіць, і збой там належыць да іншага расследавання. Гэтая розніца вырашае, ці прыдатны наступны раздзел наогул.
Падтрымоўваныя спосабы дабрацца да блізкага сервера
Найчысцейшая схема — адказ з падзелам гарызонту: публічнае імя развязваецца ў публічны адрас для інтэрнэту і ў адрас LAN сервера для кліентаў унутры. Профіль захоўвае адно імя канчатковага пункта, а рэзалвер выбірае шлях. Для гэтага патрэбен кантроль над унутраным адказам DNS, які хатні роўтар звычайна прапануе, а арганізацыя можа ўладкаваць наўмысна. Без такога кантролю застаюцца функцыя роўтара або другі профіль.
Функцыя роўтара — адлюстраванне: шлюз транслюе паток знутры вонкі і дасылае яго назад унутр. Там, дзе яна працуе, змены кліента не патрэбныя, а там, дзе не працуе, ніякая налада кліента яе не ўратуе. Праверце яе, назіраючы за журналам сервера падчас унутранай спробы, а не чытаючы спіс функцый роўтара.
Праўка профілю на прыватны адрас — гэта дыягностыка, а не праект. Яна даказвае, што сервер адказвае ў LAN, і ламае той самы профіль у тую ж хвіліну, калі ноўтбук выязджае з дому.
| Approach | What it depends on | Where it fails |
|---|---|---|
| Split-horizon name | Control of the internal DNS answer | Clients that resolve through a server outside the zone |
| Router reflection | Gateway support for hairpin translation | Routers that drop the flow silently |
| Private address in the profile | Nothing beyond the LAN | Every network except the one at home |
Трымайце профіль прыдатным па-за домам
Які б шлях вы ні абралі, не чапайце праверку сапраўднасці. Адрас канчатковага пункта — не ідэнтычнасць peer, і змена адрасу ніколі не апраўдвае прыняцце старонняга публічнага ключа, які выпадкова адказвае. WireGuard аўтэнтыфікуе па ключы, таму няправільны хост правальвае рукапацісканне замест таго, каб даць доступ да чагосьці нечаканага.
Калі публічны адрас змяняецца, менавіта дынамічны DNS захоўвае імя карысным, а паводзіны абнаўлення кліента вырашаюць, як хутка змена даедзе. Праверце гэта звонку пасля змены адрасу, бо выпадак LAN гэтага не пацвердзіць. Сачыце за рэзалверам, які кэшуе стары адказ даўжэй за час жыцця запісу. Імя, што дагэтуль паказвае на папярэдні адрас, выглядае дакладна як сервер, які ўпаў.
Запішыце, якое імя выкарыстоўвае профіль і ў што яно развязваецца з кожнага боку мяжы. Профіль, што залежыць ад функцыі роўтара, якую ніхто не зафіксаваў, — гэта званок у падтрымку ў чаканні наступнага абнаўлення прашыўкі. Запіс таксама кажа наступнаму чалавеку, ці ўнутраны збой з’яўляецца вядомым выпадкам hairpin, ці чымсьці новым.