Docker-gámur óaðgengilegur á VPN? Berið saman netkerfin

Gámarnir svara á skrifstofunetinu og hætta svo að svara um leið og VPN fyrirtækisins tengist. Ekkert í gámnum breyttist: engin endurræsing, engin mynduppfærsla, engin stillingabreyting. Það sem breyttist er leiðavalstafla hýsilsins, þar sem leið sem göngin bættu við nær nú yfir vistfangið sem Docker úthlutaði. Áður en þú breytir netkerfi eða biður um VPN-undanþágu skaltu setja báðar vistfangáætlanirnar hlið við hlið, því viðgerðirnar kosta mjög mismunandi tíma.

Lestu leiðina áður en þú breytir stillingunum

Byrjaðu á netinu sem Docker byggði í raun. IPAM-blokkin er vistfangáætlunin og netkerfið er lína sem skiptir máli:

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

Compose úthlutar /16 til hvers nýs verkefnis sjálfgefið, svo tvær þjónustur geta setið innan 65,536 vistfanga. Einmitt þessi breidd gerir skörun algenga: /16 sem valið er af handahófi er nógu stórt til að gleypa svæði sem þú nærð í gegnum göngin, og enginn tekur eftir því fyrr en göngin fara upp.

Berðu síðan saman leiðarval fyrir eitt gámavistfang, einu sinni með göngin niðri og einu sinni uppi:

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

Tvær gerðir svars leiða á ólíka staði. Ef úttakið nefnir tun0, wg0 eða annað göngutæki er VPN-forskeytið að minnsta kosti jafn sértækt og brúarleiðin og pakkanum berst aldrei í gáminn. Ef það nefnir brúna enn getur hýsillinn náð í gáminn og bilunin þín er síun, DNS eða afturleið sem bregst aðeins í aðra átt.

Hvers vegna /16 árekstur er auðveldur

Docker sækir brúarnet úr einkalausunum og sjálfgefna lausnin kemur úr blokkinni 172.16.0.0/12 í /16 sneiðum. Fyrirtækjanet nota oft sama einkarýmið og fjaraðgangs-VPN ýtir þessum forskeytum til hvers biðlar sem tengist. Þegar báðir aðilar telja sig eiga 172.18.0.0/16, heldur ein leiðavalstafla tveimur misvísandi fullyrðingum.

Lengd forskeytisins ræður sigurvegaranum, ekki röðin sem leiðirnar birtast í. Göng sem ýta 10.0.0.0/8 sigra ekki brúarleið 172.18.0.0/16, því /8 er minna sértækt. Göng sem ýta 172.18.0.0/16, eða 172.18.5.0/24 innan í henni, gera það. Þess vegna virkar ein fartölva á skrifstofunetinu og bregst á hótel-Wi-Fi með sama VPN: biðlarinn fær ólík forskeyti.

Sama tafla stýrir hinni áttinni. Gámur sem þarf innri hýsil á 10.8.4.20 sendir pakkann á brúargátt sína og hýsillinn beinir honum síðan í göngin. Sú leið virkar venjulega því hýsillinn framkvæmir NAT, en hún bregst þegar fyrirtækjahliðin samþykkir aðeins VPN-vistfang fartölvunnar, eða þegar síun afturleiðar sleppir ósamhverfa svarinu.

Berðu saman þrjár viðgerðirnar

Aðeins eru þrjár útgönguleiðir og þær eru ólíkar að því hver verður að samþykkja þær og hvað brotnar meðan þú beitir einni.

Endurnúmerun er eina viðgerðin sem þú getur klárað án miða, og þess vegna stöðvast flest skrif þar. Hún er ódýr í ungum verkefnum og dýr um leið og flutningstól eða geymdur tengistrengur vísar á bókstaflegt vistfang. Teldu þessar tilvísanir áður en þú breytir YAML, ekki eftir.

