Vsebnik Docker ni dosegljiv prek VPN? Primerjajte podomrežja

Vsebniki odgovarjajo v pisarniškem LAN, nato pa prenehajo odgovarjati v trenutku, ko se poveže službeni VPN. V vsebniku se ni spremenilo nič: brez ponovnega zagona, brez posodobitve slike, brez urejanja konfiguracije. Spremenila se je usmerjevalna tabela gostitelja, kjer pot, ki jo je dodal tunel, zdaj pokriva naslov, ki ga je dodelil Docker. Preden uredite podomrežje ali zaprosite za izjemo pri VPN, položite oba načrta naslovov drug ob drugega, saj popravki zahtevajo zelo različno količino časa.

Preberite pot, preden spremenite konfiguracijo

Začnite z omrežjem, ki ga je Docker resnično zgradil. Blok IPAM je načrt naslovov, podomrežje pa je vrstica, ki je pomembna:

docker network inspect project_default --format '{{json .IPAM.Config}}'
# [{"Subnet":"172.18.0.0/16","Gateway":"172.18.0.1"}]

Compose privzeto dodeli /16 vsakemu novemu projektu, zato se lahko dve storitvi znajdeta v obsegu 65,536 naslovov. Prav ta širina je razlog, da so prekrivanja pogosta: naključno izbrani /16 je dovolj velik, da pogoltne mesto, do katerega pridete skozi tunel, in nihče tega ne opazi, dokler se tunel ne dvigne.

Nato primerjajte izbiro poti za en naslov vsebnika, enkrat z izklopljenim tunelom in enkrat z vklopljenim:

ip route get 172.18.0.7
# 172.18.0.7 dev br-3f2a9c src 172.18.0.1

Dve obliki odgovora vodita na različna mesta. Če izpis navaja tun0, wg0 ali drugo tunelsko napravo, je predpona VPN vsaj tako specifična kot pot mostu in paket nikoli ne doseže vsebnika. Če še vedno navaja most, lahko gostitelj doseže vsebnik, vaša napaka pa je filtriranje, DNS ali povratna pot, ki odpove le v eni smeri.

Zakaj je trčenje /16 lahko doseči

Docker jemlje mostovna omrežja iz zasebnih naborov, privzeti nabor pa izhaja iz bloka 172.16.0.0/12 v kosih /16. Podjetniška omrežja pogosto uporabljajo isti zasebni prostor, VPN za oddaljeni dostop pa te predpone potiska vsakemu odjemalcu, ki se poveže. Ko obe strani verjameta, da imata v lasti 172.18.0.0/16, ena usmerjevalna tabela vsebuje dve nasprotujoči si zahtevi.

Zmagovalca odloči dolžina predpone, ne vrstni red poti. Tunel, ki potiska 10.0.0.0/8, ne premaga poti mostu 172.18.0.0/16, ker je /8 manj specifičen. Tunel, ki potiska 172.18.0.0/16 ali 172.18.5.0/24 znotraj nje, jo premaga. Zato en prenosnik deluje v pisarniškem omrežju in odpove na hotelskem Wi-Fi z istim VPN: odjemalec prejme različne predpone.

Ista tabela upravlja tudi nasprotno smer. Vsebnik, ki potrebuje notranjega gostitelja na 10.8.4.20, pošlje paket na svoj mostovni prehod, gostitelj pa ga nato usmeri v tunel. Ta pot običajno deluje, ker gostitelj izvaja NAT, a odpove, ko podjetniška stran sprejme le VPN naslov prenosnika, ali ko filtriranje povratne poti zavrže asimetrični odgovor.

Primerjajte tri popravke

Obstajajo le tri izhodi, razlikujejo pa se po tem, kdo jih mora odobriti in kaj se pokvari, medtem ko enega izvajate.

Prenumeriranje je edini popravek, ki ga lahko dokončate brez zahtevka, zato se večina besedil ustavi tam. Pri mladem projektu je poceni, drago pa postane, ko orodje za selitev ali shranjena povezovalna veriga kaže na dobesedni naslov. Preštejte te sklice pred urejanjem YAML, ne po njem.

