Dockeri konteiner ei ole VPN-i kaudu kättesaadav? Võrrelge alavõrke

Docker jagab alavõrgu, mida nõuab ka VPN. Võrrelge kahte aadressiplaani ja valige siis parandus, mis peab vastu taasühendamisele.

Konteinerid vastavad kontori LAN-is ja lakkavad vastamast hetkel, mil ettevõtte VPN ühendub. Konteineris ei ole midagi muutunud: ei taaskäivitust, ei pildi uuendust, ei konfiguratsiooni muudatust. Muutunud on hosti marsruutimistabel, kus tunneli lisatud marsruut katab nüüd Dockeri antud aadressi. Enne alavõrgu muutmist või VPN-i erandi taotlemist pange mõlemad aadressiplaanid kõrvuti, sest parandused maksavad väga erinevalt aega.

Lugege marsruuti enne konfiguratsiooni muutmist

Alustage võrgust, mille Docker tegelikult ehitas. IPAM-plokk on aadressiplaan ja alavõrk on rida, mis loeb:

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

Compose eraldab vaikimisi igale uuele projektile /16, nii et kaks teenust mahuvad 65,536 aadressi suurusesse vahemikku. Just see laius teeb kattumised tavaliseks: juhuslikult valitud /16 on piisavalt suur, et neelata sait, kuhu te tunnelist jõuate, ja keegi ei märka seda enne, kui tunnel tõuseb.

Seejärel võrrelge marsruudi valikut ühe konteineri aadressi jaoks, üks kord tunneliga maas ja üks kord tunneliga üleval:

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

Kaks vastuse kuju viivad erinevatesse kohtadesse. Kui väljund nimetab tun0, wg0 või mõnda muud tunneliseadet, on VPN-i prefiks vähemalt sama spetsiifiline kui silla marsruut ja pakett ei jõua kunagi konteinerini. Kui see nimetab endiselt silda, pääseb host konteinerini ja teie viga on filtreerimine, DNS või tagasitee, mis ebaõnnestub ainult ühes suunas.

Miks /16 kokkupõrge on kergesti tabatav

Docker võtab sillavõrgud privaatsetest kogumitest ja vaikekogum tuleb plokist 172.16.0.0/12 /16 viiludena. Ettevõttevõrgud kasutavad sageli sama privaatset ruumi ja kaugjuurdepääsu VPN lükkab need prefiksid igale ühenduvale kliendile. Kui mõlemad pooled usuvad, et nad omavad 172.18.0.0/16, hoiab üks marsruutimistabel kahte vastuolulist väidet.

Võitja otsustab prefiksi pikkus, mitte marsruutide ilmumise järjekord. Tunnel, mis lükkab 10.0.0.0/8 ei võida silla marsruuti 172.18.0.0/16, sest /8 on vähem spetsiifiline. Tunnel, mis lükkab 172.18.0.0/16, või 172.18.5.0/24 selle sees, võidab. Sellepärast üks sülearvuti töötab kontorivõrgus ja ebaõnnestub hotelli Wi-Fi-s sama VPN-iga: klient saab erinevad prefiksid.

Sama tabel juhib ka vastassuunda. Konteiner, mis vajab sisemist hosti aadressil 10.8.4.20 saadab paketi oma silla lüüsile ja host suunab selle seejärel tunnelisse. See tee töötab tavaliselt, sest host teeb NAT-i, kuid see ebaõnnestub, kui ettevõtte pool aktsepteerib ainult sülearvuti VPN-aadressi või kui pöördtagasi tee filtreerimine viskab asümmeetrilise vastuse kõrvale.

Võrrelge kolme parandust

Väljapääse on ainult kolm ja need erinevad selle poolest, kes peab need kinnitama ja mis läheb katki, kui ühte rakendate.

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

Ümbernumerdamine on ainus parandus, mille saate ilma piletita lõpetada, ja seetõttu peatuvad enamik kirjutisi seal. See on odav noores projektis ja kallis, kui migratsioonitööriist või salvestatud ühendusstring osutab sõnasõnalisele aadressile. Loendage need viited enne YAML-i muutmist, mitte pärast.

