Docker-konteiner net te berikken fia VPN? Ferlykje de subnetten

Docker jout in subnet dat de VPN ek opeasket. Ferlykje de twa adresplannen en kies dan in repaaraasje dy't in werferbining oerlibbet.

Konteinearen antwurdzje op it kantoar-LAN en hâlde dan op mei antwurdzjen op it momint dat de bedriuws-VPN ferbynt. Der is neat yn de konteiner feroare: gjin werstart, gjin byldbywurking, gjin konfiguraasjewizing. Wat feroare is, is de rûteringstabel fan de host, dêr't in rûte dy't de tunnel tafoege hat no it adres dekt dat Docker joech. Foardat jo in subnet bewurkje of in VPN-útsûndering freegje, sette beide adresplannen njonken elkoar, want de repaaraasjes kostje hiel ferskillende hoemannichten tiid.

Lês de rûte foardat jo de konfiguraasje feroarje

Begjin mei it netwurk dat Docker wier boud hat. It IPAM-blok is it adresplan, en it subnet is de rigel dy't der ta docht:

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

Compose jout standert in /16 oan elk nij projekt, sadat twa tsjinsten yn in berik fan 65,536 adressen pasje kinne. Krekt dy breedte makket oerlapingen gewoan: in tafallich keazen /16 is grut genôch om in side dy't jo fia de tunnel berikke op te slokken, en nimmen merkt it oant de tunnel omheech komt.

Ferlykje dan de rûtekar foar ien konteineradres, ien kear mei de tunnel del en ien kear mei de tunnel omheech:

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

Twa foarmen fan antwurd liede nei ferskillende plakken. As de útfier tun0, wg0 of in oar tunnelapparaat neamt, is in VPN-prefiks teminsten like spesifyk as de brêgerûte en it pakket berikt de konteiner nea. As it noch hieltyd de brêge neamt, kin de host de konteiner berikke, en jo flater is filtering, DNS of in weromrûte dy't mar yn ien rjochting mislearret.

Wêrom't in /16-botsing maklik te reitsjen is

Docker lûkt brêgenetwurken út de partikuliere swimbaden, en de standertswimbad komt út it blok 172.16.0.0/12 yn /16-stikken. Bedriuwsnetwurken brûke faak deselde partikuliere romte, en in VPN foar fiersjen tagong triuwt dy prefiksen nei elke klant dy't ferbynt. As beide kanten leauwe dat se 172.18.0.0/16 besitte, hâldt ien rûteringstabel twa tsjinstridige bewearingen.

De lingte fan it prefiks beslúdt de winner, net de oarder wêryn't rûtes ferskine. In tunnel dy't 10.0.0.0/8 triuwt, ferslacht gjin brêgerûte 172.18.0.0/16, om't /8 minder spesifyk is. In tunnel dy't 172.18.0.0/16, of 172.18.5.0/24 deryn triuwt, wol. Dêrom wurket ien laptop op it kantoarnetwurk en mislearret er op hotel-Wi-Fi mei deselde VPN: de klant krijt ferskillende prefiksen.

Deselde tabel regearret de oare rjochting. In konteiner dy't in ynterne host nedich hat op 10.8.4.20 stjoert it pakket nei syn brêge-gateway, en de host rûtet it dan de tunnel yn. Dat paad wurket normaal om't de host de NAT docht, mar it mislearret as de bedriuwskant allinnich it VPN-adres fan de laptop akseptearret, of as omkearde-paadfiltering it asymmetryske antwurd fuortsmyt.

Ferlykje de trije repaaraasjes

Der binne mar trije útgongen, en se ferskille yn wa't se goedkrije moat en wat der brekt wylst jo ien tapasse.

RepairWho owns itWhat it costs
Renumber the container networkYouRecreates the network, restarts services, invalidates literal addresses in configs and scripts
Exclude your range from the tunnelNetwork teamChanges what every laptop sees, needs a change request and a client profile update
Reach the service through a published portYou and the clientOne port only, no direct container-to-container routing across the tunnel

Fernûmering is de iennichste repaaraasje dy't jo sûnder ticket ôfmeitsje kinne, en dêrom stopje de measte stikken dêr. It is goedkeap op in jong projekt en djoer sadree't in migraasje-ark of in bewarre ferbiningstried nei in letterlik adres wiist. Tel dy ferwizings foardat jo YAML bewurkje, net dêrnei.

