WireGuard darbojas tikai pēc tam, kad serveris nosūta: gala punkta zināšanas

Tunelis šķiet darbojamies tikai pēc tam, kad serveris vispirms kaut ko nosūta. Sāciet no klienta un nekas nenotiek, nogaidiet dažas sekundes, mēģiniet vēlreiz un tas izdodas. Ierastā diagnoze ir salauzts NAT, un ierastā diagnoze ir nepareiza. Mainījies ir tas, ka viena puse uzzināja, kur dzīvo otra.

Gala punkta zināšanas, nevis sasniedzamība

WireGuard puse neuzsāks roku sasveicināšanu, kamēr nezinās, kur to sūtīt. Konfigurācija to nodrošina kā adreses un porta gala punktu, un darbības stāvoklis izseko gala punktu, kuram tā pašlaik tic.

wg show izdrukā abas šī attēla puses, un puse bez gala punkta izvadā neko nevar uzsākt, lai cik pareizs būtu tās publiskā atslēga un atļautie prefiksi. Pirms mainīt jebkuru noteikumu, salīdziniet klienta skatījumu ar servera, jo abi bieži nevienojas par to, kas ko zina.

Kā puse uzzina gala punktu

WireGuard ir apzināti kluss. Kad pareizi autentificēta pakete ierodas no adreses, kuru puse negaidīja, ieviešana atjaunina šīs puses gala punktu uz jauno avotu, un tieši tā darbojas viesošanās klēpjdatorā, kas maina tīklus. Šī uzvedība izskaidro atkarību no virziena: ja serveris nosūta pirmais un tā pakete sasniedz klientu, klients uzzina servera pašreizējo adresi un var atbildēt. Līdz tam tam nav kur sūtīt. Mehānisms ir autentificēta viesošanās, nevis uzticēšanās pirmajā lietošanā saīsne, jo paketei bija jābūt derīgai pirms gala punkta pārvietošanās.

wg rīku dokumentācija apraksta šo atjauninājumu, un to ir vērts izlasīt vienreiz, ja plānojat projektēt ap to.

Stāvokli saglabājoša tulkošana pievieno savu virzienu

Kur UDP iet caur tulkojošu vārteju, vārteja izveido stāvokli pirmajai redzētajai paketei. RFC 4787 apraksta šo uzvedību un termiņus, kas galu galā noņem kartējumu. Neaktīvs kartējums beidzas, un vārteja tad atmet ienākošo paketi no tālās puses, pirms tā sasniedz saimniekdatoru. Tunelis, kas darbojās visu rītu, pēcpusdienā pārstāj atbildēt tieši šī iemesla dēļ.

Šis ir otrs un neatkarīgs mehānisms, kas rada to pašu virziena simptomu. Gan gala punkta zināšanām, gan tulkošanas stāvoklim jābūt pareizam, un viena labošana nelabo otru.

Konfigurējiet virzienu, kuru patiešām vēlaties

Klientam, kuram jāsāk savienojums, ievietojiet servera gala punktu klienta pušu sadaļā un atstājiet to tur. Paļaušanās uz to, ka serveris nosūtīs pirmais, ir paļaušanās uz nejaušību trafika secībā, kas klusā tīklā mainīsies. Konfigurācijai jānorāda paredzētais virziens, nevis tas jāatklāj.

Pusei aiz tulkošanas, kurai jāpaliek sasniedzamai, ieslēdziet noturīgu keepalive tajā pusē. Keepalive ik pēc 25 sekundēm ir ierastā sākuma vērtība, un tā mērķis ir noturēt kartējumu atvērtu, nevis pārbaudīt tuneli. Izvēlieties vienu pusi, kas to nesīs, jo ieslēgšana abās pusēs dubulto trafiku un žurnāla troksni, neuzlabojot rezultātu.

Salīdziniet stāvokli pirms un pēc izraisītāja

Ierakstiet abus skatījumus brīdī, kad tas neizdodas, un pēc tam vēlreiz pēc tam, kad serveris nosūta. Pirmā komanda parāda gala punktus un roku sasveicināšanas vecumu. Otrā parāda, vai portam ir tulkošanas ieraksts. Ieraksts parāda, kurš virziens patiešām šķērsoja vadu, un maršruta pārbaude apstiprina, ka klients šo trafiku nesūta pavisam citur.

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

Pierakstiet gala punkta kolonnu un tulkošanas ierakstu kopā. Puse bez gala punkta un vārteja bez kartējuma ir divi dažādi defekti. Tikai vienu no tiem novērš keepalive.