Tunnelist väljajätmine on kõige puhtam vastus, kui kattumine asub vahemikus, mida teie ettevõte tõesti omab. See on ka kõige aeglasem ja kasutu töövõtjale, kes ei saa kliendiprofiili muuta. Avaldatud port või väike vastupidine puhverserver väldib vaidluse: klient räägib aadressiga, mida tunnel juba õigesti suunab, ja kättesaadav peab olema ainult see port.

Kinnitage vahemik meelega

Ühe projekti jaoks deklareerige alavõrk compose-failis, et projekt lakkaks ühisest kogumist võtmast:

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

Võtke see vahemik registrist, mida teie meeskond peab, mitte otsides leitud näitest. Kontrollige seda VPN-i lükatavate prefiksite, koduste LAN-ide, kust inimesed töötavad, ja samas hostis olevate teiste konteinerivõrkude vastu. Seejärel planeerige uuestiloomine, sest olemasolev võrk hoiab oma vana alavõrgu: docker compose down, seejärel up -d. docker network rm keeldub, kui lõpp-punktid on küljes, ja iga ipv4_address kirje failis peab jääma uue vahemiku sisse.

Võrkude jaoks, mille Docker ise loob, määrake deemonikogum failis /etc/docker/daemon.json:

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

Kogum kehtib võrkudele, mis luuakse pärast deemoni taaskäivitust, ja sillad, mis juba olemas, hoiavad oma aadresse. See on mugav ja kergesti unustatav, seega käsitlege vana projekti endiselt kattuvana, kuni keegi selle võrgu uuesti loob. Dockeri mootori võrgustiku dokumentatsioon kirjeldab eraldusreegleid, kui peate kogumit ülevaatusel kaitsma.

Linuxi sild ja Docker Desktop ebaõnnestuvad erinevalt

Linuxi hostis istuvad konteinerid hosti nimeruumi sildadel. Üks tabel otsustab kõik, seega ülaltoodud võrdlus on kogu lugu: lugege silla marsruuti, lugege tunneli marsruuti ja vaadake, milline võidab tõelise konteineri aadressi jaoks.

Docker Desktop paneb konteinerid VM-i taha, millel on oma NAT. Hostil ei ole konteineri aadressile üldse marsruuti; see jõuab teenuseni avaldatud pordi kaudu, tavaliselt seotud aadressiga 127.0.0.1. Seetõttu võib VPN-klient teenuse rikkuda ilma igasuguse alavõrkude kattumiseta, kas paigaldades marsruudi VM-i sisemisele vahemikule või blokeerides loopback-liikluse, kui tunnel on ühendatud. Kui ip route get hostis teatab, et konteineri aadressile marsruuti ei ole, on see oodatud, mitte viga.

Praktiline tagajärg on see, kuhu kõigepealt vaadata. Linuxis alustage marsruutimistabelist. Desktopis alustage avaldatud pordist ja VPN-kliendi tulemüürireeglitest, seejärel kontrollige, kas VM-i sisemine alavõrk põrkub millegagi, mida tunnel lükkab.

Kontrollige tunneliga üleval

Ühendage VPN kaks korda uuesti, enne kui nimetate selle parandatuks, sest profiil, mis ühendamisel marsruudid lükkab ja katkestamisel tagasi võtab, võib pärast esimest katset õige välja näha. Seejärel käivitage kontrollid, mida klient tegelikult käivitab:

  1. ip route get hostist, kasutades konteineri tegelikku aadressi.
  2. Päring teisest konteinerist, et tõestada, et teenus ise on terve.
  3. curl -sv http://127.0.0.1:8080/ kliendist, kui tunnel on üleval, seejärel traceroute -n konteineri aadressile LAN-is olevalt masinalt.
  4. sysctl net.ipv4.conf.all.rp_filter kui päring jõuab hostini, kuid vastus kaob.

Lõpuks kirjutage valitud vahemik samasse registrisse, millest te selle võtsite, kuupäeva ja projekti nimega, kellele see kuulub. Järgmine kattumine tuleb projektist, mida keegi ei dokumenteerinud, ja ainus kaitse on see, et vahemik reserveeriti meelega, mitte ei tõmmatud juhuslikult.

Seotud artiklid