WireGuard у мрежном именском простору: зашто је сокет остао иза

Премештање интерфејса не премешта шифровани UDP сокет, који остаје у именском простору у коме је уређај направљен. Направите га у циљном простору.

Интерфејс је наведен у именском простору који сте желели, апликација је везана за њега, а саобраћај тунела се ипак никада не појави. То је знак 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

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

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

Повезани чланци