Izjema pri tunelu je najčistejši odgovor, ko prekrivanje leži v obsegu, ki ga vaše podjetje resnično ima v lasti. Je tudi najpočasnejša in je neuporabna za izvajalca, ki ne more spremeniti profila odjemalca. Objavljena vrata ali majhen obratni posrednik se izogneta sporu: odjemalec govori z naslovom, ki ga tunel že usmerja pravilno, dosegljiva pa morajo biti le ta vrata.

Pripnite obseg namerno

Za en projekt deklarirajte podomrežje v datoteki compose, da projekt preneha črpati iz skupnega nabora:

networks:
  default:
    ipam:
      config:
        - subnet: 10.201.7.0/24

Vzemite ta obseg iz registra, ki ga vodi vaša ekipa, ne iz primera, ki ste ga našli med iskanjem. Preverite ga glede na predpone, ki jih potiska VPN, domača omrežja, iz katerih ljudje delajo, in druga vsebniška omrežja na istem gostitelju. Nato načrtujte ponovno ustvarjanje, ker obstoječe omrežje obdrži staro podomrežje: docker compose down, nato up -d. docker network rm zavrne, dokler so končne točke pripete, vsak vnos ipv4_address v datoteki pa mora pasti v novi obseg.

Za omrežja, ki jih Docker ustvari sam, nastavite nabor demonskega procesa v /etc/docker/daemon.json:

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

Nabor velja za omrežja, ustvarjena po ponovnem zagonu demona, mostovi, ki že obstajajo, pa obdržijo svoje naslove. To je priročno in zlahka pozabite, zato obravnavajte star projekt kot še vedno prekrivajoč, dokler nekdo ne ponovno ustvari njegovega omrežja. omrežna dokumentacija pogona Docker opisuje pravila dodeljevanja, če morate nabor zagovarjati na pregledu.

Most Linux in Docker Desktop odpovesta različno

Na gostitelju Linux vsebniki sedijo na mostovih v imenskem prostoru gostitelja. Vse odloči ena tabela, zato je zgornja primerjava celotna zgodba: preberite pot mostu, preberite pot tunela in poglejte, katera zmaga za resnični naslov vsebnika.

Docker Desktop postavi vsebnike za VM z lastnim NAT. Gostitelj sploh nima poti do naslova vsebnika; do storitve pride prek objavljenih vrat, običajno vezanih na 127.0.0.1. Odjemalec VPN lahko zato pokvari storitev brez kakršnega koli prekrivanja podomrežij: bodisi z namestitvijo poti za notranji obseg VM bodisi z blokiranjem loopback prometa, medtem ko je tunel povezan. Če ip route get na gostitelju poroča, da poti do naslova vsebnika ni, je to pričakovano in ne napaka.

Praktična posledica je, kam pogledate najprej. Na Linuxu začnite z usmerjevalno tabelo. Na Desktopu začnite z objavljenimi vrati in pravili požarnega zidu odjemalca VPN, nato preverite, ali se notranje podomrežje VM zaleti v kaj, kar potiska tunel.

Preverite z vklopljenim tunelom

Ponovno povežite VPN dvakrat, preden to razglasite za popravljeno, ker je profil, ki ob povezavi potisne poti in jih ob prekinitvi umakne, po prvem poskusu lahko videti pravilen. Nato izvedite preverjanja, ki jih odjemalec resnično izvaja:

1. ip route get z gostitelja, z resničnim naslovom vsebnika.
2. Zahteva iz drugega vsebnika, da dokažete, da je storitev sama zdrava.
3. curl -sv http://127.0.0.1:8080/ z odjemalca z vklopljenim tunelom, nato traceroute -n na naslov vsebnika s stroja v LAN.
4. sysctl net.ipv4.conf.all.rp_filter, če zahteva doseže gostitelja, a odgovor izgine.

Na koncu zapišite izbrani obseg v isti register, iz katerega ste ga izbrali, z datumom in projektom, ki ga ima v lasti. Naslednje prekrivanje bo prišlo iz projekta, ki ga nihče ni dokumentiral, edina obramba pa je, da je bil obseg rezerviran namerno in ne izbran naključno.