Docker- kaj VM-trafiko malantaŭ OpenVPN: enkursigi aŭ renumeri?

Ujoj kaj gastoj sur gastiganto kun OpenVPN-kliento aŭ perdas la returnan vojon aŭ kolizias kun la tunela prefikso. Tri demandoj elektas la solvon.

La gastiganto retumas tra la tunelo, kaj la ujo apud ĝi atingas nenion. Publikigi pordon el ujo, kiu mem rulas sian VPN-klienton, estas pli malbone: la peto alvenas kaj la respondo neniam eliras. Ambaŭ estas enkursigaj decidoj sur la gastiganto, kaj Docker estas nur la mesaĝisto.

Tri demandoj decidas, kiun el la du kazojn vi rigardas, kaj ili daŭras proksimume minuton.

Du difektoj, kiuj aspektas same

La unua estas problemo de la returna vojo. Publikigita pordo tradukiĝas en la ujon, la peto alvenas, kaj la respondo enkursiĝas per la defaŭlta vojo de la gastiganto, kiun la OpenVPN kliento direktis al tun0. La respondo eliras el adreso, kiun la fora kunulo ne atendas, kaj ĝi estas forĵetata. La dua estas prefiksa kolizio: la defaŭlta ponto de Docker posedas 172.17.0.0/16, kaj entreprena tunelo puŝas la saman gamon.

Unu ripariĝas per enkursiga tabelo, la alia per renumerado de ponto. Redakti antaŭ ol vi scias, kiu estas kiu, estas la maniero rompi funkciantan ujon.

Decidu per tri demandoj

Unua demando: ĉu la difekto malaperas, kiam vi haltigas la VPN-on? Se ĉio funkcias kun la tunelo malsupre, suspektu la returnan vojon. Dua demando: ĉu ip route show table all listigas la saman prefikson dufoje, unufoje sur ponto kaj unufoje sur tun0? Tio estas la kolizio. Tria demando: ĉu la trafita adreso estas ujo, NAT-gasto aŭ pontigita gasto?

La tria demando gravas, ĉar ĉiu havas malsaman ĝustan riparon, kaj apliki la ujan riparon al libvirt-gasto malŝparas vesperon.

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

Returna vojo: tabelo por unu fonta adreso

Kiam la trafiko de la ujo devas eliri tra la fizika interfaco dum la gastiganto mem uzas la tunelon, fontbazita enkursigado estas la plej malgranda ŝanĝo. Aldonu regulon kongruan kun la adreso de la ujo kaj sendu ĝin al dediĉita tabelo. Nenio alia sur la gastiganto moviĝas.

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

Ĉiu pako, kies fonto estas tiu adreso, unue konsultas tabelon 10, kaj tabelo 10 sendas ĝin al la pordego de la ponto anstataŭ al la tunelo.

Konfirmu per ip route get 1.1.1.1 from 172.22.0.3. La respondo devas nomi la interfacon de la ponto, ne tun0. Reguloj aldonitaj tiel malaperas ĉe restarto, do metu ilin en la unuon aŭ retan hokon, kiu posedas la ujon.

La sama ŝablono funkcias por WireGuard-ujo, kie ankaŭ la responda vojo bezonas eksplicitan regulon.

Prefiksa kolizio: renumeru la ponton

Enkursiga tabelo sendas unu prefikson al unu loko. Se la VPN puŝas 172.17.0.0/16 dum la ponto de Docker jam estas tie, venkas la pli malalta metriko: Docker instalas sian konektitan vojon kun metriko 0, kaj la puŝita vojo alvenas kun 50. Tiam la tunelo aspektas rompita dum Docker daŭre funkcias, aŭ la malo, laŭ la instalordo. Renumeru la ponton anstataŭ lukti kontraŭ la metriko.

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

Restartu Docker post la ŝanĝo kaj rekrei retojn konstruitajn per la malnova baseno. Ŝanĝi la metrikon anstataŭe nur translokas la konflikton al la sekva lanĉo.

VM-oj bezonas denove alian respondon

libvirt-gasto sur la defaŭlta NAT-reto heredas la enkursigadon de la gastiganto kaj ĉesas atingi la eksteron, kiam la tunelo de la gastiganto posedas la defaŭltan vojon. Ŝanĝi la gaston al pontigita aŭ macvtap-aparato donas al ĝi sian propran vojon sur la fizika reto. En virt-manager aldonu aparataron, elektu Network, agordu la fonton al la macvtap-gastiga aparato, konservu virtio kiel modelo, poste malaktivigu la malnovan NAT-interfacon.

macvtap-gasto kutime ne povas atingi sian propran gastiganton. Tio estas atendata konduto, ne difekto, kaj ĝi apartenas al la noto, kiun vi lasas.

Por gasto, kiu bezonas nur la lokan reton de la gastiganto, la kliento de la provizanto eble havas la mankantan ŝaltilon: kun Mullvad, mullvad lan set allow restarigas lokan atingeblon sen tuŝi libvirt. Kaj kiam ujo devas esti atingebla nur tra la tunelo, ligi la publikigitan pordon al la tunela adreso, -p 10.8.0.5:8080:8080, anstataŭ publikigi ĝin sur ĉiu adreso.

Rilataj artikoloj