Docker-poartpublikaasje en VPN-boarnen: twa oerienkomsten dy’t jo misse

De regel seit dat jo it adres fan de VPN-tsjinner tastean moatte nei de publisearre tsjinst, en dochs falt de ferbining. Dat resultaat is gewoan, en it is gjin Docker-flater. Twa aparte oerienkomsten binne ferkeard: de boarne dy’t jo skreaun hawwe is miskien net de boarne dy’t de host ûntfangt, en de poart dy’t jo skreaun hawwe is miskien net de poart dy’t it filter sjocht. Beide reparearje freget sjen nei it pakketpaad ynstee fan it tsjinstskema.

De myte: lit de VPN-tsjinner ta en klear

In rûte VPN kin it tunneladres fan de kliïnt oant de Docker-host bewarje. In gateway dy’t boarnfertaaling docht kin dat adres ferfange troch syn eigen. Beide ûntwerpen binne legitime, en se produsearje ferskillende boarnen foar deselde brûkersaksje.

Dat seit de útdrukking IP fan de VPN-tsjinner beskriuwt in oanname, gjin waarnimming. Oant jo witte hokker fan de twa ûntwerpen foar jo stiet, is de regel in gissing.

Boarne: kliïntepoel of fertaalde gateway

Kontrolearje fjouwer dingen yn folchoarder. Earst de kliïnteadrespoel, bygelyks 10.90.0.0/24. Twad, oft de gateway dy poel fertaalt foardat er de host berikt. Tred, de boarne dy’t de host echt waarnimt foar ien nije ferbining. Fjirde, oft de autentikaasje fan de tapassing yndividuele brûkers ûnderskiedt, want in dielde fertaalde adres kin dat net.

As de poel bewarre bliuwt, mist in regel dy’t allinnich mei it iepenbiere adres fan de gateway oerienkomt elke kliïnt. As de gateway bewust fertaalt, lit it tastean fan it fertaalde adres elke brûker dêrefter yn, wat akseptabel wêze kin foar in tsjinst mei eigen oanmelding en net akseptabel foar wat dan ek.

Poart: DNAT feroaret it nûmer dat jo ferlykje

By gewoane Linux-brêgepublikaasje mei Docker iptables wurdt in hostmapping fan 8443 nei kontenerpoart 443 fertaald foardat it trochstjoerfilter draait. It pakket komt by it filter oan mei bestimmingspoart 443. In regel dy’t op dat stuit mei 8443 oerienkomt, giet nea ôf, ek al is 8443 wat de kliïnt typte.

De publisearre poart bestiet noch yn it ferbiningsregister, dêrom kin de oarspronklike bestimming dêr ferlike wurde as jo it echt nedich hawwe.

Beslis hokker nûmer de bedoeling útdrukt. Ferlykje de kontenerpoart nei DNAT as de regel de tsjinst binnen de kontener beskermet. Ferlykje de oarspronklike bestimming mei de conntrack-opsje as de regel beskriuwe moat wat de kliïnt frege, en akseptearje de ekstra ferlykkingskosten en de soarch foar regeloarder dy’t dêrmei komme.

Keatling: DOCKER-USER, net INPUT

De iptables-gids fan Docker pleatst it brûkerstrochstjoerbelied yn de DOCKER-USER-keatling, dy’t evaluearre wurdt foar de eigen trochstjoerregels fan Docker. In regel dy’t fan in hosttsjinst nei de INPUT-keatling kopiearre is, filteret ferkear rjochte op de host, net ferkear dat trochstjoerd wurdt nei in kontener. Dy flater produsearret in regel dy’t der goed útsjocht en gjin effekt hat op it kontenerpaad.

Hâld it boarneberik, de effektive bestimmingspoart, it protokol en de ynfierende ynterface byinoar yn deselde regel. In allinnich-boarne-tastean foar elke trochstjoerde bestimming is breder as it tastean fan ien publisearre tsjinst.

Ferifiearje mei nije ferbiningen

Test beide rjochtingen mei nije ferbiningen: ien tastiene VPN-kliïnt en ien boarne dy’t wegere bliuwe moat. Besteande ferbiningstastân kin in sesje libben hâlde neidat it belied feroare is, dus in âlde ferbining bewiist neat oer de nije regel. Kontrolearje dêrnei it antwurdpaad, want de kontener moat noch altyd weromrûte nei de boarne dy’t er sjocht.

De iptables-gids fan Docker dokumintearret de keatlingoarder en it poartfertaalgedrach efter dizze kontrôles. Lês him foardat jo in resept kopiearje, en befêstigje hokker backend de ynstallearre Docker brûkt, want de nftables-backend yntegrearret belied oars.