Dockerin porttien julkaisu vastaan VPN: mihin vastaus menee

Julkaistu kontti vastaa omasta osoitteestaan ennen käänteistä NAT:ia. Kaksi ratkaisua voi pitää vastauksen julkisella polulla, eri kustannuksin.

Isäntä vastaa edelleen SSH:hon, kun täystunnelin VPN nousee, mutta samalla koneella Dockerin kautta julkaistu palvelu vaikenee. Kuuntelijassa ei ole vikaa: kontti on käynnissä, portin kartoitus on olemassa ja paketti saapuu. Kontti on terve ja pyyntö todella tavoittaa sen. Ero on siinä, mistä vastaus alkaa, kun Linux valitsee reittinsä, ja tämä ero ratkaisee, kumman kahdesta alla olevasta ratkaisusta tarvitset.

Seuraa tuplea kohde-NAT:in läpi

Ota isäntä osoitteessa 192.0.2.10, joka julkaisee TCP 2222:n kontille osoitteessa 172.30.240.5:22. Pyyntö osoitteesta 198.51.100.25 käännetään ennen kuin se saavuttaa kontin, ja kontti vastaa omana itsenään.

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

Isännän reittipäätöksessä vastaus kantaa vielä kontin lähdeosoitetta. Käänteinen käännös palauttaa julkaistun tuplen myöhemmin, ja siksi paketti näyttää väärältä juuri sillä hetkellä, kun reitti valitaan.

Miksi vain isäntää koskeva sääntö ei tavoita sitä

Sääntö, joka valitsee WAN-taulun vain paketeille osoitteesta 192.0.2.10, kattaa isännän omat daemonit ja ohittaa tämän edelleen välitetyn vastauksen kokonaan. Vastauksen lähdeosoite on 172.30.240.5, ei isäntä.

Ylikorjaus on reitittää kaikki kontista WAN:in kautta, mikä myös vapauttaa kontin riippumattomat lähtevät yhteydet VPN:stä. Se on eri käytäntö kuin pyydetty, ja se yllättää yleensä jonkun myöhemmin.

DNAT:n jälkeinen täsmäytys on eri hook

Dockerin dokumentaatio palomuureista huomauttaa, että tavallinen käyttäjäsuodatus näkee kohteen DNAT:n jälkeen, joten julkaistun portin 2222 täsmäyttäminen normaalissa säännössä ei ole sama kuin kontin portin 22 täsmäyttäminen. Jos alkuperäinen tuple on tärkeä, käytä tuettua alkuperäisen kohteen mekanismia sen sijaan, että arvaisit, mikä portti on näkyvissä.

Tämä hook-sekaannus tuottaa sääntöjä, jotka näyttävät oikeilta eivätkä koskaan täsmää. Tarkista laskurit itse säännöstä ennen käytännön uudelleenkirjoittamista. Sääntö, jolla ei ole yhtään osumaa, kertoo sinulle, että sitä arvioidaan paikassa, johon paketti ei koskaan saavu.

Ratkaisu A: kanna päätös yhteyden tilana

Yhteyden merkintä voi kantaa saapumispäätöksen käännöksen läpi, mutta se on palautettava pakettiin ennen sitä reittihakua, jolla on merkitystä. Vaiheet ovat:

  1. Varaa merkintäkenttä ja säännön prioriteetti, jotka eivät törmää Dockerin, VPN:n tai muun käytännön omistajan kanssa.
  2. Tunnista vain aiottu uusi WAN-yhteys pisteessä ennen DNAT:ia, jossa yhteyksien seuranta on käytettävissä.
  3. Kirjaa päätös yhteyden merkintään pakottamatta alkuperäistä pyyntöä itseään WAN-tauluun.
  4. Vastaussuunnassa palauta pakettiin vain omat merkintäbittisi ennen reititystä.
  5. Valitse täydellinen WAN-taulu tarpeeksi aikaisin, jotta VPN-sääntö ei voi voittaa ensin.

Taulu tarvitsee todelliset yhdistetyt reitit ja yhdyskäytävän. Se tarvitsee myös määritellyn toiminnan, kun reitti puuttuu. Hiljainen putoaminen tunneliin on huonoin lopputulos, koska kokoonpano näyttää edelleen toimivalta. Epäonnistu sen sijaan suljetusti ja kirjaa se.

Ratkaisu B: päätä isännällä

Tarkoituksella määritetty isännän puolen frontend, kuten TCP-välityspalvelin tai käänteinen välityspalvelin kontin edessä, pitää vastauksen isännän osoitteesta lähtevänä. Isännälle kirjoitetut säännöt käyttäytyvät silloin odotetusti, ja kontti pysyy omassa yksityisverkossaan.

Hinta on vielä yksi liikkuva osa, jolla on oma kokoonpanonsa, lähdeosoitteiden käsittely ja käyttöoikeuksien valvonta. Se on yleensä yksinkertaisempi tuettu raja, ja usein oikea vastaus, kun reitityskäytäntöä ylläpitäisi yksi henkilö, joka saattaa lähteä.

Varmista muutos, älä aikomus

Avaa uusi valtuutettu yhteys julkiselta puolelta ja varmista, että vastaus lähtee aiotusta rajapinnasta. Tarkista sitten, että kontin käynnistämä riippumaton pyyntö seuraa edelleen VPN:ää.

Älä tyhjennä koneen yhteystaulua yhden säännön testaamiseksi: olemassa olevat merkinnät pitävät aiemman kartoituksensa, ja tyhjennys rikkoo kaiken muun isännällä. Portin julkaiseminen määrittää tavoitettavuuden. Se ei määritä vastauksen polkua. Kirjoita valittu ratkaisu muistiin taulujensa nimillä, jotta seuraava henkilö ei löydä sitä uudelleen tapahtuman aikana.

Aiheeseen liittyvät artikkelit