WireGuard në një hapësirë emrash rrjeti: pse socket-i mbeti pas

Ndërfaqja është e listuar në hapësirën e emrave që dëshironit, aplikacioni është i lidhur me të, dhe megjithatë nuk shfaqet kurrë trafik tuneli. Ky është nënshkrimi i një pajisjeje WireGuard në kernelin e Linux, e krijuar në një hapësirë emrash dhe e zhvendosur në një tjetër: ndërfaqja u zhvendos dhe socket-i UDP i kriptuar i saj nuk u zhvendos. Të dyja duhet të jenë në vendin e duhur përpara se trafiku i brendshëm të ketë rëndësi. Kontrolli është i shpejtë sapo e dini se duhet të shikoni dy kontekste në vend të njërit.

Simptoma: hapësira e emrave e saktë, por pa paketa

Brenda hapësirës së emrave tuneli duket i shëndetshëm. Pajisja ekziston, adresat janë caktuar dhe konfigurimi i homologut është i pranishëm. Jashtë, shkëmbimi i pritur UDP nuk shfaqet kurrë në ndërfaqen që po vëzhgonit, dhe pala tjetër raporton se nuk pati shtrëngim duarsh.

Arsyeja është se paketat e brendshme të aplikacionit arrijnë te pajisja e zhvendosur, dhe pajisja përpiqet t'i dërgojë ato përmes një socket-i që i përket një konteksti tjetër rrjeti. Rruga bazë që përdor, dhe çdo rregull muri zjarri që zbatohet për të, janë ato në hapësirën e emrave ku u krijua pajisja.

Ky nuk është defekt në zhvendosje dhe nuk është konfigurim i gabuar i homologut. Kështu funksionon zbatimi i kernelit, dhe dokumentacioni i hapësirave të emrave për WireGuard përshkruan drejtpërdrejt rregullin e krijimit.

Pse socket-i ka një vend lindjeje

Një pajisje WireGuard zotëron një socket UDP për transportin e saj të kriptuar, dhe ai socket hapet në hapësirën e emrave ku krijohet pajisja. Zhvendosja e ndërfaqes me një komandë lidhjeje zhvendos pajisjen e dukshme, por e lë transportin atje ku filloi. Atëherë dy objektet kanë pronarë të ndryshëm.

Pasoja është e lehtë për t'u anashkaluar, sepse dy gjysmat shqyrtohen në vende të ndryshme. Rruga e brendshme vendoset në hapësirën e emrave ku ekzekutohet aplikacioni, dhe rruga e jashtme vendoset atje ku jeton socket-i. Kontrolli i vetëm njërës jep një përfundim të sigurt, por të gabuar. Kontrolli i të dyjave zakonisht e përfundon hetimin në një kalim.

Krijoni atë atje ku doni socket-in

Zgjidhja është ta krijoni pajisjen brenda hapësirës së emrave të synuar, në vend që ta krijoni jashtë dhe ta zhvendosni. Duke supozuar se një hapësirë emrash e miratuar ekziston tashmë dhe emri është i papërdorur:

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

Tani si ndërfaqja ashtu edhe socket-i i saj i përkasin atij konteksti, kështu që rruga bazë dhe rregullat e filtrimit të zbatueshme janë ato të konfiguruara atje. Nëse dizajni kërkon anën e pastër diku tjetër, vendosni së pari ndërfaqen bazë në hapësirën e emrave dhe më pas krijoni tunelin. Rendi është pjesë e dizajnit, jo një detaj zbatimi.

Trajtojini si komanda administrimi rrjeti, jo si recetë. Ato krijojnë një pajisje dhe tregojnë gjendjen; çelësat, homologët, adresat dhe rrugët duhet ende të vijnë nga një konfigurim i miratuar, dhe një ndërfaqe prodhuese ekzistuese nuk duhet zëvendësuar kurrë në një shembull.

Lexoni të dyja anët e rrugës

Kur pajisja është në vendin e duhur, verifikoni dy vendimet veçmas. Filloni me kërkimin e brendshëm nga konteksti i aplikacionit, më pas kontrolloni rrugën e jashtme nga konteksti që zotëron socket-in:

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

Nëse kërkimi i brendshëm zgjidhet përmes tunelit dhe kapja e jashtme tregon shkëmbimin e kriptuar, të dyja gjysmat përputhen. Nëse kapja është bosh, socket-i është ende diku tjetër, ose rruga bazë në hapësirën e tij të emrave nuk arrin pikën fundore.

Një kontroll tjetër i përket regjistrit: si krijohet pajisja pas një rinisjeje. Një menaxher që rikrijon ndërfaqen me një kontekst tjetër krijimi ndryshon vendin e lindjes së socket-it. Një zhvendosje manuale që funksionoi një herë nuk është provë për rrugën e menaxhuar.