WireGuard võrgu nimeruumis: miks socket maha jäi

Liides on loetletud nimeruumis, mida soovisite, rakendus on sellega seotud, ja ometi ei ilmu kunagi tunneliliiklust. See on Linuxi tuuma WireGuard-seadme tunnus, mis loodi ühes nimeruumis ja teisaldati teise: liides liikus, kuid selle krüptitud UDP-socket mitte. Mõlemad peavad olema õiges kohas, enne kui sisemine liiklus loeb. Kontroll on kiire, kui tead, et vaadata tuleb kahte konteksti, mitte ühte.

Sümptom: õige nimeruum, kuid pakette pole

Nimeruumi sees näeb tunnel terve välja. Seade on olemas, aadressid on määratud ja partneri konfiguratsioon on olemas. Väljastpoolt ei ilmu oodatud UDP-vahetus kunagi liidesel, mida jälgisite, ja vastaspool teatab, et käepigistust ei toimunud.

Põhjus on selles, et rakenduse sisemised paketid jõuavad teisaldatud seadmeni ja seade üritab neid saata socketi kaudu, mis kuulub teise võrgukonteksti. Alusvõrgu marsruut, mida see kasutab, ja iga tulemüürireegel, mis sellele kehtib, on need, mis asuvad nimeruumis, kus seade loodi.

See ei ole teisaldamise viga ega partneri vale konfiguratsioon. Nii käitub tuuma teostus ja WireGuardi nimeruumide dokumentatsioon kirjeldab loomisreeglit otseselt.

Miks socketil on sünnikoht

WireGuardi seadmel on krüptitud transpordi jaoks üks UDP-socket ja see socket avatakse nimeruumis, kus seade luuakse. Liidese teisaldamine lingikäsuga teisaldab nähtava seadme, kuid jätab transpordi sinna, kus see algas. Siis on kahel objektil erinevad omanikud.

Tagajärge on lihtne tähelepanuta jätta, sest pooli uuritakse erinevates kohtades. Sisemine marsruut otsustatakse nimeruumis, kus rakendus töötab, ja välimine marsruut otsustatakse seal, kus socket elab. Ainult ühe kontrollimine annab enesekindla, kuid vale järelduse. Mõlema kontrollimine lõpetab uurimise tavaliselt ühe käiguga.

Looge see seal, kus soovite socketit

Lahendus on luua seade sihtnimeruumi sees, mitte luua seda väljaspool ja teisaldada. Eeldades, et kinnitatud nimeruum on juba olemas ja nimi on kasutamata:

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

Nüüd kuuluvad nii liides kui ka selle socket sellele kontekstile, seega alusvõrgu marsruut ja kohaldatavad filtrireeglid on need, mis on seal konfigureeritud. Kui disain vajab selget poolt mujal, asetage esmalt alusliides nimeruumi ja seejärel looge tunnel. Järjekord on disaini osa, mitte teostuse detail.

Käsitlege neid võrgu haldamise käskudena, mitte retseptina. Need loovad seadme ja näitavad olekut; võtmed, partnerid, aadressid ja marsruudid peavad ikkagi tulema kinnitatud konfiguratsioonist ning olemasolevat tootmiskeskkonna liidest ei tohi kunagi näites asendada.

Lugege tee mõlemat poolt

Kui seade on õiges kohas, kontrollige kahte otsust eraldi. Alustage sisemisest otsingust rakenduse kontekstist ja seejärel kontrollige välimist teed kontekstist, millele socket kuulub:

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

Kui sisemine otsing laheneb tunneli kaudu ja välimine püüdmine näitab krüptitud vahetust, on mõlemad pooled kooskõlas. Kui püüdmine on tühi, on socket veel mujal või ei jõua selle nimeruumi alusvõrgu marsruut lõpp-punktini.

Kirjesse kuulub veel üks kontroll: kuidas seade pärast taaskäivitust luuakse. Haldur, kes loob liidese uuesti teistsuguse loomiskontekstiga, muudab socketi sünnikohta. Ühekordselt töötanud käsitsi teisaldamine ei ole tõend hallatava tee kohta.