WireGuard radi tek nakon što server prvi pošalje: znanje o krajnjoj točki

Tunel izgleda kao da radi samo nakon što server prvi nešto pošalje. Krenite s klijenta i ništa se ne događa, pričekajte nekoliko sekundi, pokušajte ponovno i uspijeva. Uobičajena dijagnoza je pokvaren NAT, a uobičajena dijagnoza je pogrešna. Promijenilo se to da je jedna strana saznala gdje se nalazi druga.

Znanje o krajnjoj točki, a ne dostupnost

WireGuard strana neće započeti rukovanje dok ne zna kamo ga poslati. Konfiguracija to daje kao krajnju točku od adrese i porta, a radno stanje prati krajnju točku u koju trenutačno vjeruje.

wg show ispisuje obje strane te slike, a strana bez krajnje točke u ispisu ne može ništa započeti, koliko god njezin javni ključ i dopušteni prefiksi bili ispravni. Usporedite klijentov pogled s poslužiteljevim prije nego promijenite bilo koje pravilo, jer se njih dvoje često ne slažu oko toga tko što zna.

Kako strana sazna krajnju točku

WireGuard je namjerno tih. Kad ispravno autentificirani paket stigne s adrese koju strana nije očekivala, implementacija ažurira krajnju točku te strane na novi izvor, i tako radi roaming na prijenosniku koji mijenja mreže. To ponašanje objašnjava ovisnost o smjeru: ako server pošalje prvi i njegov paket stigne do klijenta, klijent sazna trenutačnu adresu servera i može odgovoriti. Do tada nema kamo poslati. Mehanizam je autentificirani roaming, a ne prečac povjerenja pri prvom korištenju, jer je paket morao biti valjan prije nego se krajnja točka pomaknula.

Dokumentacija alata za wg opisuje to ažuriranje i vrijedi je jednom pročitati ako ćete graditi dizajn oko toga.

Prijevod sa stanjem dodaje vlastiti smjer

Kad UDP prolazi kroz prijevodni gateway, gateway stvara stanje za prvi paket koji vidi. RFC 4787 opisuje to ponašanje i vremenske rokove koji na kraju uklanjaju mapiranje. Neaktivno mapiranje istječe, a dolazni paket s druge strane tada gateway odbacuje prije nego stigne do hosta. Tunel koji je radio cijelo jutro prestaje odgovarati poslijepodne upravo zbog toga.

Ovo je drugi i neovisni mehanizam koji proizvodi isti simptom smjera. I znanje o krajnjoj točki i prijevodno stanje moraju biti ispravni, a popravak jednoga ne popravlja drugo.

Konfigurirajte smjer koji stvarno želite

Za klijenta koji mora započeti vezu, stavite serverovu krajnju točku u klijentov odjeljak strana i ostavite je ondje. Oslanjanje na to da će server poslati prvi jest oslanjanje na slučajnost u redoslijedu prometa koja će se promijeniti na tihoj mreži. Konfiguracija treba navesti namjeravani smjer, a ne otkriti ga.

Za stranu iza prijevoda koja mora ostati dostupna, omogućite trajni keepalive na toj strani. Keepalive svakih 25 sekundi uobičajena je početna vrijednost, a svrha mu je držati mapiranje otvorenim, a ne testirati tunel. Odaberite jednu stranu da ga nosi, jer omogućavanje na obje udvostručuje promet i šum u zapisniku bez poboljšanja rezultata.

Usporedite stanje prije i poslije okidača

Snimite dva pogleda u trenutku kad ne uspije, pa ponovno nakon što server pošalje. Prva naredba pokazuje krajnje točke i starost rukovanja. Druga pokazuje postoji li prijevodni zapis za port. Snimka pokazuje koji je smjer stvarno prešao žicu, a provjera rute potvrđuje da klijent taj promet ne šalje posve drugamo.

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

Zabilježite stupac krajnje točke i prijevodni zapis zajedno. Strana bez krajnje točke i gateway bez mapiranja dvije su različite greške. Samo jednu od njih popravlja keepalive.