WireGuard într-un spațiu de nume de rețea: de ce socketul a rămas în urmă

Interfața apare în spațiul de nume dorit, aplicația este legată de ea și totuși nu apare niciodată trafic al tunelului. Aceasta este semnătura unui dispozitiv WireGuard din nucleul Linux creat într-un spațiu de nume și mutat în altul: interfața s-a mutat, iar socketul UDP criptat nu. Ambele trebuie să fie în locul potrivit înainte ca traficul interior să conteze. Verificarea este rapidă odată ce știți că trebuie privite două contexte, nu unul.

Simptomul: spațiu de nume corect, fără pachete

În interiorul spațiului de nume tunelul pare sănătos. Dispozitivul există, adresele sunt atribuite și configurația perechii este prezentă. În exterior, schimbul UDP așteptat nu apare niciodată pe interfața pe care o urmăreați, iar partea cealaltă raportează că nu a existat nicio strângere de mână.

Motivul este că pachetele interioare ale aplicației ajung la dispozitivul mutat, iar dispozitivul încearcă să le trimită printr-un socket care aparține altui context de rețea. Ruta de bază pe care o folosește și fiecare regulă de firewall care se aplică acesteia sunt cele din spațiul de nume în care a fost creat dispozitivul.

Nu este un defect al mutării și nici o configurare greșită a perechii. Așa funcționează implementarea nucleului, iar documentația spațiilor de nume pentru WireGuard descrie direct regula de creare.

De ce socketul are un loc de naștere

Un dispozitiv WireGuard deține un socket UDP pentru transportul său criptat, iar acel socket este deschis în spațiul de nume în care este creat dispozitivul. Mutarea interfeței cu o comandă de legătură mută dispozitivul vizibil, dar lasă transportul acolo unde a început. Atunci cele două obiecte au proprietari diferiți.

Consecința este ușor de ratat pentru că cele două jumătăți sunt inspectate în locuri diferite. Ruta interioară este decisă în spațiul de nume în care rulează aplicația, iar ruta exterioară este decisă acolo unde trăiește socketul. Verificarea doar a uneia produce o concluzie sigură, dar greșită. Verificarea ambelor încheie de obicei investigația într-o singură trecere.

Creați-l acolo unde vreți socketul

Soluția este să creați dispozitivul în interiorul spațiului de nume țintă, în loc să îl creați afară și să îl mutați. Presupunând că există deja un spațiu de nume aprobat și că numele este neutilizat:

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

Acum atât interfața, cât și socketul ei aparțin acelui context, deci ruta de bază și regulile de filtrare aplicabile sunt cele configurate acolo. Dacă proiectul are nevoie de partea clară în altă parte, puneți mai ântâi interfața de bază în spațiul de nume și apoi creați tunelul. Ordinea face parte din proiect, nu este un detaliu de implementare.

Tratați-le ca pe comenzi de administrare a rețelei, nu ca pe o rețetă. Ele creează un dispozitiv și arată starea; cheile, perechile, adresele și rutele trebuie totuși să vină dintr-o configurație aprobată, iar o interfață de producție existentă nu ar trebui niciodată înlocuită într-un exemplu.

Citiți ambele părți ale căii

Când dispozitivul este în locul potrivit, verificați cele două decizii separat. Începeți cu căutarea interioară din contextul aplicației, apoi verificați calea exterioară din contextul care deține socketul:

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

Dacă căutarea interioară se rezolvă prin tunel și captura exterioară arată schimbul criptat, cele două jumătăți sunt de acord. Dacă captura este goală, socketul este încă în altă parte, sau ruta de bază din spațiul său de nume nu ajunge la punctul final.

Încă o verificare aparține înregistrării: cum este creat dispozitivul după o repornire. Un manager care recreează interfața cu un alt context de creare schimbă locul de naștere al socketului. O mutare manuală care a funcționat o dată nu este dovadă despre calea gestionată.