Docker-Container iwwer VPN net erreechbar? Vergläicht d'Subnetzer

Docker gëtt en Subnetz aus, deen och d'VPN beusprocht. Vergläicht déi zwou Adresspläng, an eng Reparatur, déi en Neiverbannen iwwersteet.

D'Containeren äntweren am Büro-LAN, a si stoppen direkt mat äntweren, wéi d'Firma-VPN sech verbënnt. Am Container huet sech näischt geännert: keen Neistart, keen Image-Update, keng Konfiguratiounsännerung. Geännert huet sech d'Routentabelle vum Host, wou eng Route, déi den Tunnel dobäigesat huet, elo d'Adress deckt, déi Docker ausginn huet. Ier Dir en Subnetz ännert oder eng VPN-Ausnam fuerdert, setzt déi zwou Adresspläng niefteneen, well d'Reparaturen ganz ënnerschiddlech laang daueren.

Liest d'Route, ier Dir d'Konfiguratioun ännert

Fänkt mam Netz un, dat Docker tatsächlech gebaut huet. Den IPAM-Block ass den Adressplang, an den Subnetz ass déi Zeil, déi zielt:

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

Compose deelt standardméisseg en /16 pro neie Projet zou, sou datt zwou Servicer an engem Beräich vun 65,536 Adressen sëtze kënnen. Genau déi Breet mécht Iwwerlappungen heefeg: en zoufälleg gewielten /16 ass grouss genuch, fir eng Site ze schlécken, déi Dir iwwer den Tunnel erreecht, an et mierkt kee bis den Tunnel opgeet.

Vergläicht duerno d'Routeselektioun fir eng Containeradress, eemol mam Tunnel zou an eemol mat him op:

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

Zwou Forme vun Äntwert féieren op verschidde Plazen. Wann d'Ausgab tun0, wg0 oder en aneren Tunnelapparat nennt, ass e VPN-Prefix op d'mannst esou spezifesch wéi d'Bréckroute an de Paket erreecht den Container ni. Wann et nach ëmmer d'Bréck nennt, kann den Host den Container erreechen, an Äre Feeler ass Filterung, DNS oder en Zréckwee, dee just an enger Richtung feelt.

Firwat eng /16-Kollisioun liicht geschitt

Docker hëlt Brécknetzer aus de private Pools, an de Standardpool kënnt aus dem 172.16.0.0/12 Block an /16-Stécker. Firmenetzer benotzen dacks déiselwecht privat Plaz, an eng Remote-Access-VPN dréckt déi Prefixen op all Client, dee sech verbënnt. Wann béid Säiten gleewen, si besëtzen 172.18.0.0/16, hält eng Routentabelle zwou widerspréchlech Uspréch.

D'Prefixlängt entscheet de Gewënner, net d'Reiefolleg vun de Routen. En Tunnel, deen 10.0.0.0/8 dréckt, gewënnt net géint eng Bréckroute vun 172.18.0.0/16, well /8 manner spezifesch ass. En Tunnel, deen 172.18.0.0/16, oder 172.18.5.0/24 dobannen, dréckt, gewënnt dogéint. Dofir schafft ee Laptop am Firmenetz a feelt am Hotel-Wi-Fi mat der selwechter VPN: de Client kritt aner Prefixen.

Déiselwecht Tabelle regéiert déi aner Richtung. 10.8.4.20 brauch, schéckt de Paket op seng Bréck-Gateway, an den Host routet et dann an den Tunnel. Dee Wee funktionéiert normalerweis, well den Host den NAT mécht, awer hie feelt, wann déi korporativ Säit just d'VPN-Adress vum Laptop acceptéiert oder wann d'Reverse-Path-Filterung déi asymmetresch Äntwert verwerft.

Vergläicht déi dräi Reparaturen

Et gëtt just dräi Auswee, an si ënnerscheede sech doran, wien si geneemegen muss a wat während der Applizéierung brécht.

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

D'Renummeréierung ass déi eenzeg Reparatur, déi Dir ouni Ticket fäerdeg kritt, dofir halen déi meeschte Schrëften do un. An engem jonke Projet ass se bëlleg, awer deier, wann en Migratiounsinstrument oder eng gespäichert Verbindungszeechen op eng wuertwiertlech Adress weist. Zielt déi Referenzen, ier Dir YAML ännert, net duerno.

