WireGuard v síťovém jmenném prostoru: proč socket zůstal pozadu

Rozhraní je uvedeno ve jmenném prostoru, který jste chtěli, aplikace je na něj navázaná, a přesto se nikdy neobjeví žádný provoz tunelu. To je typický znak zařízení WireGuard v jádru Linuxu, které bylo vytvořeno v jednom jmenném prostoru a přemístěno do jiného: rozhraní se přesunulo, ale jeho šifrovaný socket UDP ne. Obě části musí být na správném místě, než vnitřní provoz začne mít význam. Kontrola je rychlá, jakmile víte, že se máte dívat na dva kontexty místo jednoho.

Příznak: správný jmenný prostor, žádné pakety

Uvnitř jmenného prostoru vypadá tunel zdravě. Zařízení existuje, adresy jsou přiřazené a konfigurace protějšku je přítomná. Zvenku se očekávaná výměna UDP nikdy neobjeví na rozhraní, které jste sledovali, a protistrana hlásí, že nedošlo k handshake.

Důvod je ten, že vnitřní pakety aplikace dorazí k přesunutému zařízení a zařízení se je snaží odeslat socketem, který patří jinému síťovému kontextu. Podkladová trasa, kterou používá, i každé pravidlo firewallu, které se na něj vztahuje, jsou ta ve jmenném prostoru, kde bylo zařízení vytvořeno.

To není chyba v přesunu a není to špatná konfigurace protějšku. Takto implementace jádra funguje a dokumentace jmenných prostorů pro WireGuard pravidlo vytvoření popisuje přímo.

Proč má socket místo narození

Zařízení WireGuard vlastní jeden socket UDP pro svůj šifrovaný přenos a tento socket se otevírá ve jmenném prostoru, kde je zařízení vytvořeno. Přesun rozhraní příkazem pro spojení přemístí viditelné zařízení, ale přenos zůstane tam, kde začal. Oba objekty pak mají různé vlastníky.

Důsledek lze snadno přehlédnout, protože se obě poloviny kontrolují na různých místech. Vnitřní trasa se rozhoduje ve jmenném prostoru, kde běží aplikace, a vnější trasa se rozhoduje tam, kde žije socket. Kontrola jen jedné z nich dává sebevědomý, ale špatný závěr. Kontrola obou obvykle vyšetřování ukončí na jeden průchod.

Vytvořte ho tam, kde chcete socket

Řešením je vytvořit zařízení uvnitř cílového jmenného prostoru, místo aby se vytvořilo venku a přesunulo. Za předpokladu, že schválený jmenný prostor už existuje a jméno je nepoužité:

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

Nyní rozhraní i jeho socket patří tomuto kontextu, takže podkladová trasa a platná pravidla filtrování jsou ta, která jsou tam nastavena. Pokud návrh potřebuje čistou stranu jinde, umístěte nejprve podkladové rozhraní do jmenného prostoru a teprve potom vytvořte tunel. Pořadí je součástí návrhu, ne detailem implementace.

Berte je jako příkazy správy sítě, ne jako recept. Vytvářejí zařízení a zobrazují stav; klíče, protějšky, adresy a trasy stále musí pocházet ze schválené konfigurace a existující produkční rozhraní by se nikdy nemělo dosazovat do příkladu.

Čtěte obě strany cesty

Když je zařízení na správném místě, ověřte obě rozhodnutí odděleně. Začněte vnitřním vyhledáním z kontextu aplikace a potom zkontrolujte vnější cestu z kontextu, který vlastní socket:

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

Pokud se vnitřní vyhledání vyřeší přes tunel a vnější zachycení ukáže šifrovanou výměnu, obě poloviny souhlasí. Pokud je zachycení prázdné, socket je stále někde jinde, nebo se podkladová trasa v jeho jmenném prostoru nedostane ke koncovému bodu.

Do záznamu patří ještě jedna kontrola: jak se zařízení vytváří po restartu. Správce, který rozhraní znovu vytvoří v jiném kontextu vytvoření, mění místo narození socketu. Ruční přesun, který jednou fungoval, není důkazem o spravované cestě.