WireGuard ў сеткавым прасторы імёнаў: чаму сокет застаўся на месцы

Інтэрфейс пералічаны ў прасторы імёнаў, якую вы хацелі, праграма прывязана да яго, а трафік тунеля так і не з'яўляецца. Гэта адметнасць прылады WireGuard у ядры Linux, створанай у адной прасторы імёнаў і перанесенай у іншую: інтэрфейс перамясціўся, а яго зашыфраваны сокет UDP — не. Абодва павінны знаходзіцца ў правільным месцы, перш чым унутраны трафік будзе мець значэнне. Праверка хуткая, калі ведаць, што глядзець трэба на два кантэксты, а не на адзін.

Сімптом: правільная прастора імёнаў, але пакетаў няма

Унутры прасторы імёнаў тунель выглядае здаровым. Прылада існуе, адрасы прызначаны, канфігурацыя партнёра прысутнічае. Звонку чаканы абмен UDP ніколі не з'яўляецца на інтэрфейсе, за якім вы назіралі, а супрацьлеглы бок паведамляе пра адсутнасць рукапаціску.

Прычына ў тым, што ўнутраныя пакеты праграмы дасягаюць перанесенай прылады, а прылада спрабуе адправіць іх праз сокет, які належыць іншаму сеткаваму кантэксту. Маршрут асновы, які яна выкарыстоўвае, і кожнае правіла фільтра, якое да яго прымяняецца, — гэта тыя, што ў прасторы імёнаў, дзе была створана прылада.

Гэта не памылка пераносу і не няправільная канфігурацыя партнёра. Так працуе рэалізацыя ядра, і дакументацыя па прасторах імёнаў для WireGuard непасрэдна апісвае правіла стварэння.

Чаму ў сокета ёсць месца нараджэння

Прылада WireGuard валодае адным сокетам UDP для зашыфраванага транспарту, і гэты сокет адкрываецца ў прасторы імёнаў, дзе ствараецца прылада. Перанос інтэрфейса камандай звязвання перамяшчае бачную прыладу, пакідаючы транспарт там, дзе ён пачаўся. Тады ў двух аб'ектаў розныя ўласнікі.

Наступства лёгка прапусціць, бо паловы аглядаюцца ў розных месцах. Унутраны маршрут вызначаецца ў прасторы імёнаў, дзе працуе праграма, а знешні маршрут вызначаецца там, дзе жыве сокет. Праверка толькі адной з іх дае ўпэўненую, але няправільную выснову. Праверка абедзвюх звычай завяршвае расследаванне за адзін праход.

Стварыце яго там, дзе патрэбны сокет

Рашэнне — стварыць прыладу ўнутры мэтавай прасторы імёнаў, а не ствараць яе звонку і пераносіць. Мяркуючы, што ўхваленая прастора імёнаў ужо існуе і імя не выкарыстоўваецца:

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

Цяпер і інтэрфейс, і яго сокет належаць гэтаму кантэксту, таму маршрут асновы і прымяняльныя правілы фільтра — тыя, што наладжаны там. Калі па праекце незашыфраваны бок патрэбны ў іншым месцы, спяршу змясціце базавы інтэрфейс у прастору імёнаў, а потым стварыце тунель. Парадак — частка праекта, а не дэталь рэалізацыі.

Стаўцеся да іх як да каманд адміністравання сеткі, а не як да рэцэпта. Яны ствараюць прыладу і паказваюць стан; ключы, партнёры, адрасы і маршруты ўсё яшчэ павінны паходзіць з ухваленай канфігурацыі, і існучы прамысловы інтэрфейс ніколі нельга падстаўляць у прыклад.

Чытайце абодва бакі шляху

Калі прылада на правільным месцы, праверце два рашэнні асобна. Пачніце з унутранага пошуку з кантэксту праграмы, затым праверце знешні шлях з кантэксту, якому належыць сокет:

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

Калі ўнутраны пошук вырашаецца праз тунель, а знешні захоп паказвае зашыфраваны абмен, абедзве паловы ўзгоднены. Калі захоп пусты, сокет усё яшчэ недзе ў іншым месцы, альбо маршрут асновы ў яго прасторы імёнаў не дасягае канчатковай кропкі.

Яшчэ адна праверка належыць у запіс: як прылада ствараецца пасля перазапуску. Менеджар, які перастварае інтэрфейс з іншым кантэкстам стварэння, змяняе месца нараджэння сокета. Ручны перанос, які аднойчы спрацаваў, не з'яўляецца доказам пра кіраваны шлях.