Eng Ausnam vum Tunnel ass déi propperst Äntwert, wann den Iwwerlapp an engem Beräich läit, deen Är Firma wierklech besëtzt. Se ass och déi luesst, an se ass nëtzlos fir en Handwierker, dee säi Clientprofil net ännere kann. En publizéierte Port oder en klenge Reverse-Proxy vermeit de Sträit: de Client schwätzt mat enger Adress, déi den Tunnel schonn richteg routet, an just dee Port muss erreechbar sinn.

Pinn en Beräich bewosst fest

Fir ee Projet deklaréiert den Subnetz an der compose-Datei, sou datt de Projet ophält, aus dem gedeelte Pool ze schöpfen:

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

Huelt dee Beräich aus engem Register, deen Är Equipe féiert, net aus engem Beispill, dat Dir beim Sichen fonnt hutt. Kuckt en géint d'Prefixen, déi d'VPN dréckt, d'Heem-LANen, vun deenen d'Leit schaffen, an déi aner Container-Netzer um selwechten Host. Plangt dann d'Neiopsetzen, well en existéierend Netz säin ale Subnetz behält: docker compose down, dann up -d. docker network rm refuséiert, soulaang Endpunkten ugehänkt sinn, an all ipv4_address Zeilen an der Datei mussen an den neie Beräich falen.

Fir Netzer, déi Docker selwer uleet, setzt en Daemon-Pool an /etc/docker/daemon.json:

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

De Pool gëllt fir Netzer, déi no engem Neistart vum Daemon ugeleet goufen, an Brécken, déi et schonn gëtt, behalen hir Adressen. Dat ass bequem a liicht ze vergiessen, also behandelt en ale Projet nach ëmmer als iwwerlappend, bis een säin Netz nei uleet. Dem Docker seng Engine-Networking-Dokumentatioun beschreift d'Allocatiounsregelen, wann Dir de Pool an enger Revue musst verdeedegen.

Linux-Bréck an Docker Desktop feelen anescht

Op engem Linux-Host sëtzen d'Containeren op Brécken am Host-Namespace. Eng eenzeg Tabelle entscheet alles, dofir ass de Verglach uewen déi ganz Geschicht: liest d'Bréckroute, liest d'Tunnelroute, a kuckt wien fir eng richteg Containeradress gewënnt.

Docker Desktop setzt d'Containeren hannert eng VM mat engem eegenen NAT. Den Host huet iwwerhaapt keng Route op d'Containeradress; hie kritt de Service iwwer en publizéierte Port, deen normalerweis un 127.0.0.1 gebonnen ass. En VPN-Client kann de Service also ouni all Subnetz-Iwwerlappung briechen, entweder andeems en eng Route fir de bannenzege Beräich vun der VM installéiert oder andeems en Loopback-Traffic blockéiert, soulaang den Tunnel verbonnen ass. Wann ip route get um Host keng Route fir d'Containeradress mellt, dann ass dat erwaart a net de Feeler.

D'praktesch Konsequenz ass, wou Dir als éischt kuckt. Op Linux fänkt Dir an der Routentabelle un. Op Desktop fänkt Dir beim publizéierte Port an de Firewall-Regele vum VPN-Client un, a kuckt dann, ob den interne Subnetz vun der VM mat eppes kollidéiert, wat den Tunnel dréckt.

Verifizéiert mam Tunnel op

Verbind d'VPN zweemol nei, ier Dir et als reparéiert bezeechent, well e Profil, deen d'Routen beim Verbannen dréckt an se beim Trennen zréckzéit, nom éischten Versuch richteg ausgesinn kann. Da lafe léisst d'Kontrollen, déi de Client tatsächlech mécht:

  1. ip route get vum Host, mat der richteger Adress vum Container.
  2. Eng Ufro vun engem aneren Container, fir ze beweisen, datt de Service selwer gesond ass.
  3. curl -sv http://127.0.0.1:8080/ vum Client mam Tunnel op, dann traceroute -n op d'Containeradress vun enger Maschinn am LAN.
  4. sysctl net.ipv4.conf.all.rp_filter wann d'Ufro den Host erreecht, awer d'Äntwert verschwënnt.

Schreift schlussendlech de gewielte Beräich an dat selwecht Register, aus deem Dir en gewielt hutt, mat Datum a mat deem Projet, deen en besëtzt. Den nächsten Iwwerlapp kënnt vun engem Projet, deen keen dokumentéiert huet, an déi eenzeg Verdeedegung ass, datt de Beräich bewosst reservéiert gouf an net zoufälleg gezunn.

Ähnlech Artikelen