Docker-ujo neatingebla per VPN? Komparu la subretojn

Ujoj respondas en la oficeja LAN, poste ĉesas respondi en la momento, kiam la firmaa VPN konektiĝas. Nenio en la ujo ŝanĝiĝis: neniu restartigo, neniu bilda ĝisdatigo, neniu agorda redakto. Kio ŝanĝiĝis estas la enkursiga tabelo de la gastiganto, kie itinero aldonita de la tunelo nun kovras la adreson, kiun Docker donis. Antaŭ ol vi redaktos subreton aŭ petos VPN-escepton, metu ambaŭ adresplanojn unu apud la alia, ĉar la riparoj kostas tre malsamajn kvantojn da tempo.

Legu la itinerojn antaŭ ol ŝanĝi la agordon

Komencu per la reto, kiun Docker efektive konstruis. La IPAM-bloko estas la adresplano, kaj la subreto estas la linio, kiu gravas:

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

Compose asignas defaŭlte /16 al ĉiu nova projekto, do du servoj povas sidi ene de gamo de 65,536 adresoj. Ĝuste tiu larĝo kaŭzas oftajn koincidojn: hazarde elektita /16 estas sufiĉe granda por engluti retejon, kiun vi atingas tra la tunelo, kaj neniu rimarkas ĝin ĝis la tunelo ekfunkcias.

Poste komparu la itineran elekton por unu uja adreso, unufoje kun mallevita tunelo kaj unufoje kun levita:

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

Du formoj de respondo kondukas al malsamaj lokoj. Se la eligo nomas tun0, wg0 aŭ alian tunelan aparaton, VPN-prefikso estas almenaŭ same specifa kiel la ponta itinero kaj la pako neniam atingas la ujon. Se ĝi ankoraŭ nomas la ponton, la gastiganto povas atingi la ujon, kaj via misfunkcio estas filtrado, DNS aŭ revena vojo, kiu malsukcesas nur en unu direkto.

Kial kolizio de /16 estas facile trafa

Docker prenas pontajn retojn el la privataj naĝejoj, kaj la defaŭlta naĝejo venas el la bloko 172.16.0.0/12 en /16-tranĉaĵoj. Entreprenaj retoj ofte uzas la saman privatan spacon, kaj fora alira VPN puŝas tiujn prefiksojn al ĉiu konektiĝanta kliento. Kiam ambaŭ flankoj kredas, ke ili posedas 172.18.0.0/16, unu enkursiga tabelo tenas du kontraŭajn asertojn.

La longo de la prefikso decidas la venkanton, ne la ordo, en kiu itineroj aperas. Tunelo, kiu puŝas 10.0.0.0/8 ne venkas pontan itineron 172.18.0.0/16, ĉar /8 estas malpli specifa. Tunelo, kiu puŝas 172.18.0.0/16, aŭ 172.18.5.0/24 interne de ĝi, venkas. Tial unu tekkomputilo funkcias en la oficeja reto kaj malsukcesas en hotelaj Wi-Fi kun la sama VPN: la kliento ricevas malsamajn prefiksojn.

La sama tabelo regas la alian direkton. Ujo, kiu bezonas internan gastiganton ĉe 10.8.4.20 sendas la pakon al sia ponta kluzo, kaj la gastiganto tiam enkursigas ĝin en la tunelon. Tiu vojo kutime funkcias, ĉar la gastiganto faras la NAT, sed ĝi malsukcesas, kiam la entreprena flanko akceptas nur la VPN-adreson de la tekkomputilo, aŭ kiam inversvoja filtrado forĵetas la nesimetrian respondon.

Komparu la tri riparojn

Estas nur tri eliroj, kaj ili diferencas en tio, kiu devas aprobi ilin kaj kio rompiĝas dum vi aplikas unu.

Renombrado estas la sola riparo, kiun vi povas fini sen bileto, kaj tial plej multaj skribaĵoj haltas tie. Ĝi estas malmultekosta en juna projekto kaj multekosta, kiam migrada ilo aŭ konservita konekta ĉeno montras al laŭvorta adreso. Kalkulu tiujn referencojn antaŭ ol redakti YAML, ne poste.

