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.