Linuxi võrgu nimeruumid VPN-i jaoks: mida need ei isoleeri

Käivitage VPN oma nimeruumi sees, käivitage seal üks rakendus, ja liiklus väljub ikkagi hosti marsruudi kaudu. Miski pole katki: nimeruum valitseb ainult protsesse, mis sinna sisenevad, ja leke tuli protsessist, mis ei teinud seda kunagi. Liidesed, aadressid, marsruudid, tulemüürireeglid ja socket’id on see, mida nimeruum omab. Failid, kontod ja juba töötavad teenused ei ole, ja siit tuleb enamik üllatusi.

Mida nimeruum omab ja kus socket sünnib

Liigutage liides nimeruumi ja host kaotab selle; ehitage sisse tunnel ja host ei näe seda. See on nimeruumiga piiratud VPN-i mehhanism: seade ja sellele osutavad marsruudid elavad kontekstis, kuhu pääsevad ainult valitud protsessid. Host hoiab oma vaikimisi marsruuti, nii et kõik väljaspool jääb puutumata.

WireGuardi jaoks loeb loomiskontekst sama palju kui praegune asukoht: UDP socket seotakse nimeruumis, kus liides loodi, isegi pärast seda, kui seade liigub mujale. Millist marsruutimistabelit krüpteeritud paketid järgivad, sõltub sellest sünnikohast. Kui socket jääb konteksti, kus pole marsruuti partnerini, otsib liides ja kätlus ei välju kunagi. Kontrollige selle sünnikohta, seejärel praegust asukohta.

Mida nimeruum ei isoleeri

Miski siin ei eralda failisüsteeme, kontosid ega saladusi, ja ükski neist piiridest ei teki sellepärast, et lõite nimeruumi. Resolveri konfiguratsioon on fail, nii et sees olev protsess saab ikka lugeda seadet, mis osutab hosti resolverile, ja saata oma päringu välja marsruudil, mida see eeldab. Rakendus, mis annab päringu üle juba töötavale vahendajale või süsteemiteenusele, kaasab protsessi täiesti teises kontekstis. Mõlemad on päringud, millele piir ei olnud kunagi mõeldud vastama.

Lahendus on nimeruumipõhine fail asukohas /etc/netns/<name>/resolv.conf või ettevalmistatud faili bind mount, mis on suunatud seestpoolt kättesaadavale resolverile. Hosti /etc/resolv.conf redigeerimine ei muuda midagi, mida nimeruum näeb.

Protsesside paigutus on juhtimine

Isoleeritus, mille saate, on täpselt nende protsesside isoleeritus, mille sees käivitate. Nimeruumi exec-abilise kaudu käivitatud shell ja kõik, mida see tekitab, jäävad sisse; hosti sessioonist käivitatud töölauarakendus mitte. Looge kontekst, liigutage seade ja tõestage siis mõlemad pooled:

ip netns add vpn1
ip link set wg0 netns vpn1
ip netns exec vpn1 wg show
wg show

Lugege esimest wg show nimeruumi seest ja teist hostist ning oodake, et ainult üks neist loetleb partneri. Kui mõlemad seda teevad, ei liikunud seade kunagi; kui kumbki ei tee, läks see mujale. Kui käivitaja on teenusehaldur, tuleb muuta unit-faili, mitte töölaua otsetee. Ilma nimeruumi seadeta unit käivitab deemonit hosti kontekstis ja tühistab disaini vaikselt.

Testige rakenduse kontekstist

Käivitage kontroll sama binaarfaili ja sama kasutajaga, mida rakendus kasutab, nimeruumi sees. Kaasake DNS ja mõlemad aadressiperekonnad, sest IPv6 marsruut, mille peale te ei mõelnud, on tavaline väljapääs. Teie enda shellist tehtud test tõestab ainult, et teie shell on isoleeritud.

Seejärel käivitage identne kontroll hostis ja kinnitage, et vastused erinevad: tunneliaadress ja kavatsetud väljapääs sees, hosti marsruut ja kontori väljapääs väljas, ja resolver nime järgi. Nimetage nimeruumid juurutuse, mitte protokolli järgi, et puhastusskript ei ajaks kahte segi.

Edastamine, tõrkepoliitika ja puhastamine

Lüüsi puhul lülitage edastamine teadlikult sisse ja otsustage, mis peaks juhtuma, kui tunnel katkeb. Nimeruum ei blokeeri marsruute, mille sellesse paigaldate, nii et hosti suunas varumaršruuti kasutatakse, kui selle loote. See on poliitikaotsus ja see tuleks kirja panna enne, kui katkestus seda testib.

Kirjutage üles nimeruumide nimed, liidesed ja see, kellele konfiguratsioon kuulub, et puhastamine eemaldaks ainult juurutuse loodu. Hosti võrgu lähtestamine tagasipööramise ajal muudab puhastamise katkestuseks. Leht network_namespaces(7) on lühike ja tasub lugeda enne, kui selle tee kavandate.