WireGuard i et nettverksnavnerom: hvorfor sokkelen ble stående igjen

Grensesnittet er ført opp i navnerommet du ønsket, applikasjonen er bundet til det, og likevel dukker det aldri opp tunneltrafikk. Dette er signaturen til en WireGuard-enhet i Linux-kjernen som ble opprettet i ett navnerom og flyttet til et annet: grensesnittet flyttet, men den krypterte UDP-sokkelen gjorde det ikke. Begge må være på riktig sted før den indre trafikken betyr noe. Kontrollen er rask når du først vet at du må se på to kontekster i stedet for én.

Symptomet: riktig navnerom, ingen pakker

Inne i navnerommet ser tunnelen sunn ut. Enheten finnes, adresser er tildelt, og peer-oppsettet er på plass. Utenfor dukker den forventede UDP-utvekslingen aldri opp på grensesnittet du overvåket, og den andre siden rapporterer at det ikke var noen håndtrykk.

Årsaken er at applikasjonens indre pakker når den flyttede enheten, og enheten prøver å sende dem gjennom en sokkel som tilhører en annen nettverkskontekst. Den underliggende ruten den bruker, og hver brannmurregel som gjelder for den, er de i navnerommet der enheten ble opprettet.

Det er ikke en feil i flyttingen, og det er ikke en feilkonfigurasjon av peeren. Det er slik kjerneimplementasjonen gjør det, og navneromsdokumentasjonen for WireGuard beskriver opprettelsesregelen direkte.

Hvorfor sokkelen har et fødested

En WireGuard-enhet eier én UDP-sokkel for sin krypterte transport, og den sokkelen åpnes i navnerommet der enheten opprettes. Å flytte grensesnittet med en linkkommando flytter den synlige enheten, men lar transporten bli der den startet. Da har de to objektene forskjellige eiere.

Konsekvensen er lett å overse fordi de to halvdelene undersøkes på forskjellige steder. Den indre ruten avgjøres i navnerommet der applikasjonen kjører, og den ytre ruten avgjøres der sokkelen bor. Å kontrollere bare én av dem gir en selvsikker, men feil konklusjon. Å kontrollere begge avslutter vanligvis undersøkelsen i én gjennomgang.

Opprett den der du vil ha sokkelen

Løsningen er å opprette enheten inne i mål-navnerommet i stedet for å opprette den utenfor og flytte den. Forutsatt at et godkjent navnerom allerede finnes og at navnet er ubrukt:

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

Nå tilhører både grensesnittet og sokkelen denne konteksten, så den underliggende ruten og de gjeldende filterreglene er de som er konfigurert der. Hvis designet trenger den klare siden et annet sted, legg det underliggende grensesnittet i navnerommet først og opprett tunnelen etterpå. Rekkefølgen er en del av designet, ikke en implementasjonsdetalj.

Behandle dem som kommandoer for nettverksadministrasjon, ikke som en oppskrift. De oppretter en enhet og viser tilstand; nøkler, peers, adresser og ruter må fortsatt komme fra en godkjent konfigurasjon, og et eksisterende produksjonsgrensesnitt bør aldri settes inn i et eksempel.

Les begge sider av veien

Når enheten er på riktig sted, verifiser de to beslutningene hver for seg. Start med det indre oppslaget fra applikasjonens kontekst, og kontroller deretter den ytre veien fra konteksten som eier sokkelen:

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 oppslaget løses gjennom tunnelen og den ytre opptaket viser den krypterte utvekslingen, er de to halvdelene enige. Hvis opptaket er tomt, er sokkelen fortsatt et annet sted, eller den underliggende ruten i navnerommet når ikke endepunktet.

Nok en kontroll hører med i posten: hvordan enheten opprettes etter en omstart. En leder som gjenoppretter grensesnittet med en annen opprettelseskontekst, endrer sokkelens fødested. En manuell flytting som virket én gang, er ikke bevis for den administrerte veien.