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

Ако вътрешното търсене се разрешава през тунела и външният запис показва криптирания обмен, двете половини съвпадат. Ако записът е празен, сокетът все още е някъде другаде или основният маршрут в неговото пространство от имена не стига до крайната точка.

Още една проверка принадлежи в записа: как устройството се създава след рестарт. Мениджър, който пресъздава интерфейса с различен контекст на създаване, променя мястото на раждане на сокета. Ръчно преместване, което е проработило веднъж, не е доказателство за управлявания път.