Kontejneri Docker i paarritshëm përmes VPN? Krahasoni nënrrjetet

Kontejnerët përgjigjen në LAN-in e zyrës, pastaj ndalojnë së përgjigjuri në momentin që lidhet VPN-ja e kompanisë. Në kontejner nuk ka ndryshuar asgjë: as rinisje, as përditësim imazhi, as redaktim konfigurimi. Ajo që ndryshoi është tabela e rrugëzimit të hostit, ku një rrugë e shtuar nga tuneli tani mbulon adresën që dha Docker. Përpara se të redaktoni një nënrrjet ose të kërkoni një përjashtim nga VPN, vendosni dy planet e adresave krah për krah, sepse rregullimet kërkojnë sasi shumë të ndryshme kohe.

Lexoni rrugën përpara se të ndryshoni konfigurimin

Filloni me rrjetin që Docker ndërtoi vërtet. Blloku IPAM është plani i adresave, dhe nënrrjeti është rreshti që ka rëndësi:

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

Compose ndan si parazgjedhje një /16 për çdo projekt të re, kështu që dy shërbime mund të qëndrojnë brenda një intervali prej 65,536 adresash. Kjo gjerësi është arsyeja pse mbivendosjet janë të shpeshta: një /16 i zgjedhur rastësisht është mjaft i madh për të gëlltitur një faqe që e arrini përmes tunelit, dhe askush nuk e vëren derisa tuneli të ngrihet.

Pastaj krahasoni zgjedhjen e rrugës për një adresë kontejneri, një herë me tunelin e fikur dhe një herë me atë të ndezur:

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

Dy forma përgjigjeje çojnë në vende të ndryshme. Nëse dalja përmend tun0, wg0 ose një pajisje tjetër tuneli, prefiksi i VPN është të paktën po aq specifik sa rruga e urës dhe paketa nuk arrin kurrë te kontejneri. Nëse vazhdon të përmendë urën, hosti mund ta arrijë kontejnerin, dhe defekti juaj është filtrimi, DNS ose një rrugë kthimi që dështon vetëm në një drejtim.

Pse një përplasje /16 arrihet lehtë

Docker i merr rrjetet e urës nga grupet private, dhe grupi i parazgjedhur vjen nga blloku 172.16.0.0/12 në feta /16. Rrjetet e korporatave shpesh përdorin të njëjtin hapësirë private, dhe një VPN aksesi në distancë i shtyn ato prefikse te çdo klient që lidhet. Kur të dyja palët besojnë se zotërojnë 172.18.0.0/16, një tabelë rrugëzimi mban dy pretendime kundërshtuese.

Gjatësia e prefiksit vendos fituesin, jo rendi i rrugëve. Një tunel që shtyn 10.0.0.0/8 nuk e mund një rrugë ure 172.18.0.0/16, sepse /8 është më pak specifik. Një tunel që shtyn 172.18.0.0/16, ose 172.18.5.0/24 brenda saj, e mund. Kjo është arsyeja pse një laptop funksionon në rrjetin e zyrës dhe dështon në Wi-Fi-n e hotelit me të njëjtën VPN: klienti merr prefikse të ndryshme.

E njëjta tabelë qeveris edhe drejtimin tjetër. Një kontejner që ka nevojë për një host të brendshëm në 10.8.4.20 e dërgon paketën te porta e urës së tij, dhe pastaj hosti e rrugëzon në tunel. Ajo rrugë zakonisht funksionon sepse hosti kryen NAT-in, por dështon kur pala e korporatës pranon vetëm adresën VPN të laptopit, ose kur filtrimi i rrugës së kthimit hedh përgjigjen asimetrike.

Krahasoni tre rregullimet

Ka vetëm tre rrugëdalje, dhe ato ndryshojnë në atë se kush duhet t'i miratojë dhe çfarë thyhet ndërsa aplikoni njërën.

Rinumërimi është rregullimi i vetëm që mund ta përfundoni pa një kërkesë, dhe për këtë arsye shumica e shkrimeve ndalen aty. Është i lirë në një projekt të ri dhe i shtrenjtë sapo një mjet migrimi ose një varg lidhjeje i ruajtur tregon një adresë të mirëfilltë. Numëroni ato referenca përpara se të redaktoni YAML, jo pas.

