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

Sučelje je navedeno 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 stvoren u jednom imenskom prostoru i premješten u drugi: sučelje se premjestilo, a njegov šifrirani UDP socket nije. Oboje mora biti na pravom mjestu prije nego unutarnji promet postane važan. Provjera je brza kada znate da treba gledati dva konteksta umjesto jednoga.

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 sučelju koje ste promatrali, a suprotna strana javlja da nema rukovanja.

Razlog je to što unutarnji paketi aplikacije stižu do premještenog uređaja, a uređaj ih pokušava poslati kroz socket koji pripada drugom mrežnom kontekstu. Temeljna ruta koju koristi i svako pravilo vatrozida koje se na njega primjenjuje jesu ona u imenskom prostoru u kojem je uređaj stvoren.

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 otvara se u imenskom prostoru u kojem je uređaj stvoren. Premještanje sučelja 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 polovice pregledavaju na različitim mjestima. Unutarnja ruta odlučuje se u imenskom prostoru u kojem aplikacija radi, a vanjska ruta odlučuje se tamo gdje socket živi. Provjera samo jedne daje samouvjeren, ali pogrešan zaključak. Provjera obiju obično završava istragu u jednom prolazu.

Stvorite ga tamo gdje želite socket

Rješenje je stvoriti uređaj unutar ciljnog imenskog prostora, umjesto da ga stvorite 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 sučelje i njegov socket pripadaju tom kontekstu, pa su temeljna ruta i primjenjiva pravila filtriranja ona koja su tamo konfigurirana. Ako dizajn traži čistu stranu negdje drugdje, prvo stavite temeljno sučelje u imenski prostor, a zatim stvorite tunel. Redoslijed je dio dizajna, a ne detalj implementacije.

Tretirajte ih kao naredbe mrežne administracije, 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će proizvodno sučelje 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 unutarnjim 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 unutarnje pretraživanje razriješi kroz tunel i vanjsko snimanje pokaže šifriranu razmjenu, obje se polovice slažu. Ako je snimanje prazno, socket je još negdje drugdje ili temeljna ruta u njegovu 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 sučelje s drugim kontekstom stvaranja mijenja mjesto rođenja socketa. Ručno premještanje koje je jednom uspjelo nije dokaz o upravljanom putu.