WireGuard í netnafnrými: hvers vegna sokkinn varð eftir

Viðmótið er skráð í nafnrýminu sem þú vildir, forritið er bundið við það, og samt birtist aldrei nein gangnaumferð. Þetta er einkenni WireGuard-tækis í Linux-kjarnanum sem var búið til í einu nafnrými og flutt í annað: viðmótið fluttist en dulkóðaði UDP-sokkurinn þess ekki. Bæði verða að vera á réttum stað áður en innri umferðin skiptir máli. Athugunin er fljót þegar maður veit að horfa á tvö samhengi í stað eins.

Einkennið: rétt nafnrými, engar pakkningar

Inni í nafnrýminu virðist göngin heilbrigð. Tækið er til, netföngum hefur verið úthlutað og stilling jafningjans er til staðar. Úti birtist vænt UDP-skipti aldrei á viðmótinu sem þú fylgdist með, og hin hliðin tilkynnir að engin handaband hafi átt sér stað.

Ástæðan er sú að innri pakkar forritsins ná til flutta tækisins, og tækið reynir að senda þá um sokk sem tilheyrir öðru netssamhengi. Undirliggjandi leiðin sem það notar, og hver eldveggjarregla sem gildir um hana, eru þær í nafnrýminu þar sem tækið var búið til.

Þetta er ekki villa í flutningnum og ekki röng stilling jafningjans. Svona hagar kjarnaframkvæmdin sér, og skjölun nafnrýma fyrir WireGuard lýsir sköpununarreglunni beint.

Hvers vegna sokkinn á sér fæðingarstað

WireGuard-tæki á einn UDP-sokk fyrir dulkóðaða flutninginn sinn, og sá sokkur er opnaður í nafnrýminu þar sem tækið er búið til. Að færa viðmótið með hlekkjskipun færir sýnilega tækið en lætur flutninginn vera þar sem hann hófst. Þa eiga hlutirnir tveir mismunandi eigendur.

Afleiðinguna er auðvelt að missa af því hálfurnar tvær eru skoðaðar á mismunandi stöðum. Innri leiðin er ákveðin í nafnrýminu þar sem forritið keyrir, og ytri leiðin er ákveðin þar sem sokkinn býr. Að athuga aðeins aðra þeirra gefur örugga en ranga niðurstöðu. Að athuga báðar lýkur rannsókninni venjulega í einni lotu.

Búðu það til þar sem þú vilt sokkinn

Lausnin er að búa tækið til inni í marknafnrýminu í stað þess að búa það til fyrir utan og flytja það. Að því gefnu að samþykkt nafnrými sé þegar til og nafnið sé ónotað:

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

Nú tilheyra bæði viðmótið og sokkinn þessu samhengi, svo undirliggjandi leiðin og gildandi síunarreglur eru þær sem stilltar eru þar. Ef hönnunin þarf hreinu hliðina annars staðar, settu undirliggjandi viðmótið fyrst í nafnrýmið og búðu göngin til á eftir. Röðin er hluti af hönnuninni, ekki úftærsluatriði.

Meðhöndlaðu þetta sem netstjórnunarskipanir, ekki uppskrift. Þær búa til tæki og sýna stöðu; lyklar, jafningjar, netföng og leiðir verða samt að koma frá samþykktri stillingu, og aldrei ætti að setja núverandi framleiðsluviðmót í dæmi.

Lestu báðar hliðar leiðarinnar

Þegar tækið er á réttum stað, staðfestu ákvarðanirnar tvær sitt í hvoru lagi. Byrjaðu á innri uppflettingunni frá samhengi forritsins og athugaðu síðan ytri leiðina frá samhenginu sem á sokkinn:

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

Ef innri uppflettingin leysist í gegnum göngin og ytri skráningin sýnir dulkóðuðu skiptin, eru hálfurnar sammála. Ef skráningin er tóm er sokkinn enn annars staðar, eða undirliggjandi leiðin í nafnrými hans nær ekki endapunktinum.

Ein athugun til viðbótar á heima í skránni: hvernig tækið er búið til eftir endurræsingu. Stjórnandi sem býr viðmótið til á ný með öðru sköpunarsamhengi breytir fæðingarstað sokkans. Handvirkur flutningur sem virkaði einu sinni er ekki sönnun um stýrðu leiðina.