Një përjashtim nga tuneli është përgjigja më e pastër kur mbivendosja ndodhet në një interval që kompania juaj zotëron vërtet. Është gjithashtu më i ngadaltë, dhe është i padobishëm për një kontraktor që nuk mund të ndryshojë profilin e klientit. Një port i publikuar ose një proxy i vogël i kthimit e shmang debatin: klienti flet me një adresë që tuneli tashmë e rrugëzon saktë, dhe vetëm ai port duhet të jetë i arritshëm.

Fiksoni një interval me qëllim

Për një projekt të vetëm, deklaroni nënrrjetin në skedarin compose që projekti të ndalojë marrjen nga grupi i përbashkët:

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

Merrni atë interval nga një regjistër që mban ekipi juaj, jo nga një shembull që gjetët gjatë kërkimit. Kontrollojeni kundrejt prefikseve që shtyn VPN-ja, rrjeteve shtëpiake nga të cilat punojnë njerëzit dhe rrjeteve të tjera të kontejnerëve në të njëjtin host. Pastaj planifikoni rikrijimin, sepse një rrjet ekzistues mban nënrrjetin e vjetër: docker compose down, pastaj up -d. docker network rm refuzon ndërsa ka pika fundore të lidhura, dhe çdo zë ipv4_address në skedar duhet të bjerë brenda intervalit të ri.

Për rrjetet që Docker i krijon vetë, vendosni një grup daemon në /etc/docker/daemon.json:

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

Grupi zbatohet për rrjetet e krijuara pas rinisjes së daemon-it, dhe urat që ekzistojnë tashmë i mbajnë adresat e tyre. Kjo është e përshtatshme dhe e lehtë për t'u harruar, prandaj trajtoni një projekt të vjetër si ende të mbivendosur derisa dikush ta rikrijojë rrjetin e tij. dokumentacioni i rrjetëzimit të motorit Docker përshkruan rregullat e ndarjes, nëse duhet të mbroni grupin në një rishikim.

Ura Linux dhe Docker Desktop dështojnë ndryshe

Në një host Linux, kontejnerët qëndrojnë mbi ura në hapësirën e emrave të hostit. Një tabelë e vetme vendos gjithçka, prandaj krahasimi më sipër është e gjithë historia: lexoni rrugën e urës, lexoni rrugën e tunelit dhe shikoni cila fiton për një adresë reale kontejneri.

Docker Desktop i vendos kontejnerët pas një VM me NAT të vetin. Hosti nuk ka fare rrugë drejt adresës së kontejnerit; e arrin shërbimin përmes një porti të publikuar, zakonisht të lidhur me 127.0.0.1. Prandaj një klient VPN mund ta prishë shërbimin pa asnjë mbivendosje nënrrjeti: ose duke instaluar një rrugë për intervalin e brendshëm të VM-së, ose duke bllokuar trafikun loopback ndërsa tuneli është i lidhur. Nëse ip route get në host raporton se nuk ka rrugë për adresën e kontejnerit, kjo është e pritur dhe jo defekti.

Pasoja praktike është se ku shikoni së pari. Në Linux, filloni nga tabela e rrugëzimit. Në Desktop, filloni nga porti i publikuar dhe rregullat e murit të zjarrit të klientit VPN, pastaj kontrolloni nëse nënrrjeti i brendshëm i VM-së përplaset me diçka që shtyn tuneli.

Verifikoni me tunelin të ndezur

Rilidhni VPN-në dy herë përpara se ta shpallni të rregulluar, sepse një profil që shtyn rrugët kur lidhet dhe i tërheq ato kur shkëputet mund të duket i saktë pas provës së parë. Pastaj ekzekutoni kontrollet që klienti kryen vërtet:

1. ip route get nga hosti, duke përdorur adresën e vërtetë të kontejnerit.
2. Një kërkesë nga një kontejner tjetër, për të provuar se vetë shërbimi është i shëndetshëm.
3. curl -sv http://127.0.0.1:8080/ nga klienti me tunelin të ndezur, pastaj traceroute -n drejt adresës së kontejnerit nga një makinë në LAN.
4. sysctl net.ipv4.conf.all.rp_filter nëse kërkesa arrin hostin por përgjigjja zhduket.

Së fundi, shkruani intervalin e zgjedhur në të njëjtin regjistër nga i cili e zgjodhët, me datën dhe projektin që e zotëron. Mbivendosja e radhës do të vijë nga një projekt që askush nuk e dokumentoi, dhe mbrojtja e vetme është që intervali u rezervua me qëllim dhe nuk u nxor rastësisht.