WireGuard v omrežnem imenskem prostoru: zakaj je vtičnica ostala zadaj

Vmesnik je naveden v imenskem prostoru, ki ste ga želeli, aplikacija je nanj vezana, in vendar se promet predora nikoli ne pojavi. To je značilnost naprave WireGuard v jedru Linuxa, ustvarjene v enem imenskem prostoru in premaknjene v drugega: vmesnik se je premaknil, njena šifrirana vtičnica UDP pa ne. Oba morata biti na pravem mestu, preden ima notranji promet pomen. Preverjanje je hitro, ko enkrat veste, da je treba gledati dva konteksta namesto enega.

Simptom: pravi imenski prostor, brez paketov

Znotraj imenskega prostora je predor videti zdrav. Naprava obstaja, naslovi so dodeljeni in konfiguracija partnerja je prisotna. Zunaj se pričakovana izmenjava UDP nikoli ne pojavi na vmesniku, ki ste ga opazovali, druga stran pa poroča, da rokovanja ni bilo.

Razlog je, da notranji paketi aplikacije dosežejo premaknjeno napravo, naprava pa jih poskuša poslati skozi vtičnico, ki pripada drugemu omrežnemu kontekstu. Osnovna pot, ki jo uporablja, in vsako pravilo požarnega zidu, ki zanj velja, so tista v imenskem prostoru, kjer je bila naprava ustvarjena.

To ni napaka pri premiku in ni napačna konfiguracija partnerja. Tako deluje izvedba jedra, dokumentacija o imenskih prostorih za WireGuard pa neposredno opisuje pravilo ustvarjanja.

Zakaj ima vtičnica kraj rojstva

Naprava WireGuard ima eno vtičnico UDP za svoj šifrirani prenos, in ta vtičnica se odpre v imenskem prostoru, kjer je naprava ustvarjena. Premik vmesnika z ukazom za povezavo premakne vidno napravo, a prenos pusti tam, kjer se je začel. Takrat imata dva predmeta različna lastnika.

Posledico je lahko spregledati, ker se obe polovici pregledujeta na različnih mestih. Notranja pot se odloča v imenskem prostoru, kjer teče aplikacija, zunanja pot pa se odloča tam, kjer živi vtičnica. Preverjanje samo ene da samozavesten, a napačen sklep. Preverjanje obeh običajno konča preiskavo v enem prehodu.

Ustvarite jo tam, kjer želite vtičnico

Rešitev je, da napravo ustvarite znotraj ciljnega imenskega prostora, namesto da bi jo ustvarili zunaj in premaknili. Ob predpostavki, da odobreni imenski prostor že obstaja in ime ni v uporabi:

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

Zdaj tako vmesnik kot njegova vtičnica pripadata temu kontekstu, zato so osnovna pot in veljavna pravila filtriranja tista, ki so nastavljena tam. Če zasnova potrebuje čisto stran drugje, najprej postavite osnovni vmesnik v imenski prostor in šele nato ustvarite predor. Vrstni red je del zasnove, ne podrobnost izvedbe.

Obravnavajte jih kot ukaze za upravljanje omrežja, ne kot recept. Ustvarijo napravo in prikažejo stanje; ključi, partnerji, naslovi in poti morajo še vedno priti iz odobrene konfiguracije, obstoječega proizvodnega vmesnika pa nikoli ne bi smeli nadomestiti v primeru.

Preberite obe strani poti

Ko je naprava na pravem mestu, preverite obe odločitvi ločeno. Začnite z notranjim iskanjem iz konteksta aplikacije, nato preverite zunanjo pot iz konteksta, ki ima v lasti vtičnico:

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

Če se notranje iskanje razreši skozi predor in zunanji posnetek pokaže šifrirano izmenjavo, se obe polovici ujemata. Če je posnetek prazen, je vtičnica še vedno kje drugje, ali pa osnovna pot v njenem imenskem prostoru ne doseže končne točke.

Še eno preverjanje spada v zapis: kako se naprava ustvari po ponovnem zagonu. Upravitelj, ki znova ustvari vmesnik z drugim kontekstom ustvarjanja, spremeni kraj rojstva vtičnice. Ročni premik, ki je enkrat uspel, ni dokaz o upravljani poti.