Undanþága frá göngunum er hreinasta svarið þegar skörunin er í sviði sem fyrirtækið þitt á í raun. Hún er líka hægasta leiðin og gagnslaus fyrir verktaka sem getur ekki breytt biðlarasniðinu. Birt port eða lítill öfugur milliþjónn forðast rökræðurnar: biðlarinn talar við vistfang sem göngin beina þegar rétt, og aðeins það port þarf að vera aðgengilegt.

Festu svið viljandi

Fyrir eitt verkefni skaltu lýsa netkerfinu í compose-skránni svo verkefnið hætti að sækja úr sameiginlegu lausninni:

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

Taktu það svið úr skrá sem teymið þitt heldur, ekki úr dæmi sem þú fannst við leit. Athugaðu það gegn forskeytum sem VPN-ið ýtir, heimanetum sem fólk vinnur úr og öðrum gámanetum á sama hýsli. Skipuleggðu síðan endursköpunina, því núverandi net heldur gamla netkerfinu sínu: docker compose down, síðan up -d. docker network rm neitar á meðan endapunktar eru tengdir, og hver ipv4_address færsla í skránni verður að falla innan nýja sviðsins.

Fyrir net sem Docker býr til sjálft skaltu setja daemon-lausn í /etc/docker/daemon.json:

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

Lausnin gildir um net sem búin eru til eftir að daemon er endurræstur, og brýr sem þegar eru til halda vistföngum sínum. Það er þægilegt og auðvelt að gleyma, svo meðhöndlaðu gamalt verkefni sem enn skarast þangað til einhver endurskapar netið þess. Docker-skjöl um netkerfi vélarinnar lýsa úthlutunarreglunum ef þú þarft að verja lausnina í yfirferð.

Linux-brú og Docker Desktop bregðast á ólíkan hátt

Á Linux-hýsli sitja gámar á brúm í nafnrými hýsilsins. Ein tafla ræður öllu, svo samanburðurinn hér að ofan er öll sagan: lestu brúarleiðina, lestu gönguleiðina og sjáðu hvor vinnur fyrir raunverulegt gámavistfang.

Docker Desktop setur gáma bak við VM með eigin NAT. Hýsillinn hefur alls enga leið að vistfangi gámsins; hann nær í þjónustuna í gegnum birt port, venjulega bundið við 127.0.0.1. VPN-biðlari getur því brotið þjónustuna án nokkurrar netkersskörunar, annaðhvort með því að setja leið fyrir innra svið VM eða með því að loka loopback-umferð á meðan göngin eru tengd. Ef ip route get á hýslinum tilkynnir að engin leið sé fyrir gámavistfangið er það vonlegt en ekki gallinn.

Hagnýta afleiðingin er hvar þú horfir fyrst. Á Linux skaltu byrja á leiðavalstöflunni. Á Desktop skaltu byrja á birta portinu og eldveggsreglum VPN-biðlarans og athuga svo hvort innra netkerfi VM skarist við eitthvað sem göngin ýta.

Staðfestu með göngin uppi

Tengdu VPN aftur tvisvar áður en þú segir það lagað, því snið sem ýtir leiðum við tengingu og dregur þær til baka við aftengingu getur litið rétt út eftir fyrstu tilraun. Keyrðu síðan þær prófanir sem biðlarinn keyrir í raun:

1. ip route get frá hýslinum, með raunverulegu vistfangi gámsins.
2. Beiðni frá öðrum gámi, til að sanna að þjónustan sjálf sé heilbrigð.
3. curl -sv http://127.0.0.1:8080/ frá biðlaranum með göngin uppi, síðan traceroute -n að vistfangi gámsins frá vél á netinu.
4. sysctl net.ipv4.conf.all.rp_filter ef beiðnin nær hýslinum en svarið hverfur.

Að lokum skaltu skrifa valda sviðið í sama skrá og þú notaðir til að velja það, með dagsetningunni og verkefninu sem á það. Næsta skörun kemur frá verkefni sem enginn skjalfesti, og eina vörnin er að sviðið var frátekið viljandi en ekki dregið af handahófi.