WireGuard in 'n netwerknaamruimte: waarom die sokkel agtergebly het

Die koppelvlak word in die naamruimte gelys wat jy wou hê, die toepassing is daaraan gebind, en daar verskyn nooit enige tonnelverkeer nie. Dit is die kenmerk van 'n Linux-kern-WireGuard-toestel wat in een naamruimte geskep en na 'n ander geskuif is: die koppelvlak het geskuif en sy geënkripteerde UDP-sokkel het nie. Albei moet op die regte plek woon voordat die binneste verkeer saak maak. Die kontrolering is vinnig sodra jy weet om na twee kontekste eerder as een te kyk.

Die simptoom: regte naamruimte, geen pakkette

Binne die naamruimte lyk die tonnel gesond. Die toestel bestaan, adresse is toegewys, en die eweknie-konfigurasie is teenwoordig. Buite verskyn die verwagte UDP-uitruiling nooit op die koppelvlak waarna jy gekyk het nie, en die ander kant rapporteer geen handdruk nie.

Die rede is dat die toepassing se binneste pakkette die geskuifde toestel bereik, en die toestel probeer hulle stuur deur 'n sokkel wat aan 'n ander netwerkkonteks behoort. Die onderliggende roete wat dit gebruik, en elke firewallreël wat daarop van toepassing is, is dié in die naamruimte waar die toestel geskep is.

Dit is nie 'n fout in die skuif nie, en dit is nie 'n verkeerde konfigurasie van die eweknie nie. Dit is wat die kernimplementering doen, en die naamruimtedokumentasie vir WireGuard beskryf die skeppingsreël direk.

Waarom die sokkel 'n geboorteplek het

'n WireGuard-toestel besit een UDP-sokkel vir sy geënkripteerde vervoer, en daardie sokkel word oopgemaak in die naamruimte waar die toestel geskep word. Om die koppelvlak met 'n skakelopdrag te skuif, verskuif die sigbare toestel terwyl die vervoer gelaat word waar dit begin het. Die twee voorwerpe het dan verskillende eienaars.

Die gevolg is maklik om mis te kyk omdat die helftes op verskillende plekke ondersoek word. Die binneste roete word bepaal in die naamruimte waar die toepassing loop, en die buitenste roete word bepaal waar die sokkel woon. Om net een van hulle na te gaan, lewer 'n selfversekerde, verkeerde gevolgtrekking. Om albei na te gaan, beëindig gewoonlik die ondersoek in een deurgang.

Skep dit waar jy die sokkel wil hê

Die oplossing is om die toestel binne die teikennaamruimte te skep eerder as om dit buite te skep en te skuif. Gestel 'n goedgekeurde naamruimte bestaan al en die naam is ongebruik:

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

Beide die koppelvlak en sy sokkel behoort nou aan daardie konteks, so die onderliggende roete en die toepaslike filterreëls is dié wat daar opgestel is. As die ontwerp die heldertekant elders nodig het, plaas die onderliggende koppelvlak eerste in die naamruimte en skep die tonnel daarna. Orde is deel van die ontwerp, nie 'n implementeringsbesonderheid nie.

Behandel hierdie as netwerkadministrasie-opdragte, nie as 'n resep nie. Hulle skep 'n toestel en wys toestand; sleutels, eweknieë, adresse en roetes moet steeds uit 'n goedgekeurde konfigurasie kom, en 'n bestaande produksiekoppelvlak moet nooit in 'n voorbeeld ingespan word nie.

Lees albei kante van die pad

Sodra die toestel op die regte plek is, verifieer die twee besluite afsonderlik. Begin met die binneste opsoek vanuit die toepassing se konteks, en gaan dan die buitenste pad na vanuit die konteks wat die sokkel besit:

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

As die binneste opsoek deur die tonnel oplos en die buitenste opvang die geënkripteerde uitruiling wys, stem albei helftes saam. As die opvang leeg is, is die sokkel steeds elders, of die onderliggende roete in sy naamruimte bereik nie die eindpunt nie.

Nog een kontrolering hoort in die rekord: hoe die toestel ná 'n herbegin geskep word. 'n Bestuurder wat die koppelvlak met 'n ander skeppingskonteks herskep, verander die sokkel se geboorteplek. 'n Handmatige skuif wat een keer gewerk het, is nie bewyse oor die bestuurde pad nie.