Cynhwysydd Docker yn anghyraeddadwy ar VPN? Cymharwch yr is-rwydweithiau

Mae cynwysyddion yn ateb ar LAN y swyddfa, yna'n stopio ateb yr eiliad y bydd VPN y cwmni'n cysylltu. Nid oes unrhyw beth yn y cynhwysydd wedi newid: dim ailgychwyn, dim diweddariad delwedd, dim golygu cyfluniad. Yr hyn sydd wedi newid yw tabl llwybro'r gwesteiwr, lle mae llwybr a ychwanegwyd gan y twnnel bellach yn cwmpasu'r cyfeiriad a roddodd Docker. Cyn i chi olygu is-rwydwaith neu ofyn am eithriad VPN, rhowch y ddau gynllun cyfeiriad ochr yn ochr, oherwydd mae'r atgyweiriadau'n costio symiau amser gwahanol iawn.

Darllenwch y llwybr cyn newid y cyfluniad

Dechreuwch gyda'r rhwydwaith a adeiladodd Docker mewn gwirionedd. Bloc IPAM yw'r cynllun cyfeiriad, a'r is-rwydwaith yw'r llinell sy'n bwysig:

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

Mae Compose yn dyrannu /16 i bob prosiect newydd yn ddiofyn, felly gall dwy wasanaeth eistedd o fewn ystod o 65,536 cyfeiriad. Y lled hwnnw yw'r rheswm bod gorgyffwrdd yn gyffredin: mae /16 a ddewiswyd ar hap yn ddigon mawr i lyncu safle rydych chi'n ei gyrraedd drwy'r twnnel, ac nid oes neb yn sylwi nes bod y twnnel yn codi.

Yna cymharwch y dewis llwybr ar gyfer un cyfeiriad cynhwysydd, unwaith gyda'r twnnel i lawr ac unwaith gyda fe i fyny:

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

Mae dau siâp ateb yn arwain at leoedd gwahanol. Os yw'r allbwn yn enwi tun0, wg0 neu ddyfais twnnel arall, mae rhagddodiad VPN o leiaf mor benodol â llwybr y bont ac nid yw'r pecyn byth yn cyrraedd y cynhwysydd. Os yw'n dal i enwi'r bont, gall y gwesteiwr gyrraedd y cynhwysydd, a'ch nam yw hidlo, DNS, neu lwybr dychwelyd sy'n methu mewn un cyfeiriad yn unig.

Pam mae gwrthdrawiad /16 yn hawdd ei daro

Mae Docker yn tynnu rhwydweithiau pont o'r pyllau preifat, ac mae'r pwll diofyn yn dod o'r bloc 172.16.0.0/12 mewn tafelli /16. Mae rhwydweithiau corfforaethol yn aml yn defnyddio'r un gofod preifat, ac mae VPN mynediad o bell yn gwthio'r rhagddodiaid hynny at bob cleient sy'n cysylltu. Pan fydd y ddwy ochr yn credu eu bod yn berchen ar 172.18.0.0/16, mae un tabl llwybro yn dal dau haeriad gwrthgyferbyniol.

Hyd y rhagddodiad sy'n penderfynu'r enillydd, nid y drefn y mae llwybrau'n ymddangos ynddi. Nid yw twnnel sy'n gwthio 10.0.0.0/8 yn curo llwybr pont 172.18.0.0/16, oherwydd bod /8 yn llai penodol. Mae twnnel sy'n gwthio 172.18.0.0/16, neu 172.18.5.0/24 y tu mewn iddo, yn curo. Dyna pam mae un gliniadur yn gweithio ar rwydwaith y swyddfa ac yn methu ar Wi-Fi gwesty gyda'r un VPN: mae'r cleient yn derbyn rhagddodiaid gwahanol.

Mae'r un tabl yn llywodraethu'r cyfeiriad arall. Mae cynhwysydd sydd angen gwesteiwr mewnol yn 10.8.4.20 yn anfon y pecyn at ei borth bont, ac yna mae'r gwesteiwr yn ei lwybro i'r twnnel. Mae'r llwybr hwnnw'n gweithio fel arfer oherwydd bod y gwesteiwr yn gwneud y NAT, ond mae'n methu pan fo'r ochr gorfforaethol yn derbyn cyfeiriad VPN y gliniadur yn unig, neu pan fo hidlo llwybr cefn yn gollwng yr ateb anghymesur.

Cymharwch y tri atgyweiriad

Dim ond tri ffordd allan sydd, ac maent yn wahanol o ran pwy sy'n rhaid eu cymeradwyo a beth sy'n torri wrth i chi gymhwyso un.

Ail-rifo yw'r unig atgyweiriad y gallwch ei orffen heb docyn, a dyna pam mae'r rhan fwyaf o ysgrifau'n stopio yno. Mae'n rhad ar brosiect ifanc ac yn ddrud unwaith y bydd teclyn mudo neu linyn cysylltu wedi'i storio yn pwyntio at gyfeiriad llythrennol. Cyfrwch y cyfeiriadau hynny cyn i chi olygu YAML, nid ar ôl.

