Docker ir VM srautas už OpenVPN: maršrutizuoti ar pernumeruoti?

OpenVPN klientą turinčiame pagrindiniame kompiuteryje konteineriai ir svečiai arba praranda grįžimo kelią, arba susiduria su tunelio priešdėliu. Sprendimą išrenka trys klausimai.

Pagrindinis kompiuteris naršo per tunelį, o šalia esantis konteineris nieko nepasiekia. Skelbti portą iš konteinerio, kuriame veikia jo paties VPN klientas, yra blogiau: užklausa ateina, o atsakymas niekada neišeina. Abu yra maršrutizavimo sprendimai pagrindiniame kompiuteryje, o Docker tėra pasiuntinys.

Trys klausimai nusprendžia, kurį iš dviejų atvejų matote, ir tai trunka apie minutę.

Du gedimai, kurie atrodo vienodai

Pirmasis – grįžimo kelio problema. Paskelbtas portas išverčiamas į konteinerį, užklausa ateina, o atsakymas maršrutizuojamas pagrindinio kompiuterio numatytuoju maršrutu, kurį OpenVPN klientas nukreipė į tun0. Atsakymas išeina iš adreso, kurio tolimasis partneris nesitiki, ir yra numetamas. Antrasis – priešdėlių susidūrimas: numatytasis Docker tiltas valdo 172.17.0.0/16, o įmonės tunelis stumia tą patį diapazoną.

Vienas taisomas maršrutų lentele, kitas – pernumeruojant tiltą. Redaguoti prieš žinant, kuris yra kuris, – tai būdas sugadinti veikiantį konteinerį.

Nuspręskite trimis klausimais

Pirmas klausimas: ar gedimas išnyksta sustabdžius VPN? Jei su išjungtu tuneliu viskas veikia, įtarkite grįžimo kelią. Antras klausimas: ar ip route show table all išvardija tą patį priešdėlį du kartus, kartą ant tilto ir kartą ant tun0? Tai ir yra susidūrimas. Trečias klausimas: ar paveiktas adresas yra konteineris, NAT svečias ar tiltu prijungtas svečias?

Trečias klausimas svarbus todėl, kad kiekvienam tinka kitoks teisingas sprendimas, o konteinerio sprendimo taikymas libvirt svečiui praranda visą vakarą.

ip route
ip route show table all | grep -E '172\.1[7-9]|10\.8'
docker network inspect bridge --format '{{.IPAM.Config}}'

Grįžimo kelias: lentelė vienam šaltinio adresui

Kai konteinerio srautas turi išeiti per fizinę sąsają, o pats pagrindinis kompiuteris naudoja tunelį, maršrutizavimas pagal šaltinį yra mažiausias pakeitimas. Pridėkite taisyklę, atitinkančią konteinerio adresą, ir nukreipkite ją į atskirą lentelę. Nieko daugiau pagrindiniame kompiuteryje nejuda.

ip rule add from 172.22.0.3 lookup 10
ip route add default via 172.22.0.1 table 10

Kiekvienas paketas, kurio šaltinis yra tas adresas, pirmiausia tikrina lentelę 10, o lentelė 10 siunčia jį į tilto šliuzą, o ne į tunelį.

Patikrinkite su ip route get 1.1.1.1 from 172.22.0.3. Atsakyme turi būti nurodyta tilto sąsaja, o ne tun0. Taip pridėtos taisyklės dingsta perkraunant, todėl įrašykite jas į unit ar tinklo kabliuką, kuriam priklauso konteineris.

Ta pati schema tinka WireGuard konteineriui, kur grįžimo keliui taip pat reikia aiškios taisyklės.

Priešdėlių susidūrimas: pernumeruokite tiltą

Maršrutų lentelė siunčia vieną priešdėlį į vieną vietą. Jei VPN stumia 172.17.0.0/16, o Docker tiltas jau ten, laimi mažesnė metrika: Docker įdiegia savo sujungtą maršrutą su metrika 0, o įstumtas maršrutas ateina su 50. Tada tunelis atrodo sugedęs, kol Docker toliau veikia, arba atvirkščiai, priklausomai nuo diegimo tvarkos. Pernumeruokite tiltą, o ne kovokite su metrika.

{
  "bip": "10.200.0.1/24",
  "default-address-pools": [{"base": "10.201.0.0/16", "size": 24}]
}

Po pakeitimo paleiskite Docker iš naujo ir iš naujo sukurkite tinklus, sukurtus su senuoju telkiniu. Metrikos keitimas tik perkelia konfliktą į kitą paleidimą.

VM reikia dar kito atsakymo

libvirt svečias numatytajame NAT tinkle paveldi pagrindinio kompiuterio maršrutizavimą ir nustoja pasiekti išorę, kai pagrindinio kompiuterio tunelis užima numatytąjį maršrutą. Svečio perkėlimas į tiltą ar macvtap įrenginį suteikia jam savo kelią fiziniame tinkle. virt-manager programoje pridėkite aparatinę įrangą, pasirinkite Network, nustatykite šaltinį į macvtap pagrindinio kompiuterio įrenginį, palikite virtio kaip modelį, tada išjunkite seną NAT sąsają.

macvtap svečias paprastai negali pasiekti savo pagrindinio kompiuterio. Tai laukiamas elgesys, o ne gedimas, ir tai priklauso pastabai, kurią paliekate.

Svečiui, kuriam reikia tik pagrindinio kompiuterio LAN, tiekėjo kliente gali būti trūkstamas jungiklis: su Mullvad mullvad lan set allow atkuria vietinį pasiekiamumą neliesdamas libvirt. O kai konteineris turi būti pasiekiamas tik per tunelį, pririškite paskelbtą portą prie tunelio adreso, -p 10.8.0.5:8080:8080, o ne skelbkite jį visais adresais.

Susiję straipsniai