In útsûndering fan de tunnel is it skjinste antwurd as de oerlaap yn in berik leit dat jo bedriuw wier besit. It is ek it stadichste, en it is nutteleas foar in oannimmer dy't it klantprofyl net feroarje kin. In publisearre poarte of in lytse omkearde proxy foarkomt de diskusje: de klant praat mei in adres dat de tunnel al korrekt rûtet, en allinnich dy poarte hoecht berikber te wêzen.

Fêstigje in berik mei opset

Foar ien projekt, ferklearje it subnet yn it compose-triem sadat it projekt ophâldt út de mienskiplike swimbad te lûken:

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

Nim dat berik út in register dat jo team byhâldt, net út in foarbyld dat jo by it sykjen fûn. Kontrolearje it tsjin de prefiksen dy't de VPN triuwt, de thús-LAN's dêr't minsken fan wurkje, en de oare konteinernetwurken op deselde host. Plan dan de weropbou, want in besteand netwurk hâldt syn âlde subnet: docker compose down, dan up -d. docker network rm wegeret wylst einpunten fêst sitte, en elk ipv4_address item yn it triem moat binnen it nije berik falle.

Foar netwurken dy't Docker sels makket, set in daemon-swimbad yn /etc/docker/daemon.json:

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

De swimbad jildt foar netwurken dy't makke wurde neidat de daemon werstart, en brêgen dy't al bestean hâlde har adressen. Dat is handich en maklik te ferjitten, behannelje in âld projekt dus as noch oerlapjend oant immen syn netwurk wer oanmakket. Docker syn dokumintaasje oer netwurkjen fan de motor beskriuwt de taskenningsregels as jo de swimbad by in resinsje ferdigenje moatte.

Linux-brêge en Docker Desktop mislearje oars

Op in Linux-host sitte konteinearen op brêgen yn 'e nammeromte fan de host. Ien tabel beslút alles, dus de ferliking hjirboppe is it hiele ferhaal: lês de brêgerûte, lês de tunnelrûte, en sjoch hokker wint foar in echt konteineradres.

Docker Desktop set konteinearen efter in VM mei syn eigen NAT. De host hat hielendal gjin rûte nei it konteineradres; hy berikt de tsjinst fia in publisearre poarte, meastentiids bûn oan 127.0.0.1. In VPN-klant kin de tsjinst dus stikken meitsje sûnder hokker oerlaap fan subnetten dan ek, itsij troch in rûte foar it ynterne berik fan 'e VM te ynstallearjen, itsij troch loopback-ferkear te blokkearjen wylst de tunnel ferbûn is. As ip route get op 'e host meldt dat der gjin rûte is foar it konteineradres, is dat ferwachte en net de flater.

It praktykgefölch is wêr't jo earst sjogge. Op Linux begjinne jo by de rûteringstabel. Op Desktop begjinne jo by de publisearre poarte en de firewallregels fan 'e VPN-klant, en kontrolearje dan oft it ynterne subnet fan 'e VM botst mei wat de tunnel triuwt.

Ferifiearje mei de tunnel omheech

Ferbin de VPN twa kear opnij foardat jo it reparearre neame, want in profyl dat by ferbinen rûtes triuwt en by ôfbrekken weromlûkt kin nei de earste poging korrekt lykje. Rin dan de kontrôles dy't de klant wier rint:

  1. ip route get fan 'e host, mei it echte adres fan 'e konteiner.
  2. In fersyk fan in oare konteiner, om te bewizen dat de tsjinst sels sûn is.
  3. curl -sv http://127.0.0.1:8080/ fan 'e klant mei de tunnel omheech, dan traceroute -n nei it konteineradres fan in masine op it LAN.
  4. sysctl net.ipv4.conf.all.rp_filter as it fersyk de host berikt mar it antwurd ferdwynt.

Skriuw úteinlik it keazen berik yn itselde register dat jo brûkten om it te kiezen, mei de datum en it projekt dat it besit. De folgjende oerlaap sil komme fan in projekt dat nimmen dokumintearre hat, en de ienige ferdigening is dat it berik mei opset reservearre waard yn stee fan tafallich lutsen.

Relatearre artikelen