Docker-houer onbereikbaar op VPN? Vergelyk die subnetwerke

Houers antwoord op die kantoor-LAN en hou dan op antwoord die oomblik wanneer die maatskappy-VPN koppel. Niks in die houer het verander nie: geen herbegin, geen beeldopdatering, geen konfigurasiewysiging nie. Wat verander het, is die gasheer se roetertabel, waar 'n roete wat die tonnel bygevoeg het nou die adres dek wat Docker uitgedeel het. Voordat jy 'n subnet wysig of 'n VPN-uitsluiting aanvra, plaas albei adresplanne langs mekaar, want die herstellings kos baie verskillende hoeveelhede tyd.

Lees die roete voordat jy die konfigurasie verander

Begin met die netwerk wat Docker werklik gebou het. Die IPAM-blok is die adresplan, en die subnet is die reël wat saak maak:

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

Compose ken by verstek 'n /16 aan elke nuwe projek toe, so twee dienste kan binne 'n reeks van 65,536 adresse sit. Daardie breedte is hoekom oorvleuelings algemeen is: 'n lukraak gekose /16 is groot genoeg om 'n werf te sluk wat jy deur die tonnel bereik, en niemand merk dit totdat die tonnel opkom nie.

Vergelyk dan roeteseleksie vir een houeradres, een keer met die tonnel af en een keer met dit op:

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

Twee vorme van antwoord lei na verskillende plekke. As die uitset tun0, wg0 of 'n ander tonneltoestel noem, is 'n VPN-voorvoegsel ten minste so spesifiek soos die brugroete en bereik die pakkie nooit die houer nie. As dit steeds die brug noem, kan die gasheer die houer bereik, en jou fout is filter, DNS, of 'n terugkeerpad wat net in een rigting faal.

Hoekom 'n /16-botsing maklik is om te tref

Docker trek brugnetwerke uit die private poele, en die verstekpoel kom uit die 172.16.0.0/12 blok in /16-skywe. Korporatiewe netwerke gebruik dikwels dieselfde private ruimte, en 'n afstandtoegang-VPN stoot daardie voorvoegsels na elke kliënt wat koppel. Wanneer albei kante glo hulle besit 172.18.0.0/16, hou een roetertabel twee teenstrydige aansprake.

Voorvoegsellengte besluit die wenner, nie die volgorde waarin roetes verskyn nie. 'n Tonnel wat 10.0.0.0/8 stoot, klop nie 'n brugroete van 172.18.0.0/16, want /8 is minder spesifiek. 'n Tonnel wat 172.18.0.0/16, of 172.18.5.0/24 daarbinne stoot, klop wel. Dis hoekom een skootrekenaar op die kantoornetwerk werk en op hotel-Wi-Fi met dieselfde VPN faal: die kliënt ontvang verskillende voorvoegsels.

Dieselfde tabel beheer die ander rigting. 'n Houer wat 'n interne gasheer by 10.8.4.20 nodig het, stuur die pakkie na sy brugpoort, en die gasheer roeteer dit dan in die tonnel in. Daardie pad werk gewoonlik omdat die gasheer die NAT doen, maar dit faal wanneer die korporatiewe kant net die skootrekenaar se VPN-adres aanvaar, of wanneer tru-roete-filtrering die asimmetriese antwoord laat val.

Vergelyk die drie herstellings

Daar is net drie uitweë, en hulle verskil in wie dit moet goedkeur en wat breek terwyl jy een toepas.

Hernommering is die enigste herstelling wat jy sonder 'n kaartjie kan afhandel, en daarom stop die meeste skrywes daar. Dit is goedkoop op 'n jong projek en duur sodra 'n migrasieprogram of 'n gestoorde verbindingstring na 'n letterlike adres wys. Tel daardie verwysings voordat jy YAML wysig, nie daarna nie.

