WireGuard v sieťovom mennom priestore: prečo socket zostal vzadu

Rozhranie je uvedené v mennom priestore, ktorý ste chceli, aplikácia je naň naviazaná, a napriek tomu sa nikdy neobjaví prevádzka tunela. To je znak zariadenia WireGuard v jadre Linuxu, ktoré bolo vytvorené v jednom mennom priestore a presunuté do iného: rozhranie sa presunulo a jeho šifrovaný socket UDP nie. Obe musia byť na správnom mieste, kým vnútorná prevádzka začne mať význam. Kontrola je rýchla, keď už viete, že sa treba pozerať na dva kontexty namiesto jedného.

Príznak: správny menný priestor, žiadne pakety

Vnútri menného priestoru vyzerá tunel zdravo. Zariadenie existuje, adresy sú pridelené a konfigurácia partnera je prítomná. Zvonku sa očakávaná výmena UDP nikdy neobjaví na rozhraní, ktoré ste sledovali, a druhá strana hlási, že nedošlo k potraseniu rúk.

Príčinou je, že vnútorné pakety aplikácie sa dostanú k presunutému zariadeniu a zariadenie ich skúša odoslať cez socket, ktorý patrí inému sieťovému kontextu. Podkladová trasa, ktorú používa, aj každé pravidlo firewallu, ktoré sa naň vzťahuje, sú tie v mennom priestore, kde bolo zariadenie vytvorené.

Nie je to chyba v presune ani nesprávna konfigurácia partnera. Takto funguje implementácia jadra a dokumentácia menných priestorov pre WireGuard priamo opisuje pravidlo vytvorenia.

Prečo má socket miesto narodenia

Zariadenie WireGuard vlastní jeden socket UDP pre svoj šifrovaný prenos a tento socket sa otvára v mennom priestore, kde sa zariadenie vytvára. Presun rozhrania príkazom pre spojenie premiestni viditeľné zariadenie, ale prenos nechá tam, kde sa začal. Potom majú dva objekty rôznych vlastníkov.

Dôsledok sa dá ľahko prehliadnuť, pretože obe polovice sa kontrolujú na rôznych miestach. Vnútorná trasa sa rozhoduje v mennom priestore, kde beží aplikácia, a vonkajšia trasa sa rozhoduje tam, kde žije socket. Kontrola len jednej z nich dáva sebavedomý, ale nesprávny záver. Kontrola oboch zvyčajne ukončí vyšetrovanie na jeden prechod.

Vytvorte ho tam, kde chcete socket

Riešením je vytvoriť zariadenie vnútri cieľového menného priestoru namiesto jeho vytvorenia zvonku a presunu. Za predpokladu, že schválený menný priestor už existuje a meno je nepoužité:

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

Teraz rozhranie aj jeho socket patria tomuto kontextu, takže podkladová trasa a platné pravidlá filtrovania sú tie, ktoré sú tam nastavené. Ak návrh potrebuje čistú stranu inde, umiestnite najprv podkladové rozhranie do menného priestoru a až potom vytvorte tunel. Poradie je súčasťou návrhu, nie detailom implementácie.

Berte ich ako príkazy správy siete, nie ako recept. Vytvárajú zariadenie a zobrazujú stav; kľúče, partneri, adresy a trasy stále musia pochádzať zo schválenej konfigurácie a existujúce produkčné rozhranie by sa nikdy nemalo dosadzovať do príkladu.

Čítajte obe strany cesty

Keď je zariadenie na správnom mieste, overte obe rozhodnutia oddelene. Začnite vnútorným vyhľadaním z kontextu aplikácie a potom skontrolujte vonkajšiu cestu z kontextu, ktorý 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

Ak sa vnútorné vyhľadanie vyrieši cez tunel a vonkajšie zachytenie ukáže šifrovanú výmenu, obe polovice súhlasia. Ak je zachytenie prázdne, socket je stále niekde inde, alebo sa podkladová trasa v jeho mennom priestore nedostane ku koncovému bodu.

Do záznamu patrí ešte jedna kontrola: ako sa zariadenie vytvára po reštarte. Správca, ktorý znovu vytvorí rozhranie v inom kontexte vytvorenia, mení miesto narodenia socketu. Ručný presun, ktorý raz fungoval, nie je dôkazom o spravovanej ceste.