Dockerin ja VM:ien liikenne OpenVPN:n takana: reitittää vai numeroida uudelleen?

Isäntä selaa tunnelin kautta, eikä vieressä oleva kontti tavoita mitään. Portin julkaiseminen kontista, joka ajaa omaa VPN-asiakastaan, on pahempaa: pyyntö saapuu eikä vastaus koskaan lähde. Molemmat ovat reitityspäätöksiä isännällä, ja Docker on vain sanansaattaja.

Kolme kysymystä ratkaisee, kumpi tapaus sinulla on edessä, ja ne vievät noin minuutin.

Kaksi vikaa, jotka näyttävät samalta

Ensimmäinen on paluupolun ongelma. Julkaistu portti käännetään konttiin, pyyntö saapuu ja vastaus reititetään isännän oletusreitin kautta, jonka OpenVPN -asiakas on osoittanut tun0:lle. Vastaus lähtee osoitteesta, jota etäinen vastapuoli ei odota, ja se pudotetaan. Toinen on etuliitteen törmäys: Dockerin oletussilta omistaa 172.17.0.0/16:n ja yritystunneli työntää saman alueen.

Toinen korjataan reititystaululla, toinen numeroimalla silta uudelleen. Muokkaaminen ennen kuin tietää, kumpi on kumpi, on tapa rikkoa toimiva kontti.

Ratkaise kolmella kysymyksellä

Kysymys yksi: katoaako vika, kun pysäytät VPN:n? Jos kaikki toimii tunnelin ollessa alhaalla, epäile paluupolkua. Kysymys kaksi: listaako ip route show table all saman etuliitteen kahdesti, kerran sillalla ja kerran tun0:lla? Se on törmäys. Kysymys kolme: onko kärsinyt osoite kontti, NAT-vieras vai siltaan liitetty vieras?

Kolmas kysymys on tärkeä, koska jokaisella on eri oikea korjaus, ja kontin korjauksen soveltaminen libvirt-vieraaseen tuhlaa yhden illan.

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

Paluupolku: taulu yhdelle lähdeosoitteelle

Kun kontin liikenteen on lähdettävä fyysisen liitännän kautta samalla kun isäntä itse käyttää tunnelia, lähdeperusteinen reititys on pienin muutos. Lisää sääntö, joka vastaa kontin osoitetta, ja lähetä se omaan tauluun. Mikään muu isännällä ei liiku.

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

Jokainen paketti, jonka lähde on tuo osoite, katsoo ensin taulua 10, ja taulu 10 lähettää sen sillan yhdyskäytävälle tunnelin sijaan.

Vahvista komennolla ip route get 1.1.1.1 from 172.22.0.3. Vastauksen on nimettävä sillan liitäntä, ei tun0. Näin lisätyt säännöt katoavat uudelleenkäynnistyksessä, joten laita ne unit-yksikköön tai verkkokoukkuun, joka omistaa kontin.

Sama kuvio toimii WireGuard-kontille, jossa myös vastauspolku tarvitsee nimenomaisen säännön.

Etuliitteen törmäys: numeroi silta uudelleen

Reititystaulu lähettää yhden etuliitteen yhteen paikkaan. Jos VPN työntää 172.17.0.0/16:n, kun Dockerin silta on jo siellä, pienempi metriikka voittaa: Docker asentaa yhdistetyn reittinsä metriikalla 0, ja työnnetty reitti saapuu metriikalla 50. Silloin tunneli näyttää rikkoutuneelta, kun Docker jatkaa toimintaansa, tai päinvastoin, asennusjärjestyksestä riippuen. Numeroi silta uudelleen sen sijaan, että taistelet metriikan kanssa.

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

Käynnistä Docker uudelleen muutoksen jälkeen ja luo uudelleen vanhalla altaalla rakennetut verkot. Metriikan muuttaminen vain siirtää ristiriidan seuraavaan käynnistykseen.

VM:t tarvitsevat jälleen eri vastauksen

Oletus-NAT-verkon libvirt-vieras perii isännän reitityksen ja lakkaa tavoittamasta ulkopuolta heti, kun isännän tunneli omistaa oletusreitin. Vieraan siirtäminen siltaan tai macvtap-laitteeseen antaa sille oman polun fyysisessä verkossa. Lisää virt-managerissa laitteisto, valitse Network, aseta lähteeksi macvtap-isäntälaite, pidä virtio mallina ja poista sitten vanha NAT-liitäntä käytöstä.

macvtap-vieras ei yleensä tavoita omaa isäntäänsä. Se on odotettua käytöstä eikä vika, ja se kuuluu muistiinpanoon, jonka jätät.

Vieraalle, joka tarvitsee vain isännän lähiverkon, toimittajan asiakkaassa voi olla puuttuva kytkin: Mullvadin kanssa mullvad lan set allow palauttaa paikallisen tavoitettavuuden koskematta libvirtiin. Ja kun kontin on oltava tavoitettavissa vain tunnelin kautta, sido julkaistu portti tunnelin osoitteeseen, -p 10.8.0.5:8080:8080, sen sijaan että julkaisisit sen jokaisessa osoitteessa.