Eithriad o'r twnnel yw'r ateb glanaf pan fo'r gorgyffwrdd yn eistedd mewn ystod y mae eich cwmni'n berchen arni mewn gwirionedd. Dyma'r arafaf hefyd, ac mae'n ddiwerth i gontractor na all newid proffil y cleient. Mae porth cyhoeddedig neu wrthdroi-porthi bach yn osgoi'r ddadl: mae'r cleient yn siarad â chyfeiriad y mae'r twnnel eisoes yn ei lwybro'n gywir, a dim ond y porth hwnnw sydd angen bod yn gyrraeddadwy.

Pinwch ystod yn fwriadol

Ar gyfer un prosiect, datganwch yr is-rwydwaith yn y ffeil compose fel bod y prosiect yn stopio tynnu o'r pwll a rennir:

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

Cymerwch yr ystod honno o gofrestr y mae eich tîm yn ei chadw, nid o enghraifft a gawsoch wrth chwilio. Gwiriwch hi yn erbyn y rhagddodiaid y mae'r VPN yn eu gwthio, y LANau cartref y mae pobl yn gweithio ohonynt, a'r rhwydweithiau cynhwysydd eraill ar yr un gwesteiwr. Yna cynlluniwch yr ail-greu, oherwydd mae rhwydwaith sy'n bodoli'n cadw ei hen is-rwydwaith: docker compose down, yna up -d. docker network rm yn gwrthod tra bo pennau terfyn ynghlwm, a rhaid i unrhyw ipv4_address gofnod yn y ffeil syrthio o fewn yr ystod newydd.

Ar gyfer rhwydweithiau y mae Docker yn eu creu ei hun, gosodwch bwll daemon yn /etc/docker/daemon.json:

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

Mae'r pwll yn berthnasol i rwydweithiau a grëwyd ar ôl i'r daemon ailgychwyn, ac mae pontydd sy'n bodoli eisoes yn cadw eu cyfeiriadau. Mae hynny'n gyfleus ac yn hawdd i'w anghofio, felly triniwch brosiect hen fel un sy'n gorgyffwrdd o hyd nes i rywun ail-greu ei rwydwaith. Mae dogfennaeth Docker ar rwydweithio'r peiriant yn disgrifio'r rheolau dyrannu os oes angen i chi amddiffyn y pwll mewn adolygiad.

Mae pont Linux a Docker Desktop yn methu'n wahanol

Ar westeiwr Linux, mae cynwysyddion yn eistedd ar bontydd yn enw gofod y gwesteiwr. Mae un tabl yn penderfynu popeth, felly'r gymhariaeth uchod yw'r stori gyfan: darllenwch lwybr y bont, darllenwch lwybr y twnnel, a gwelwch pa un sy'n ennill ar gyfer cyfeiriad cynhwysydd go iawn.

Mae Docker Desktop yn rhoi cynwysyddion y tu ôl i VM gyda'i NAT ei hun. Nid oes gan y gwesteiwr unrhyw lwybr at gyfeiriad y cynhwysydd o gwbl; mae'n cyrraedd y gwasanaeth drwy borth cyhoeddedig, fel arfer wedi'i rwymo i 127.0.0.1. Gall cleient VPN felly dorri'r gwasanaeth heb unrhyw orgyffwrdd is-rwydwaith, naill ai drwy osod llwybr ar gyfer ystod fewnol y VM neu drwy rwystro traffig loopback tra bo'r twnnel yn gysylltiedig. Os yw ip route get ar y gwesteiwr yn adrodd nad oes llwybr ar gyfer cyfeiriad y cynhwysydd, mae hynny'n ddisgwyliedig yn hytrach na'r nam.

Y canlyniad ymarferol yw ble rydych chi'n edrych gyntaf. Ar Linux, dechreuwch at y tabl llwybro. Ar Desktop, dechreuwch at y porth cyhoeddedig a rheolau wal dân y cleient VPN, yna gwiriwch a yw is-rwydwaith mewnol y VM yn gwrthdaro â rhywbeth y mae'r twnnel yn ei wthio.

Gwiriwch gyda'r twnnel i fyny

Ailgysylltwch y VPN ddwywaith cyn dweud bod hyn wedi'i drwsio, oherwydd gall proffil sy'n gwthio llwybrau wrth gysylltu ac yn eu tynnu'n ôl wrth ddatgysylltu edrych yn gywir ar ôl yr ymgais gyntaf. Yna rhedwch y gwiriadau y mae'r cleient yn eu rhedeg mewn gwirionedd:

1. ip route get o'r gwesteiwr, gan ddefnyddio cyfeiriad go iawn y cynhwysydd.
2. Cais o gynhwysydd arall, i brofi bod y gwasanaeth ei hun yn iach.
3. curl -sv http://127.0.0.1:8080/ o'r cleient gyda'r twnnel i fyny, yna traceroute -n at gyfeiriad y cynhwysydd o beiriant ar y LAN.
4. sysctl net.ipv4.conf.all.rp_filter os yw'r cais yn cyrraedd y gwesteiwr ond mae'r ateb yn diflannu.

Yn olaf, ysgrifennwch yr ystod a ddewiswyd yn yr un gofrestr a ddefnyddiwyd gennych i'w dewis, gyda'r dyddiad a'r prosiect sy'n berchen arni. Daw'r gorgyffwrdd nesaf o brosiect na chofnododd neb, a'r unig amddiffyniad yw bod yr ystod wedi'i chadw'n fwriadol yn hytrach na'i thynnu ar hap.