WireGuard en reta nomspaco: kial la ingo restis malantaŭe

La interfaco estas listigita en la nomspaco, kiun vi volis, la aplikaĵo estas ligita al ĝi, kaj tamen neniu tunela trafiko aperas. Tio estas la signo de WireGuard-aparato en la Linux-kerno, kiu estis kreita en unu nomspaco kaj movita al alia: la interfaco moviĝis kaj ĝia ĉifrita UDP-ingo ne. Ambaŭ devas esti en la ĝusta loko antaŭ ol la interna trafiko gravas. La kontrolo estas rapida, kiam vi scias rigardi du kuntekstojn anstataŭ unu.

La simptomo: ĝusta nomspaco, neniuj pakaĵoj

Ene de la nomspaco la tunelo aspektas sana. La aparato ekzistas, adresoj estas asignitaj, kaj la agordo de la kunulo ĉeestas. Ekstere, la atendata UDP-interŝanĝo neniam aperas sur la interfaco, kiun vi observis, kaj la kontraŭa flanko raportas, ke ne estis manpremo.

La kialo estas, ke la internaj pakaĵoj de la aplikaĵo atingas la movitan aparaton, kaj la aparato provas sendi ilin per ingo, kiu apartenas al alia reta kunteksto. La suba vojo, kiun ĝi uzas, kaj ĉiu fajroŝirma regulo, kiu aplikiĝas al ĝi, estas tiuj en la nomspaco, kie la aparato estis kreita.

Tio ne estas cimo en la movado, kaj ĝi ne estas malĝusta agordo de la kunulo. Tiel funkcias la kerna realigo, kaj la dokumentaro pri nomspacoj por WireGuard priskribas la krean regulon rekte.

Kial la ingo havas naskiĝlokon

WireGuard-aparato posedas unu UDP-ingon por sia ĉifrita transporto, kaj tiu ingo malfermiĝas en la nomspaco, kie la aparato estas kreita. Movi la interfacon per liga komando translokas la videblan aparaton sed lasas la transporton, kie ĝi komenciĝis. Tiam la du objektoj havas malsamajn posedantojn.

La sekvo facile mankas, ĉar la du duonoj estas ekzamenataj en malsamaj lokoj. La interna vojo decidiĝas en la nomspaco, kie la aplikaĵo ruliĝas, kaj la ekstera vojo decidiĝas tie, kie la ingo vivas. Kontroli nur unu el ili donas memcertan sed malĝustan konkludon. Kontroli ambaŭ kutime finas la esploron en unu paŝo.

Kreu ĝin tie, kie vi volas la ingon

La solvo estas krei la aparaton ene de la cela nomspaco anstataŭ krei ĝin ekstere kaj movi ĝin. Supozante, ke aprobita nomspaco jam ekzistas kaj la nomo estas neuzata:

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

Nun kaj la interfaco kaj ĝia ingo apartenas al tiu kunteksto, do la suba vojo kaj la aplikeblaj filtraj reguloj estas tiuj agorditaj tie. Se la dezajno bezonas la klaran flankon aliloke, metu la suban interfacon unue en la nomspacon kaj poste kreu la tunelon. La ordo estas parto de la dezajno, ne efektiviga detalo.

Traktu ilin kiel retadministrajn komandojn, ne kiel recepton. Ili kreas aparaton kaj montras staton; ŝlosiloj, kunuloj, adresoj kaj vojoj ankoraŭ devas veni el aprobita agordo, kaj ekzistanta produktada interfaco neniam estu anstataŭigita en ekzemplo.

Legu ambaŭ flankojn de la vojo

Kiam la aparato estas en la ĝusta loko, kontrolu la du decidojn aparte. Komencu per la interna serĉo el la kunteksto de la aplikaĵo, poste kontrolu la eksteran vojon el la kunteksto, kiu posedas la ingon:

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

Se la interna serĉo solviĝas tra la tunelo kaj la ekstera kaptado montras la ĉifritan interŝanĝon, la du duonoj konsentas. Se la kaptado estas malplena, la ingo ankoraŭ estas aliloke, aŭ la suba vojo en ĝia nomspaco ne atingas la finpunkton.

Ankoraŭ unu kontrolo apartenas al la rikordo: kiel la aparato estas kreata post restartiĝo. Administrilo, kiu rekreas la interfacon kun alia krea kunteksto, ŝanĝas la naskiĝlokon de la ingo. Mana movado, kiu funkciis unufoje, ne estas pruvo pri la administrata vojo.