Dockerin porttien julkaisu ja VPN-lähteet: kaksi osumaa, jotka ohitat

Sääntö sanoo, että VPN-palvelimen osoite sallitaan julkaistuun palveluun, ja yhteys katkeaa silti. Tulos on tavallinen eikä ole Dockerin virhe. Kaksi erillistä osumaa on väärin: kirjoittamasi lähde ei ehkä ole lähde, jonka isäntä vastaanottaa, eikä kirjoittamasi portti ehkä ole portti, jonka suodatin näkee. Molempien korjaaminen vaatii paketin reitin katsomista palvelun kaavion sijaan.

Myytti: salli VPN-palvelin ja homma on valmis

Reititetty VPN voi säilyttää asiakkaan tunneliosoitteen aina Docker-isännälle asti. Yhdyskäytävä, joka tekee lähdekäännöksen, voi korvata osoitteen omallaan. Molemmat mallit ovat sallittuja, ja ne tuottavat eri lähteet samalle käyttäjän toiminnolle.

Niinpä ilmaus VPN-palvelimen IP kuvaa oletusta, ei havaintoa. Kunnes tiedät, kumpi malleista on edessäsi, sääntö on arvaus.

Lähde: asiakaspooli vai käännetty yhdyskäytävä

Tarkista neljä asiaa järjestyksessä. Ensiksi asiakkaiden osoitepooli, esimerkiksi 10.90.0.0/24. Toiseksi, kääntääkö yhdyskäytävä poolin ennen kuin se saavuttaa isännän. Kolmanneksi lähde, jonka isäntä todella havaitsee yhdelle uudelle yhteydelle. Neljänneksi, erottaako sovelluksen todennus yksittäiset käyttäjät, koska jaettu käännetty osoite ei voi.

Jos pooli säilyy, sääntö, joka vastaa vain yhdyskäytävän julkista osoitetta, ohittaa jokaisen asiakkaan. Jos yhdyskäytävä kääntää tarkoituksella, käännetyn osoitteen salliminen päästää sisään jokaisen käyttäjän sen takana, mikä voi olla hyväksyttävää palvelulle, jolla on oma kirjautuminen, ja hyväksymätöntä kaikelle muulle.

Portti: DNAT muuttaa numeroa, jota vastaat

Tavallisessa Linux-sillan julkaisussa Docker iptablesin kanssa isännän kuvaus 8443:sta kontin porttiin 443 käännetään ennen kuin edelleenlähetyssuodatin käynnistyy. Paketti saapuu suodattimelle kohdeportilla 443. Sääntö, joka vastaa 8443:a siinä kohdassa, ei laukea koskaan, vaikka 8443 on se, minkä asiakas kirjoitti.

Julkaistu portti on yhä olemassa yhteyksien seurannassa, siksi alkuperäinen kohde voidaan sovittaa siellä, kun sitä todella tarvitset.

Päätä, mikä numero ilmaisee aikomuksen. Sovita kontin porttiin DNATin jälkeen, kun sääntö suojaa palvelua kontin sisällä. Sovita alkuperäiseen kohteeseen conntrack-valinnalla, kun säännön on kuvattava, mitä asiakas pyysi, ja hyväksy ylimääräinen sovituskustannus ja sääntöjärjestyksen huolellisuus, jotka tulevat sen mukana.

Ketju: DOCKER-USER, ei INPUT

Dockerin iptables-opas sijoittaa käyttäjän edelleenlähetyskäytännön DOCKER-USER-ketjuun, joka arvioidaan ennen Dockerin omia edelleenlähetyssääntöjä. Isäntäpalvelusta INPUT-ketjuun kopioitu sääntö suodattaa isännälle osoitettua liikennettä, ei konttiin edelleenlähetettävää liikennettä. Tämä virhe tuottaa säännön, joka näyttää oikealta eikä vaikuta kontin reittiin.

Pidä lähdealue, tehollinen kohdeportti, protokolla ja saapuva liitäntä yhdessä samassa säännössä. Vain lähteeseen perustuva sallinta jokaiselle edelleenlähetetylle kohteelle on laajempi kuin yhden julkaistun palvelun salliminen.

Vahvista tuoreilla yhteyksillä

Testaa molemmat suunnat uusilla yhteyksillä: yksi sallittu VPN-asiakas ja yksi lähde, jonka pitäisi pysyä hylättynä. Olemassa oleva yhteystila voi pitää istunnon elossa käytännön muuttamisen jälkeen, joten vanha yhteys ei todista mitään uudesta säännöstä. Tarkista sitten vastausreitti, koska kontin on yhä reititettävä takaisin lähteeseen, jonka se näkee.

Dockerin iptables-opas dokumentoi ketjujen järjestyksen ja porttien käännöskäyttäytymisen näiden tarkistusten taustalla. Lue se ennen reseptin kopioimista ja varmista, mitä backendia asennettu Docker käyttää, koska nftables-backend sisällyttää käytännön eri tavalla.