Docker: trairigu unu ujon tra VPN kaj lasu alian rekte

Unu gastiganto, du laborŝarĝoj kaj postulo, kiu disigas ilin: kliento por elŝutado, kiu devas eliri tra komerca VPN, kaj administra fasado, kiu devas daŭre uzi la konekton de la gastiganto. Instali la VPN-klienton sur la gastiganto tuj malplenumigas la postulon, ĉar tiam ambaŭ laborŝarĝoj kunhavas unu eliron. La ŝablono, kiu vere funkcias, estas movi la tunelon en ĝian propran ujon kaj lasi nur la laborŝarĝojn, kiuj bezonas ĝin, aliĝi al la reta nomspaco de tiu ujo. Ĉio alia tenas la kutiman Docker-vojon, kaj la detaloj, kiuj sekvas, estas konsekvencoj de tio, kiu posedas la nomspacon.

Kial kunhava nomspaco ŝanĝas la regulojn

Ujo, kiu aliĝas al la nomspaco de alia, ne ricevas propran retan stakon. Ĝi vidas la samajn interfacojn, la saman enkursigan tabelon kaj la saman loopback kiel la ujo, al kiu ĝi aliĝis, kaj ĝuste tial la ŝablono utilas: la laborŝarĝo solvas kaj konektiĝas normale, kaj la tunelo sube kaptas la trafikon sen ke la aplikaĵo sciu. La kosto estas, ke ĉiu reta agordo nun havas unu posedanton, kaj la aliĝanta ujo ne estas tiu.

Tiu posedregulo respondas al la plej multaj agordaj demandoj antaŭ ol ili estas starigitaj. Se agordo vivas en la reta stako, ĝi apartenas al la flanka ujo. Se ĝi priskribas la procezon, ĝi restas ĉe la laborŝarĝo.

Loopback estas la parto, kiu surprizas homojn. Ene de la aliĝanta ujo, localhost solviĝas al la loopback de la flanka ujo, ne al propra privata, do servo, kiu ligiĝas al 127.0.0.1 esperante izolitecon, nun kunhavas tiun adreson kun la tunela ujo.

Publikigu pordojn sur la ujo, kiu posedas la nomspacon

La porda mapado apartenas al la posedanto de la nomspaco eĉ kiam la aŭskultanta procezo ruliĝas en la alia ujo. Deklaru la mapadon sur la flanka ujo, kaj lasu la laborŝarĝon teni sian propran procesan agordon netuŝita. Mapado sur la aliĝanta servo ne povas efektiviĝi, ĉu la motoro rifuzas ĝin ĉu ĝi silente ignoras ĝin laŭ tio, kiel la ujo estas startigita, kaj tial interfaco, kiu estis atingebla antaŭ momento, malaperas tuj kiam la ŝablono aplikiĝas.

services:
  gluetun:
    image: qmcgaw/gluetun
    cap_add: [NET_ADMIN]
    ports: ["8080:8080"]
  client-vpn:
    image: example/client
    network_mode: "service:gluetun"
  client-direct:
    image: example/client
    ports: ["8081:8080"]

Legu tiun blokon kiel tri decidojn, ne kiel tri servojn. La flanka ujo posedas la tunelon kaj la publikigitan pordon; la aliĝanta kliento deklaras tute neniun reton; la rekta kliento tenas propran mapadon sur la implicita reto. La kapablo NET_ADMIN estas tio, kio ebligas al la flanka ujo krei interfacojn kaj ŝanĝi enkursigojn, kaj ĝi estas la kialo, ke ĉi tiu ujo bezonas pli da privilegioj ol la laborŝarĝoj, kiujn ĝi servas.

La servo, kiu restas rekta, tenas sian propran reton

La laborŝarĝo, kiu ne rajtas iri tra la tunelo, tenas la implicitan ponton aŭ propran uzant-difinitan reton, kun propra publikigita pordo kaj propra eliro. Estas tentate ligi ĝin al la reto de la flanka ujo, por ke la du ujoj povu paroli laŭ nomo, sed tiu sola paŝo silente movas ĝian trafikon en la tunelon. Se ili devas atingi unu la alian, konstruu apartan uzant-difinitan reton, ligi ambaŭ al ĝi kaj lasu la flankan ujon la sola vojo eksteren.

Tenu la du demandojn aparte: kiuj ujoj povas atingi unu la alian, kaj kiu eliras kien. Kunfandi ilin estas la plej ofta maniero, per kiu ĉi tiu dezajno denove fariĝas VPN por la tuta gastiganto.

Matrico de malsukcesoj por la unua horo

La plej multaj unuaj provoj malsukcesas en unu el kvar manieroj, kaj ĉiu havas alian kaŭzon. Kontrolu ilin laŭ ĉi tiu ordo, ĉar la unuaj du klarigas preskaŭ ĉiun raporton.

La kvara vico estas tiu, kiun homoj misdiagnozas kiel aplikaĵan cimon. Sondilo skribita kontraŭ la propra loopback de la laborŝarĝo nun testas la tunelan ujon, do ĝi aŭ malsukcesas aŭ raportas tute malĝustan servon.

Kiam unu sola gastigantnomo bezonas la tunelon

Kelkfoje plena tunelo estas tro: unu interna nomo devas iri tra kompania VPN dum loka ingo aŭ ekrana konekto daŭre funkcias. Plena tunelo ene de la ujo rompas tiun vojon kaj ĉion adresitan al la gastiganto, do enkursigu nur la prefikson, kiu bezonas ĝin. Dividita enkursiga envolvaĵo ĉirkaŭ la kliento faras tion, sendante la nomatan gastiganton tra la tunelo kaj lasante la antaŭan enkursigon netuŝita por ĉio alia.

Elektu ĉi tion, kiam vi bezonas atingi nur unu servon kaj ne provas movi la tutan trafikon de la ujo. Ĝi estas alia ilo ol la flanka ujo kaj respondas al alia demando.

Kontrolu, poste faru ĝin postviva al restarto

Demandu ĉiun ujon, de kiu adreso ĝi ŝajnas veni. La tunela devus presi la adreson de la provizanto kaj la rekta la eliron de la gastiganto. Identaj respondoj signifas, ke la rekta servo heredis la malĝustan nomspacon aŭ ke VPN ĉe gastiganta nivelo ankoraŭ kaptas ĉion, kaj tiuj du riparoj estas malsamaj. Rerunu la kontrolon post ĉiu compose-redakto, ĉar unu kopiita serva bloko sufiĉas por reenkonduki la problemon.

Tri aferoj emas rompiĝi poste. DNS sekvas la posedanton de la nomspaco, do agordoj de solvilo kaj serĉa domajno apartenas al la flanka ujo anstataŭ al la gastiganto. VPN kun porda plusendado ŝanĝas sian aŭskultantan pordon ĉe rekonekto, do la plusendita pordo de la provizanto kaj la aŭskultanta pordo ĉe la uja flanko devas esti reskribitaj en la klientan agordon aŭ en la pordan mapadon, kutime per malgranda ĝisdatigilo, kiu legas la API de la provizanto. Kaj ĉiu sondilo skribita kontraŭ localhost nun demandas la tunelan ujon anstataŭ la laborŝarĝon.

Skribu la ŝablonon, inkluzive de tio, kiu ujo posedas la nomspacon kaj kiuj pordoj apartenas al ĝi. La sekva persono aldonos servon, kopios la malĝustan blokon kaj reproduktos la unuan malsukceson en ĉi tiu artikolo.