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

Interfejs je naveden u imenskom prostoru koji ste želeli, aplikacija je vezana za njega, a saobraćaj tunela se ipak nikad ne pojavi. To je znak WireGuard uređaja u Linux kernelu koji je napravljen u jednom imenskom prostoru i premešten u drugi: interfejs se premestio, a njegov šifrovani UDP socket nije. Oba moraju biti na pravom mestu pre nego što unutrašnji saobraćaj bude važan. Provera je brza kada znate da treba gledati dva konteksta umesto jednog.

Simptom: pravi imenski prostor, nema paketa

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

Razlog je to što unutrašnji paketi aplikacije stižu do premeštenog uređaja, a uređaj pokušava da ih pošalje kroz socket koji pripada drugom mrežnom kontekstu. Osnovna ruta koju koristi i svako pravilo firewall-a koje se na njega primenjuje jesu ona u imenskom prostoru u kojem je uređaj napravljen.

To nije greška u premeš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 mesto rođenja

WireGuard uređaj poseduje jedan UDP socket za svoj šifrovani prenos, a taj socket se otvara u imenskom prostoru u kojem je uređaj napravljen. Premeštanje interfejsa naredbom za vezu premešta vidljivi uređaj, a prenos ostaje tamo gde je počeo. Tada dva objekta imaju različite vlasnike.

Posledicu je lako propustiti jer se polovine pregledaju na različitim mestima. Unutrašnja ruta odlučuje se u imenskom prostoru u kojem aplikacija radi, a spoljna ruta odlučuje se tamo gde socket živi. Provera samo jedne daje samouveren, ali pogrešan zaključak. Provera obeju obično završava istragu u jednom prolazu.

Napravite ga tamo gde želite socket

Rešenje je da napravite uređaj unutar ciljnog imenskog prostora, umesto da ga napravite spolja i premestite. Uz pretpostavku da odobreni imenski prostor već postoji i da je ime neiskorišćeno:

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 primenljiva pravila filtriranja ona koja su tamo konfigurisana. Ako dizajn traži čistu stranu negde drugde, prvo stavite osnovni interfejs u imenski prostor, a zatim napravite tunel. Redosled je deo 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ći proizvodni interfejs nikada se ne sme staviti u primer.

Čitajte obe strane puta

Kada je uređaj na pravom mestu, proverite dve odluke odvojeno. Počnite sa unutrašnjim pretraživanjem iz konteksta aplikacije, zatim proverite spoljni put iz konteksta koji poseduje 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 razreši kroz tunel i spoljno snimanje pokaže šifrovanu razmenu, obe polovine se slažu. Ako je snimanje prazno, socket je još negde drugde ili osnovna ruta u njegovom imenskom prostoru ne doseže krajnju tačku.

Još jedna provera pripada u zapis: kako se uređaj stvara nakon ponovnog pokretanja. Upravljač koji ponovo stvara interfejs sa drugim kontekstom stvaranja menja mesto rođenja socketa. Ručno premeštanje koje je jednom uspelo nije dokaz o upravljanom putu.