Dockeri ja VM-i liiklus OpenVPN-i taga: marsruutida või ümber nummerdada?

Host sirvib tunneli kaudu ja kõrval olev konteiner ei jõua kuhugi. Pordi avaldamine konteinerist, mis jooksutab oma VPN-klienti, on hullem: päring saabub ja vastus ei lahku kunagi. Mõlemad on marsruudimisotsused hostil ja Docker on ainult käskjalg.

Kolm küsimust otsustavad, millist kahest juhtumist te vaatate, ja see võtab umbes minuti.

Kaks riket, mis näevad välja ühtemoodi

Esimene on tagasitee probleem. Avaldatud port tõlgitakse konteinerisse, päring saabub ja vastus marsruuditakse hosti vaikemarsruudi kaudu, mille OpenVPN klient on suunanud tun0-le. Vastus lahkub aadressilt, mida kaugpartner ei oota, ja see visatakse ära. Teine on eesliite kokkupõrge: Dockeri vaikimisi sild omab 172.17.0.0/16 ja ettevõtte tunnel lükkab sama vahemikku.

Üks parandatakse marsruuditabeliga, teine silla ümbernummerdamisega. Muudatuste tegemine enne, kui tead, kumb on kumb, ongi töötava konteineri rikkumise viis.

Otsusta kolme küsimusega

Esimene küsimus: kas rike kaob, kui VPN-i peatate? Kui tunnel maas kõik töötab, kahtlusta tagasiteed. Teine küsimus: kas ip route show table all loetleb sama eesliite kaks korda, korra sillal ja korra tun0-l? See ongi kokkupõrge. Kolmas küsimus: kas mõjutatud aadress on konteiner, NAT-külaline või sillaga ühendatud külaline?

Kolmas küsimus loeb, sest igal neist on erinev õige parandus, ja konteineri lahenduse rakendamine libvirti külalisele raiskab õhtu.

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

Tagasitee: tabel ühe lähteaadressi jaoks

Kui konteineri liiklus peab väljuma füüsilisest liidesest, samal ajal kui host ise kasutab tunnelit, on lähtepõhine marsruutimine väikseim muudatus. Lisage reegel, mis vastab konteineri aadressile, ja suunake see sihtotstarbelisse tabelisse. Midagi muud hostil ei liigu.

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

Iga pakett, mille lähteks on see aadress, vaatab kõigepealt tabelit 10, ja tabel 10 saadab selle tunneli asemel silla lüüsile.

Kontrollige käsuga ip route get 1.1.1.1 from 172.22.0.3. Vastus peab nimetama silla liidest, mitte tun0. Nii lisatud reeglid kaovad taaskäivitusel, seega pange need unit-i või võrgukonksu, mis konteinerit omab.

Sama muster töötab WireGuardi konteineri puhul, kus ka vastusetee vajab selgesõnalist reeglit.

Eesliite kokkupõrge: nummerdage sild ümber

Marsruuditabel saadab ühe eesliite ühte kohta. Kui VPN lükkab 172.17.0.0/16 ja Dockeri sild on juba seal, võidab madalam metrika: Docker paigaldab oma ühendatud marsruudi metrikaga 0 ja lükatud marsruut saabub metrikaga 50. Siis näib tunnel katki, samal ajal kui Docker töötab edasi, või vastupidi, sõltuvalt paigaldamise järjekorrast. Nummerdage sild ümber, selle asemel et metrikaga võidelda.

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

Pärast muudatust taaskäivitage Docker ja looge uuesti vana pilvega ehitatud võrgud. Metrika muutmine nihutab konflikti ainult järgmisele käivitusele.

VM-id vajavad jälle teistsugust vastust

libvirti külaline vaikimisi NAT-võrgus pärib hosti marsruutimise ja lakkab väljapoole jõudmast, kui hosti tunnel saab vaikemarsruudi endale. Külalise üleviimine sillaga või macvtap-seadmele annab talle füüsilises võrgus oma tee. virt-manageris lisage riistvara, valige Network, määrake allikaks macvtap hostseade, jätke mudeliks virtio ja seejärel deaktiveerige vana NAT-liides.

macvtap-külaline ei saa tavaliselt oma hostini jõuda. See on oodatud käitumine, mitte viga, ja see kuulub märkmesse, mille jätate.

Külalisele, kes vajab ainult hosti lähivõrku, võib tarnija kliendil olla puuduv lüliti: Mullvadiga taastab mullvad lan set allow kohaliku kättesaadavuse ilma libvirti puutumata. Ja kui konteiner peab olema kättesaadav ainult tunneli kaudu, siduge avaldatud port tunneli aadressiga, -p 10.8.0.5:8080:8080, selle asemel et avaldada see igal aadressil.