WireGuard i et netværksnavnerum: hvorfor socketten blev ladt tilbage

Grænsefladen er opført i det navnerum, du ønskede, applikationen er bundet til den, og der vises aldrig nogen tunneltrafik. Det er kendetegnet for en WireGuard-enhed i Linux-kernen, der blev oprettet i ét navnerum og flyttet til et andet: grænsefladen flyttede, og dens krypterede UDP-socket gjorde ikke. Begge skal være det rigtige sted, før den indre trafik betyder noget. Kontrollen er hurtig, når du først ved, at du skal se på to kontekster i stedet for én.

Symptomet: det rigtige navnerum, ingen pakker

Inde i navnerummet ser tunnelen sund ud. Enheden findes, adresser er tildelt, og peer-konfigurationen er til stede. Udenfor dukker den forventede UDP-udveksling aldrig op på den grænseflade, du overvågede, og den anden side rapporterer, at der ikke er noget håndtryk.

Årsagen er, at applikationens indre pakker når den flyttede enhed, og enheden forsøger at sende dem gennem en socket, der tilhører en anden netværkskontekst. Den underliggende rute, den bruger, og hver firewallregel, der gælder for den, er dem i det navnerum, hvor enheden blev oprettet.

Det er ikke en fejl i flytningen, og det er ikke en forkert konfiguration af peeren. Det er, hvad kernelimplementeringen gør, og navnerumsdokumentationen for WireGuard beskriver oprettelsesreglen direkte.

Hvorfor socketten har et fødested

En WireGuard-enhed ejer én UDP-socket til sin krypterede transport, og den socket åbnes i det navnerum, hvor enheden oprettes. At flytte grænsefladen med en linkkommando flytter den synlige enhed, men lader transporten blive, hvor den startede. Derefter har de to objekter forskellige ejere.

Konsekvensen er let at overse, fordi de to halvdele undersøges forskellige steder. Den indre rute afgøres i det navnerum, hvor applikationen kører, og den ydre rute afgøres, hvor socketten bor. At kontrollere kun én af dem giver en selvsikker, men forkert konklusion. At kontrollere begge afslutter normalt undersøgelsen i ét gennemløb.

Opret den, hvor du vil have socketten

Løsningen er at oprette enheden inde i målnavnerummet i stedet for at oprette den udenfor og flytte den. Forudsat at et godkendt navnerum allerede findes, og at navnet er ubrugt:

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

Nu tilhører både grænsefladen og dens socket denne kontekst, så den underliggende rute og de gældende filterregler er dem, der er konfigureret der. Hvis designet har brug for den klare side et andet sted, skal du først placere den underliggende grænseflade i navnerummet og derefter oprette tunnelen. Rækkefølgen er en del af designet, ikke en implementeringsdetalje.

Behandl dem som kommandoer til netværksadministration, ikke som en opskrift. De opretter en enhed og viser tilstand; nøgler, peers, adresser og ruter skal stadig komme fra en godkendt konfiguration, og en eksisterende produktionsgrænseflade bør aldrig sættes ind i et eksempel.

Læs begge sider af vejen

Når enheden er det rigtige sted, skal du verificere de to beslutninger hver for sig. Start med det indre opslag fra applikationens kontekst, og kontroller derefter den ydre vej fra den kontekst, der ejer socketten:

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

Hvis det indre opslag løses gennem tunnelen, og den ydre optagelse viser den krypterede udveksling, er de to halvdele enige. Hvis optagelsen er tom, er socketten stadig et andet sted, eller den underliggende rute i dens navnerum når ikke endepunktet.

Endnu en kontrol hører med i posten: hvordan enheden oprettes efter en genstart. En manager, der genskaber grænsefladen med en anden oprettelseskontekst, ændrer socketens fødested. En manuel flytning, der virkede én gang, er ikke bevis for den administrerede vej.