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

Ако внатрешното пребарување се решава низ тунелот и надворешниот запис го покажува шифрираниот размена, двете половини се совпаѓаат. Ако записот е празен, сокетот сў уште е некаде другаде, или основната рута во неговиот именски простор не стигнува до крајната точка.

Уште една проверка припаѓа во записот: како се создава уредот по рестарт. Менаџерот што го пресоздава интерфејсот со различен контекст на создавање го менува местото на раѓање на сокетот. Рачното преместување што еднаш успеало не е доказ за управуваната патека.