WireGuard u mrežnom imenskom prostoru: zašto je socket ostao iza

Interfejs je naveden u imenskom prostoru koji ste željeli, aplikacija je vezana za njega, a promet tunela se ipak nikad ne pojavi. To je znak WireGuard uređaja u Linux kernelu koji je napravljen u jednom imenskom prostoru i premješten u drugi: interfejs se premjestio, a njegov šifrirani UDP socket nije. Oboje mora biti na pravom mjestu prije nego unutrašnji promet bude važan. Provjera je brza kada znate da treba gledati dva konteksta umjesto jednog.

Simptom: pravi imenski prostor, nema paketa

Unutar imenskog prostora tunel izgleda zdravo. Uređaj postoji, adrese su dodijeljene, a konfiguracija partnera je prisutna. Izvana se očekivana UDP razmjena nikad ne pojavi na interfejsu koji ste promatrali, a suprotna strana javlja da nema rukovanja.

Razlog je to što unutrašnji paketi aplikacije stižu do premještenog uređaja, a uređaj ih pokušava poslati kroz socket koji pripada drugom mrežnom kontekstu. Osnovna ruta koju koristi i svako pravilo zaštitnog zida koje se na njega primjenjuje jesu oni u imenskom prostoru u kojem je uređaj napravljen.

To nije greška u premještanju i nije pogrešna konfiguracija partnera. Tako implementacija kernela radi, a dokumentacija o imenskim prostorima za WireGuard izravno opisuje pravilo stvaranja.

Zašto socket ima mjesto rođenja

WireGuard uređaj posjeduje jedan UDP socket za svoj šifrirani prijenos, a taj socket se otvara u imenskom prostoru u kojem je uređaj napravljen. Premještanje interfejsa naredbom za vezu premješta vidljivi uređaj, a prijenos ostaje tamo gdje je počeo. Tada dva objekta imaju različite vlasnike.

Posljedicu je lako propustiti jer se polovine pregledaju na različitim mjestima. Unutrašnja ruta se odlučuje u imenskom prostoru u kojem aplikacija radi, a vanjska ruta se odlučuje tamo gdje socket živi. Provjera samo jedne daje samouvjeren, ali pogrešan zaključak. Provjera obiju obično završava istragu u jednom prolazu.

Napravite ga tamo gdje želite socket

Rješenje je napraviti uređaj unutar ciljnog imenskog prostora, umjesto da ga napravite izvana i premjestite. Uz pretpostavku da odobreni imenski prostor već postoji i da je ime neiskorišteno:

ip netns exec vpn-apps ip link add wg-demo type wireguard
ip netns exec vpn-apps wg show

Sada i interfejs i njegov socket pripadaju tom kontekstu, pa su osnovna ruta i primjenjiva pravila filtriranja ona koja su tamo konfigurirana. Ako dizajn traži čistu stranu negdje drugdje, prvo stavite temeljni interfejs u imenski prostor, a zatim napravite tunel. Redoslijed je dio dizajna, a ne detalj implementacije.

Tretirajte ih kao naredbe za mrežnu administraciju, ne kao recept. One stvaraju uređaj i prikazuju stanje; ključevi, partneri, adrese i rute i dalje moraju doći iz odobrene konfiguracije, a postojeći proizvodni interfejs nikada se ne smije staviti u primjer.

Čitajte obje strane puta

Kada je uređaj na pravom mjestu, provjerite dvije odluke odvojeno. Počnite s unutrašnjim pretraživanjem iz konteksta aplikacije, zatim provjerite vanjski put iz konteksta koji posjeduje socket:

ip netns exec vpn-apps ip route get 10.30.0.9
ip netns exec vpn-apps wg show
tcpdump -ni any udp port 51820

Ako se unutrašnje pretraživanje razriješi kroz tunel i vanjsko snimanje pokaže šifriranu razmjenu, obje polovine se slažu. Ako je snimanje prazno, socket je još negdje drugdje ili osnovna ruta u njegovom imenskom prostoru ne doseže krajnju točku.

Još jedna provjera pripada u zapis: kako se uređaj stvara nakon ponovnog pokretanja. Upravitelj koji ponovno stvara interfejs s drugim kontekstom stvaranja mijenja mjesto rođenja socketa. Ručno premještanje koje je jednom uspjelo nije dokaz o upravljanom putu.