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 или нешто ново.