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, или нещо ново.