Docker un VM trafiks aiz OpenVPN: maršrutēt vai pārnumurēt?

Resursdators pārlūko pa tuneli, un blakus esošais konteiners neko nesasniedz. Publicēt portu no konteinera, kurā darbojas paša VPN klients, ir sliktāk: pieprasījums pienāk, un atbilde nekad neiziet. Abi ir maršrutēšanas lēmumi resursdatorā, un Docker ir tikai ziņnesis.

Trīs jautājumi nosaka, kuru no abiem gadījumiem jūs redzat, un tas aizņem apmēram minūti.

Divi bojājumi, kas izskatās vienādi

Pirmais ir atgriešanās ceļa problēma. Publicētais ports tiek pārtulkots konteinerā, pieprasījums pienāk, un atbilde tiek maršrutēta pa resursdatora noklusējuma maršrutu, kuru OpenVPN klients ir vērsis uz tun0. Atbilde iziet no adreses, ko attālais partneris negaida, un tā tiek izmesta. Otrais ir prefiksu sadursme: Docker noklusējuma tilts pārvalda 172.17.0.0/16, un uzņēmuma tunelis bīda to pašu diapazonu.

Vienu labo ar maršrutēšanas tabulu, otru ar tilta pārnumurēšanu. Rediģēt pirms tam, kad zināt, kurš ir kurš, ir veids, kā salauzt strādājošu konteineru.

Izlemiet ar trim jautājumiem

Pirmais jautājums: vai bojājums pazūd, kad apturat VPN? Ja ar izslēgtu tuneli viss darbojas, turiet aizdomās atgriešanās ceļu. Otrais jautājums: vai ip route show table all uzskaita to pašu prefiksu divreiz, vienreiz uz tilta un vienreiz uz tun0? Tā ir sadursme. Trešais jautājums: vai skartā adrese ir konteiners, NAT viesis vai tiltā pievienots viesis?

Trešais jautājums ir svarīgs, jo katram ir cits pareizais labojums, un konteinera labojuma piemērošana libvirt viesim iznieko vienu vakaru.

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

Atgriešanās ceļš: tabula vienai avota adresei

Kad konteinera trafikam jāiziet pa fizisko saskarni, kamēr pats resursdators izmanto tuneli, maršrutēšana pēc avota ir mazākā izmaiņa. Pievienojiet noteikumu, kas atbilst konteinera adresei, un nosūtiet to uz atsevišķu tabulu. Nekas cits resursdatorā nekustas.

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

Katrs pakets, kura avots ir šī adrese, vispirms skatās tabulā 10, un tabula 10 nosūta to uz tilta vārteju, nevis tunelī.

Pārbaudiet ar ip route get 1.1.1.1 from 172.22.0.3. Atbildē jānorāda tilta saskarne, nevis tun0. Šādi pievienoti noteikumi pazūd pēc pārstartēšanas, tāpēc ievietojiet tos unit vai tīkla āķī, kuram pieder konteiners.

Tas pats modelis darbojas WireGuard konteineram, kur arī atbildes ceļam vajag skaidru noteikumu.

Prefiksu sadursme: pārnumurējiet tiltu

Maršrutēšanas tabula nosūta vienu prefiksu uz vienu vietu. Ja VPN bīda 172.17.0.0/16, kamēr Docker tilts jau ir tur, uzvar zemākā metrika: Docker instalē savu savienoto maršrutu ar metriku 0, un iespiestais maršruts pienāk ar 50. Tad tunelis izskatās salauzts, kamēr Docker turpina strādāt, vai otrādi, atkarībā no instalēšanas secības. Pārnumurējiet tiltu, nevis cīnieties ar metriku.

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

Pēc izmaiņas pārstartējiet Docker un no jauna izveidojiet tīklus, kas būvēti ar veco kopu. Metrikas maiņa tikai pārvieto konfliktu uz nākamo palaišanu.

VM atkal vajag citu atbildi

libvirt viesis noklusējuma NAT tīklā manto resursdatora maršrutēšanu un pārstāj sasniegt ārpasauli, tiklīdz resursdatora tunelis pārņem noklusējuma maršrutu. Viesa pārvietošana uz tiltu vai macvtap ierīci dod tam savu ceļu fiziskajā tīklā. virt-manager pievienojiet aparatūru, izvēlieties Network, iestatiet avotu uz macvtap resursdatora ierīci, saglabājiet virtio kā modeli un pēc tam deaktivizējiet veco NAT saskarni.

macvtap viesis parasti nevar sasniegt savu resursdatoru. Tā ir gaidāma uzvedība, nevis bojājums, un tai jābūt piezīmē, ko atstājat.

Viesim, kuram vajag tikai resursdatora LAN, piegādātāja klientā var būt trūkstošais slēdzis: ar Mullvad mullvad lan set allow atjauno vietējo sasniedzamību, neaizskarot libvirt. Un, ja konteineram jābūt sasniedzamam tikai pa tuneli, piesaistiet publicēto portu tuneļa adresei, -p 10.8.0.5:8080:8080, tā vietā, lai publicētu to katrā adresē.