Kial via Docker VPN-porda mapado neniam atingas OpenVPN

Via ujo povas aŭskulti sur UDP 1195 dum la gastigo publikigas 1194, kaj tio estas ĝusta se la mapado tion diras. La numeroj formas traduktabelon: la kliento vokas la gastigan pordon, Docker reverkas la celon al la uja pordo, kaj OpenVPN respondas sur la pordo, kiun nomas ĝia propra agordo. Miskongruo en iu ajn el tiuj ligiloj produktas silentan fiaskon, kiu aspektas kiel fajroŝirmilo. Atestiloj kaj ĉifroj troviĝas poste kaj ne povas ripari ĝin.

Sekvu unu paketon de la kliento ĝis la procezo antaŭ ol ŝanĝi ion pri aŭtentigo.

Tri numeroj, unu konekto

La tri numeroj estas la fora celo, kiun la kliento uzas, la publikigita mapado sur la gastigo, kaj la aŭskultanto ene de la ujo. Ili ne devas esti egalaj, sed ili devas formi ĉenon. Egalaj numeroj estas speciala kazo, kiu hazarde estas la plej ofta, kaj tial miskongruo facile skribiĝas unufoje kaj malfacile videblas poste.

Skribu la ĉenon en unu linio antaŭ sencimigado: klienta adreso kaj pordo, gastiga mapado, uja aŭskultanto, transporto. Difekto en la ĉeno montriĝas kiel numero, kiu aperas dufoje kun malsamaj valoroj.

Kion la mallonga sintakso vere diras

En la mallonga formo la maldekstra flanko estas la gastiga pordo kaj la dekstra estas la uja pordo, kaj oblikva sufikso elektas la transporton. Se vi forlasas la sufikson, Docker traktas la mapadon kiel TCP, do UDP-aŭskultanto malantaŭ mapado sen protokolo estas aŭskultanto, kiun neniu povas atingi. Tiu defaŭlto estas dokumentita kaj ankoraŭ surprizas homojn, kiuj kongruigis la numerojn kaj konsideris la aferon finita.

La longa formo eksplicite fiksas la ligadreson kaj la protokolon, kio valoras la pliajn liniojn por io ajn turnita al reto. Legu la publikigitan mapadon returne anstataŭ fidi la dosieron, kiu ĝin kreis.

ports:
  - 1194:1195/udp

Kie la paketo povas halti

Peto povas esti forĵetita antaŭ Docker, en Docker aŭ ĉe la aŭskultanto. Antaŭ Docker povas esti nuba fajroŝirmilo aŭ enkursigilo, kiu mem plusendas, kaj tiu aparato bezonas la gastigan pordon kaj la ĝustan transporton. Ene de Docker, mapado al malĝusta uja pordo plusendas al fermita ingo.

Poste la aŭskultanto: la agordo de OpenVPN nomas pordon kaj protokolon, kaj kliento, kiu alvenas al alia pordo ene de la ujo, atingas nenion. TCP-testado de UDP-servo pruvas nenion ĉe iu ajn el tiuj etapoj, do uzu la transporton, kiun la kliento uzos.

Ligadresoj decidas atingeblon

Publikigita mapado ligita al loopback estas atingebla nur de la gastigo, dum unu ligita al ĉiuj interfacoj estas atingebla kie ajn la fajroŝirmilo permesas. Ambaŭ aspektas identaj en Compose-dosiero, kiu forlasas la adreson, kaj la defaŭlto de Docker estas la larĝa.

Decidu, kiun elmeton la deplojo celas, poste skribu ĝin eksplicite. Interna testo, kiu konektiĝas tra loopback, kaj fora kliento, kiu ne povas konektiĝi, povas ambaŭ esti precizaj priskriboj de la sama ujo.

Legu la kurantan staton

Kontrolu la efektivan mapadon de la kuranta ujo kaj la aŭskultanton en ĝia reta nomspaco. Compose-dosiero eble estis redaktita post la starto de la ujo, bilda metadateno eble deklaras pordon sen publikigi ĝin, kaj dua ujo eble jam tenas la gastigan pordon. Deklari pordon en bildo ne estas publikigi ĝin, kaj nek unu nek la alia samas al aŭskulti.

Tri malsamaj statoj, tri malsamaj komandoj, kaj nur la lasta koncernas OpenVPN.

Post kiam la mapado estas ĝusta

Post kiam la paketo atingas OpenVPN, ĝia protokolo estas la loko por legi pri TLS kaj aŭtentigo. Regeneri atestilojn por ripari paketon, kiu neniam alvenis, estas perdita laboro, kiu aldonas duan variablon. Tenu la mapadan noton apud la klienta profilo, por ke la sekva persono legu unu linion anstataŭ remalkovri ĉiujn tri numerojn. Unu paketa kapto ĉe la gastiga flanko solvas, kiu el la tri ligiloj maltrafas, kaj ĝi kostas malpli ol atestila regenerado.

Ponto-publikigo estas la kazo priskribita ĉi tie. Gastiga retado kaj enkursigataj ujaj adresoj preterlasas la tradukon, do la samaj numeroj signifas ion alian en tiuj dezajnoj.