Şəbəkə adlar məkanında WireGuard: soket niyə geridə qaldı

İnterfeys istədiyiniz adlar məkanında görünür, tətbiq ona bağlıdır, amma tunel trafiki heç vaxt görünmür. Bu, Linux nüvəsində bir adlar məkanında yaradılıb digərinə köçürülmüş WireGuard cihazının əlamətidir: interfeys köçdü, şifrələnmiş UDP soketi isə köçmədi. Daxili trafikin əhəmiyyəti olması üçün hər ikisi düzgün yerdə olmalıdır. Yoxlama sürətlidir, kifayətdir ki, bir deyil, iki kontekstə baxmaq lazım olduğunu biləsiniz.

Simptom: düzgün adlar məkanı, paket yoxdur

Adlar məkanının içində tunel sağlam görünür. Cihaz mövcuddur, ünvanlar təyin edilib və peer konfiqurasiyası yerindədir. Çöldə isə gözlənilən UDP mübadiləsi izlədiyiniz interfeysdə heç vaxt görünmür və qarşı tərəf heç bir əl sıxma bildirmir.

Səbəb ondadır ki, tətbiqin daxili paketləri köçürülmüş cihaza çatır, cihaz isə onları başqa şəbəkə kontekstinə aid soketdən göndərməyə çalışır. İstifadə etdiyi əsas marşrut və ona tətbiq olunan hər firewall qaydası cihazın yaradıldığı adlar məkanındakılardır.

Bu, köçürmədə səhv deyil və peer-in yanlış konfiqurasiyası da deyil. Nüvə tətbiqi belə işləyir və WireGuard üçün adlar məkanı sənədləri yaradılma qaydasını birbaşa təsvir edir.

Soketin niyə doğulduğu yeri var

WireGuard cihazı şifrələnmiş daşıması üçün bir UDP soketinə sahibdir və bu soket cihazın yaradıldığı adlar məkanında açılır. İnterfeysi link əmri ilə köçürmək görünən cihazın yerini dəyişir, daşımanı isə başladığı yerdə qoyur. Sonra iki obyektin sahibləri fərqli olur.

Nəticəni qaçırmaq asandır, çünki yarılar fərqli yerlərdə yoxlanılır. Daxili marşrut tətbiqin işlədiyi adlar məkanında, xarici marşrut isə soketin yaşadığı yerdə müəyyən edilir. Onlardan yalnız birini yoxlamaq arxayın, amma səhv nəticə verir. İkisini birlikdə yoxlamaq isə araşdırmanı adətən bir keçiddə bitirir.

Onu soketi istədiyiniz yerdə yaradın

Həll cihazı kənarda yaradıb köçürmək əvəzinə hədəf adlar məkanının içində yaratmaqdır. Tutaq ki, təsdiqlənmiş adlar məkanı artıq mövcuddur və ad istifadə olunmur:

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

İndi həm interfeys, həm də onun soketi həmin kontekstə aiddir, yəni əsas marşrut və tətbiq olunan filtr qaydaları orada qurulanlardır. Əgər dizayn şifrələnməmiş tərəfi başqa yerdə tələb edirsə, əvvəlcə əsas interfeysi adlar məkanına qoyun, sonra tuneli yaradın. Sıra dizaynın bir hissəsidir, tətbiq detalları deyil.

Bunlara resept kimi deyil, şəbəkə idarəetmə əmrləri kimi yanaşın. Onlar cihaz yaradır və vəziyyəti göstərir; açarlar, peer-lər, ünvanlar və marşrutlar yenə də təsdiqlənmiş konfiqurasiyadan gəlməlidir və mövcud istehsal interfeysi heç vaxt nümunəyə əvəz edilməməlidir.

Yolun hər iki tərəfini oxuyun

Cihaz düzgün yerdə olduqdan sonra iki qərarı ayrıca yoxlayın. Əvvəlcə tətbiqin kontekstindən daxili axtarışa başlayın, sonra soketə sahib kontekstdən xarici yolu yoxlayın:

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

Daxili axtarış tuneldən keçərək həll olunursa və xarici tutma şifrələnmiş mübadiləni göstərirsə, hər iki yarım uyğundur. Tutma boşdursa, soket hələ də başqa yerdədir və ya onun adlar məkanındakı əsas marşrut son nöqtəyə çatmır.

Qeydə daha bir yoxlama daxildir: cihazın yenidən başlatmadan sonra necə yaradıldığı. İnterfeysi fərqli yaradılma konteksti ilə yenidən yaradan menecer soketin doğulduğu yeri dəyişir. Bir dəfə işləmiş əl ilə köçürmə idarə olunan yol haqqında sübut deyil.