Escepto el la tunelo estas la plej pura respondo, kiam la koincido kuŝas en gamo, kiun via firmao vere posedas. Ĝi ankaŭ estas la plej malrapida kaj senutila por subkontraktanto, kiu ne povas ŝanĝi la klientan profilon. Publikigita pordo aŭ malgranda inversa prokura servilo evitas la disputon: la kliento parolas kun adreso, kiun la tunelo jam enkursigas ĝuste, kaj nur tiu pordo devas esti atingebla.

Fiksu gamon intence

Por unu projekto, deklaru la subreton en la compose-dosiero, por ke la projekto ĉesu preni el la komuna naĝejo:

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

Prenu tiun gamon el registro, kiun tenas via teamo, ne el ekzemplo, kiun vi trovis serĉante. Kontrolu ĝin kontraŭ la prefiksoj, kiujn la VPN puŝas, la hejmaj LAN-oj, de kiuj homoj laboras, kaj la aliaj ujaj retoj sur la sama gastiganto. Poste planu la rekreadon, ĉar ekzistanta reto konservas sian malnovan subreton: docker compose down, poste up -d. docker network rm rifuzas dum finpunktoj estas alkroĉitaj, kaj ĉiu ipv4_address ero en la dosiero devas fali ene de la nova gamo.

Por retoj, kiujn Docker mem kreas, agordu naĝejon de demono en /etc/docker/daemon.json:

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

La naĝejo validas por retoj kreitaj post restartigo de la demono, kaj pontoj, kiuj jam ekzistas, konservas siajn adresojn. Tio estas oportuna kaj facila forgesi, do traktu malnovan projekton kiel ankoraŭ koincidan ĝis iu rekreas ĝian reton. La dokumentaro de Docker pri retumado de la motoro priskribas la asignajn regulojn, se vi devas defendi la naĝejon en revizio.

La ponto de Linux kaj Docker Desktop malsukcesas malsame

Sur Linuksa gastiganto, ujoj sidas sur pontoj en la nomspaco de la gastiganto. Unu tabelo decidas ĉion, do la supra komparo estas la tuta historio: legu la pontan itineron, legu la tunelan itineron, kaj vidu, kiu venkas por reala uja adreso.

Docker Desktop metas ujojn malantaŭ VM kun propra NAT. La gastiganto tute ne havas itineron al la uja adreso; ĝi atingas la servon tra publikigita pordo, kutime ligita al 127.0.0.1. VPN-kliento povas do rompi la servon sen iu ajn subreta koincido, ĉu instalante itineron por la interna gamo de la VM, ĉu blokante loopback-trafikon dum la tunelo estas konektita. Se ip route get sur la gastiganto raportas, ke ne estas itinero por la uja adreso, tio estas atendata kaj ne la fuŝaĵo.

La praktika sekvo estas, kie vi unue rigardas. Sur Linux, komencu ĉe la enkursiga tabelo. Sur Desktop, komencu ĉe la publikigita pordo kaj la fajroŝirmilaj reguloj de la VPN-kliento, poste kontrolu, ĉu la interna subreto de la VM kolizias kun io, kion la tunelo puŝas.

Kontrolu kun la tunelo levita

Rekonektu la VPN dufoje antaŭ ol nomi ĝin riparita, ĉar profilo, kiu puŝas itinerojn ĉe konekto kaj forprenas ilin ĉe malkonekto, povas aspekti ĝusta post la unua provo. Poste rulu la kontrolojn, kiujn la kliento efektive rulas:

1. ip route get de la gastiganto, uzante la realan adreson de la ujo.
2. Peto el alia ujo, por pruvi, ke la servo mem estas sana.
3. curl -sv http://127.0.0.1:8080/ de la kliento kun la tunelo levita, poste traceroute -n al la uja adreso el maŝino en la LAN.
4. sysctl net.ipv4.conf.all.rp_filter se la peto atingas la gastiganton sed la respondo malaperas.

Fine, skribu la elektitan gamon en la saman registron, kiun vi uzis por elekti ĝin, kun la dato kaj la projekto, kiu posedas ĝin. La sekva koincido venos de projekto, kiun neniu dokumentis, kaj la sola defendo estas, ke la gamo estis rezervita intence anstataŭ hazarde prenita.