Docker-en portuen argitalpena eta VPN-a: erantzuna nora doan

Argitaratutako edukiontzi bat bere helbidetik erantzuten du NAT alderantzizkoa baino lehen. Bi diseinuk erantzun hori bide publikoan mantendu dezakete, kostu ezberdinekin.

Ostalariak SSH-ri erantzuten jarraitzen du tunel osoaren VPN bat altxatu ondoren, baina makina berean Docker bidez argitaratutako zerbitzu bat isildu egiten da. Entzulearekin ez dago ezer gaizki: edukiontzia martxan dago, portu-mapaketa badago eta paketea iristen da. Edukiontzia osasuntsu dago eta eskaerak benetan lortzen du. Desberdintasuna erantzuna nondik hasten den da Linuxek bere bidea aukeratzen duenean, eta desberdintasun horrek erabakitzen du beheko bi diseinuetatik zein behar duzun.

Jarraitu tuplea helmugako NAT bidez

Hartu ostalari bat 192.0.2.10 helbidean, TCP 2222 172.30.240.5:22 helbideko edukiontzi batera argitaratzen duena. 198.51.100.25 helbidetik datorren eskaera edukiontzira iritsi baino lehen itzultzen da, eta edukiontziak bere buru gisa erantzuten du.

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

Ostalariaren bide-erabakian erantzunak edukiontziaren jatorrizko helbidea darama oraindik. Itzulpen alderantzizkoak argitaratutako tuplea berrezartzen du geroago, eta horregatik paketea oker ikusten da bidea aukeratzen den une zehatzean.

Zergatik uzten duen ostalariarentzako soilik den erregela batek

WAN taula 192.0.2.10 helbidetik datozen paketeetarako soilik aukeratzen duen erregela batek ostalariaren beraren daemonak estaltzen ditu eta aurreratutako erantzun hau erabat saltatzen du. Erantzunaren jatorrizko helbidea 172.30.240.5 da, ez ostalaria.

Gehiegizko zuzenketa edukiontziko guztia WAN bidez bideratzea da, eta horrek edukiontziaren erlazionik gabeko irteerako konexioak VPN-tik salbuetsi ere egiten ditu. Eskatu zaizun politikaren desberdina da, eta normalean norbaiti sorpresa ematen dio geroago.

DNAT osteko parekatzea beste hook bat da

Docker-en suebaki buruzko dokumentazioak ohartarazten du erabiltzaile-iragazketa arruntak DNAT osteko helmuga ikusten duela, beraz argitaratutako 2222 portua erregela arrunt batean parekatzea ez da gauza bera edukiontziaren 22 portua parekatzea. Jatorrizko tuplea garrantzitsua bada, erabili onartutako jatorrizko helmugaren mekanismoa zein portu den ikusgai asmatu beharrean.

Hook nahaste honek zuzenak diruditen eta inoiz bat egiten ez duten erregelak sortzen ditu. Berrikusi erregelaren beraren kontagailuak politika berridatzi aurretik. Zero kolpekadun erregela batek esaten dizu paketea inoiz iristen ez den lekuan ebaluatzen ari dela.

Diseinua A: eraman erabakia konexio-egoera gisa

Konexio-marka batek sarrerako erabakia itzulpenaren bidez eraman dezake, baina garrantzitsua den bide-kontsultaren aurretik paketera berrezarri behar da. Etapak hauek dira:

  1. Erreserbatu Docker-ekin, VPN-arekin edo beste politika-jabe batekin talka egiten ez duen marka-eremu eta erregela-lehentasun bat.
  2. Identifikatu WAN konexio berri nahi dena soilik DNAT aurreko puntu batean, konexioen jarraipena eskuragarri dagoenean.
  3. Erregistratu erabakia konexio-markan, jatorrizko eskaera bera WAN taulara behartu gabe.
  4. Erantzun-norabidean, berrezarri zure marka-bitoak soilik paketera bideratzearen aurretik.
  5. Aukeratu WAN taula oso bat behar bezain goiz, VPN erregela batek lehenengo irabazi ez dezan.

Taula horrek benetako konektatutako bideak eta atebidea behar ditu. Bidea falta denean definitutako portaera bat ere behar du. Tunelera isilki erortzea da emaitzarik okerrena, konfigurazioak oraindik funtzionatzen duela ematen duelako. Horren ordez, huts egin itxita eta erregistratu.

Diseinua B: amaitu ostalarian

Ostalariaren aldean nahita konfiguratutako frontend batek, adibidez TCP proxy batek edo edukiontziaren aurrean alderantzizko proxy batek, erantzuna ostalariaren helbidetik sortzen mantentzen du. Orduan ostalariarentzat idatzitako erregelak espero bezala jokatzen dute, eta edukiontzia bere sare pribatuan geratzen da.

Kostua konfigurazio propioa, jatorrizko helbideen kudeaketa eta sarbide-kontrolak dituen beste pieza mugikor bat da. Normalean onartutako muga errazagoa da, eta askotan erantzun zuzena da bideratze-politika agian joango litzatekeen pertsona batek mantenduko balu.

Egiaztatu aldaketa, ez asmoa

Ireki konexio baimendu berri bat alde publikotik eta egiaztatu erantzuna aurreikusitako interfazetik irteten dela. Gero egiaztatu edukiontziak hasitako erlazionik gabeko eskaera batek VPN-a jarraitzen duela.

Ez hustu makinaren konexio-taula erregela bat probatzeko: lehendik dauden sarrerek beren aurreko mapaketa gordetzen dute, eta hustuketak ostalariaren beste guztia apurtzen du. Portu bat argitaratzeak irisgarritasuna definitzen du. Ez du erantzunaren bidea definitzen. Idatzi aukeratutako diseinua bere taula-izenekin, hurrengo pertsonak intzidente batean berriro aurkitu behar ez dezan.

Erlazionatutako artikuluak