WireGuard i eit nettverksnamnerom: kvifor sockelen vart ståande att

Grensesnittet er ført opp i namnerommet du ønskte, applikasjonen er bunden til det, og likevel dukkar det aldri opp tunneltrafikk. Dette er signaturen til ei WireGuard-eining i Linux-kjernen som vart oppretta i eitt namnerom og flytta til eit anna: grensesnittet flytta, men den krypterte UDP-sockelen gjorde det ikkje. Begge må vere på rett stad før den indre trafikken betyr noko. Kontrollen er rask når du først veit at du må sjå på to kontekstar i staden for éin.

Symptomet: rett namnerom, ingen pakkar

Inne i namnerommet ser tunnelen sunn ut. Eininga finst, adresser er tildelte, og peer-konfigurasjonen er på plass. Utanfor dukkar den venta UDP-utvekslinga aldri opp på grensesnittet du overvaka, og den andre sida melder at det ikkje var noko handtrykk.

Årsaka er at dei indre pakkane til applikasjonen når den flytta eininga, og eininga prøver å sende dei gjennom ein sockel som høyrer til ein annan nettverkskontekst. Den underliggjande ruta ho brukar, og kvar brannmurregel som gjeld for henne, er dei i namnerommet der eininga vart oppretta.

Det er ikkje ein feil i flyttinga, og det er ikkje ein feilkonfigurasjon av peeren. Slik gjer kjerneimplementasjonen det, og namneromsdokumentasjonen for WireGuard skildrar opprettingsregelen direkte.

Kvifor sockelen har ein fødestad

Ei WireGuard-eining eig éin UDP-sockel for den krypterte transporten sin, og den sockelen blir opna i namnerommet der eininga blir oppretta. Å flytte grensesnittet med ein linkkommando flyttar den synlege eininga, men lèt transporten bli der han starta. Då har dei to objekta ulike eigarar.

Konsekvensen er lett å oversjå fordi dei to halvdelane blir undersøkte på ulike stader. Den indre ruta blir avgjord i namnerommet der applikasjonen køyrer, og den ytre ruta blir avgjord der sockelen bur. Å kontrollere berre éin av dei gir ein sjølvsikker, men feil konklusjon. Å kontrollere begge avsluttar vanlegvis undersøkinga i éin gjennomgang.

Opprett han der du vil ha sockelen

Løysinga er å opprette eininga inne i mål-namnerommet i staden for å opprette henne utanfor og flytte henne. Føresett at eit godkjent namnerom alt finst og at namnet er ubrukt:

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

No høyrer både grensesnittet og sockelen hans til denne konteksten, så den underliggjande ruta og dei gjeldande filterreglane er dei som er konfigurerte der. Viss designet treng den klare sida ein annan stad, legg det underliggjande grensesnittet i namnerommet først og opprett tunnelen etterpå. Rekkjefølgja er ein del av designet, ikkje ein implementasjonsdetalj.

Behandle dei som kommandoar for nettverksadministrasjon, ikkje som ein oppskrift. Dei opprettar ei eining og viser tilstand; nøklar, peers, adresser og ruter må framleis kome frå ein godkjend konfigurasjon, og eit eksisterande produksjonsgrensesnitt bør aldri setjast inn i eit døme.

Les begge sider av vegen

Når eininga er på rett stad, verifiser dei to avgjerdene kvar for seg. Start med det indre oppslaget frå konteksten til applikasjonen, og kontroller deretter den ytre vegen frå konteksten som eig sockelen:

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

Viss det indre oppslaget blir løyst gjennom tunnelen og den ytre opptaka viser den krypterte utvekslinga, er dei to halvdelane samde. Viss opptaka er tom, er sockelen framleis ein annan stad, eller den underliggjande ruta i namnerommet hans når ikkje endepunktet.

Endå ein kontroll høyrer med i posten: korleis eininga blir oppretta etter ein omstart. Ein leiar som gjenopprettar grensesnittet med ein annan opprettingskontekst, endrar fødestaden til sockelen. Ei manuell flytting som verka éin gong, er ikkje prov for den administrerte vegen.