Publikigo de Docker-pordoj kontraŭ la VPN: kien iras la respondo

Publikigita ujo respondas el sia propra adreso antaŭ la inversa NAT. Du dezajnoj povas teni tiun respondon sur la publika vojo, kun malsamaj kostoj.

La gastiganto daŭre respondas al SSH post kiam VPN kun plena tunelo ekfunkcias, dum Docker-publikigita servo sur la sama maŝino silentas. La aŭskultanto estas en ordo: la ujo funkcias, la pordomapado ekzistas, kaj la paketo alvenas. La ujo estas sana kaj la peto ja atingas ĝin. La diferenco estas, de kie la respondo komenciĝas kiam Linux elektas sian itineron, kaj tiu diferenco decidas, kiun el la du subaj dezajnoj vi bezonas.

Sekvu la opon tra la cela NAT

Prenu gastiganton ĉe 192.0.2.10, kiu publikigas TCP 2222 al ujo ĉe 172.30.240.5:22. Peto de 198.51.100.25 estas tradukata antaŭ ol ĝi atingas la ujon, kaj la ujo respondas kiel si mem.

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

Ĉe la itinera decido de la gastiganto la respondo ankoraŭ portas la fontadreson de la ujo. La inversa traduko restarigas la publikigitan opon poste, kaj tial la paketo aspektas malĝusta ĝuste en la momento, kiam la itinero estas elektata.

Kial regulo nur por la gastiganto maltrafas ĝin

Regulo, kiu elektas la WAN-tabelon nur por paketoj de 192.0.2.10 kovras la proprajn demonojn de la gastiganto kaj tute maltrafas ĉi tiun plusenditan respondon. La fontadreso de la respondo estas 172.30.240.5, ne la gastiganto.

La troa korekto estas enkursigi ĉion el la ujo tra la WAN, kio ankaŭ liberigas la ne rilatajn elirantajn konektojn de la ujo de la VPN. Tio estas alia politiko ol la petita, kaj ĝi kutime surprizas iun poste.

Post-DNAT kongruado estas alia hoko

La dokumentaro de Docker pri fajroŝirmiloj rimarkigas, ke ordinara uzantofiltrado vidas la celon post DNAT, do kongruigi la publikigitan pordon 2222 en normala regulo ne samas kiel kongruigi la ujon-pordon 22. Se la origina opo gravas, uzu la subtenatan mekanismon de origina celo anstataŭ diveni, kiu pordo videblas.

Ĉi tiu hoka konfuzo produktas regulojn, kiuj aspektas ĝustaj kaj neniam kongruas. Kontrolu la nombrilojn sur la regulo mem antaŭ ol reverki la politikon. Regulo kun nula trafo diras al vi, ke ĝi estas taksata ie, kien la paketo neniam alvenas.

Dezajno A: porti la decidon kiel konektan staton

Konekta marko povas porti la enigan decidon tra la traduko, sed ĝi devas esti restarigita al la paketo antaŭ la itinera serĉo, kiu gravas. La etapoj estas:

  1. Rezervu markokampon kaj regulan prioritaton, kiuj ne kolizias kun Docker, la VPN aŭ alia politika posedanto.
  2. Identigu nur la celatan novan WAN-konekton ĉe punkto antaŭ DNAT, kie konekta spurado haveblas.
  3. Registru la decidon sur la konektan markon, sen trudi la originan peton mem al la WAN-tabelo.
  4. En la responda direkto restarigu nur viajn proprajn markobitojn al la paketo antaŭ ol enkursigi.
  5. Elektu kompletan WAN-tabelon sufiĉe frue, ke VPN-regulo ne povu venki unue.

Tiu tabelo bezonas la realajn konektitajn itinerojn kaj la kluzon. Ĝi ankaŭ bezonas difinitan konduton, kiam la itinero mankas. Silenta defalo en la tunelon estas la plej malbona rezulto, ĉar la agordo ankoraŭ aspektas funkcia. Anstataŭe fiasku fermite kaj registru ĝin.

Dezajno B: fini sur la gastiganto

Intence agordita frontaĵo ĉe la gastiganta flanko, ekzemple TCP-prokurilo aŭ inversa prokurilo antaŭ la ujo, tenas la respondon devenantan de la gastiganta adreso. Reguloj skribitaj por la gastiganto tiam kondutas kiel atendite, kaj la ujo restas sur sia privata reto.

La kosto estas plia moviĝanta parto kun sia propra agordo, fontadresa traktado kaj alirkontroloj. Ĝi kutime estas la pli simpla subtenata limo, kaj ĝi ofte estas la ĝusta respondo, kiam la enkursiga politiko estus prizorgata de unu persono, kiu eble foriros.

Kontrolu la ŝanĝon, ne la intencon

Malfermu novan rajtigitan konekton de la publika flanko kaj konfirmu, ke la respondo forlasas la celatan interfacon. Poste kontrolu, ke ne rilata peto iniciatita de la ujo ankoraŭ sekvas la VPN.

Ne malplenigu la konektan tabelon de la maŝino por testi unu regulon: ekzistantaj eroj konservas sian pli fruan mapadon, kaj la malplenigo rompas ĉion alian sur la gastiganto. Publikigi pordon difinas atingeblon. Ĝi ne difinas la respondan vojon. Skribu la elektitan dezajnon kun ĝiaj tabelnomoj, por ke la sekva persono ne remalkovru ĝin dum incidento.

Rilataj artikoloj