'n Uitsluiting uit die tonnel is die skoonste antwoord wanneer die oorvleueling in 'n reeks sit wat jou maatskappy werklik besit. Dit is ook die stadigste, en dit is nutteloos vir 'n kontrakteur wat nie die kliëntprofiel kan verander nie. 'n Gepubliseerde poort of 'n klein tru-proxy vermy die argument: die kliënt praat met 'n adres wat die tonnel reeds korrek roeteer, en net daardie poort hoef bereikbaar te wees.

Pen 'n reeks doelbewus vas

Vir 'n enkele projek, verklaar die subnet in die compose-lêer sodat die projek ophou om uit die gedeelde poel te trek:

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

Neem daardie reeks uit 'n register wat jou span byhou, nie uit 'n voorbeeld wat jy tydens soek gevind het nie. Kontroleer dit teen die voorvoegsels wat die VPN stoot, die tuis-LAN's waar mense werk, en die ander houernetwerke op dieselfde gasheer. Beplan dan die herskep, want 'n bestaande netwerk hou sy ou subnet: docker compose down, dan up -d. docker network rm weier terwyl eindpunte aangeheg is, en enige ipv4_address inskrywing in die lêer moet binne die nuwe reeks val.

Vir netwerke wat Docker self skep, stel 'n daemon-poel in /etc/docker/daemon.json:

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

Die poel geld vir netwerke wat geskep word nadat die daemon herbegin, en brûe wat reeds bestaan hou hul adresse. Dit is gerieflik en maklik om te vergeet, so behandel 'n ou projek as steeds oorvleuelend totdat iemand sy netwerk herskep. Docker se netwerkdokumentasie beskryf die toekenningsreëls as jy die poel in hersiening moet verdedig.

Linux-brug en Docker Desktop faal anders

Op 'n Linux-gasheer sit houers op brûe in die gasheer se naamruimte. Een tabel besluit alles, so die vergelyking hierbo is die hele storie: lees die brugroete, lees die tonnelroete, en sien watter een wen vir 'n werklike houeradres.

Docker Desktop plaas houers agter 'n VM met sy eie NAT. Die gasheer het glad geen roete na die houeradres nie; dit bereik die diens deur 'n gepubliseerde poort, gewoonlik gebind aan 127.0.0.1. 'n VPN-kliënt kan dus die diens breek sonder enige subnetoorvleueling, hetsy deur 'n roete vir die VM se interne reeks te installeer of deur loopback-verkeer te blokkeer terwyl die tonnel gekoppel is. As ip route get op die gasheer geen roete vir die houeradres rapporteer nie, is dit verwag en nie die fout nie.

Die praktiese gevolg is waar jy eerste kyk. Op Linux, begin by die roetertabel. Op Desktop, begin by die gepubliseerde poort en die VPN-kliënt se firewall-reëls, en kyk dan of die VM se interne subnet bots met iets wat die tonnel stoot.

Verifieer met die tonnel op

Herkoppel die VPN twee keer voordat jy dit reg noem, want 'n profiel wat roetes by koppeling stoot en by ontkoppeling onttrek, kan ná die eerste poging korrek lyk. Hardloop dan die kontroles wat die kliënt werklik hardloop:

1. ip route get vanaf die gasheer, met die houer se werklike adres.
2. 'n Versoek van 'n ander houer, om te bewys die diens self is gesond.
3. curl -sv http://127.0.0.1:8080/ vanaf die kliënt met die tonnel op, dan traceroute -n na die houeradres vanaf 'n masjien op die LAN.
4. sysctl net.ipv4.conf.all.rp_filter as die versoek die gasheer bereik maar die antwoord verdwyn.

Skryf laastens die gekose reeks in dieselfde register wat jy gebruik het om dit te kies, met die datum en die projek wat dit besit. Die volgende oorvleueling sal kom van 'n projek wat niemand gedokumenteer het nie, en die enigste verdediging is dat die reeks doelbewus gereserveer is eerder as lukraak getrek.