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.