DNAT yn in VPN-kontener: trochstjoere, net INPUT

Nei DNAT wurdt in fersyk oan it tunneladres trochstjoerd ferkear. Behein de trochstjoerregel, lês de Docker-keten en kies mei opsetsin in weromwei.

It fersyk komt oan mei it tunnel-IP as adres en ferlit deselde kontener mei it adres fan in oanbuorjende tsjinst. Tusken dy twa mominten hat DNAT de bestimming oerskreaun, en it pakket wie gjin ynfier mear foar de VPN-kontener. No is it trochstjoerd ferkear, dat troch in oare regel beoardiele wurdt. Dy ferskowing ferklearret wêrom in fjoermuorreel dy't foar it tunneladres goed liket, gjin effekt hat op de oersette ferbining.

Folgje it pakket nei de oersetting

Nim in klantpôle fan 10.90.0.0/24 en in tunneladres fan 10.90.0.1. Twa konteners steane op ien brêge: 192.0.2.2 rint de VPN en 192.0.2.3 rint de applikaasje. In klant ferbynt mei 10.90.0.1:8080, en de DNAT-regel yn 'e nammeromte fan de VPN-kontener skriuwt dat oer nei it echte adres en de poarte fan de applikaasje. Dan stjoert in rûte it pakket oer de brêge. Dy adressen binne yllustratyf, gjin resept foar útrulling.

De poarte dêr't de applikaasje echt op harket, kin ferskille fan elke poarte dy't op de host publisearre is. Lês de harker binnen de kontener ynstee fan oan te nimmen dat beide nûmers oerienkomme.

De tastimming heart by it trochstjoerpaad

De VPN-kontener hat IP-trochstjoering nedich en in trochstjoerbeslút dat beheind is ta de klantpôle, it adres fan de applikaasje en de bedoelde poarte. Fêstige antwurden hawwe har eigen tastimming nedich. In regel dy't by it oarspronklike tunneladres past, sil nei DNAT net mear passe, om't de bestimming al feroare is. In INPUT-tastimming is de ferkearde heak foar ferkear dat net mear oan dizze host rjochte is.

Hâld it berik smel: ien boarneberik, ien bestimming, ien tsjinst. In tastien trochstjoerregel is makliker te skriuwen en folle dreger letter te ferdigenjen.

docker exec vpn-container ip route get 192.0.2.3
docker exec vpn-container iptables -t nat -S
docker exec vpn-container iptables -S FORWARD

Docker-ketens binne net de ketens fan jo kontener

Regels binnen de nammeromte fan de kontener binne net de regels fan de Docker-host. As ferkear fan de tunnelrynterface nei de brêge giet, kin de brêgefjoermuorre fan de host in oar beslút nimme. By de iptables-backend fan Docker is it yn 'e dokumintearre trochstjoerketens en de oerienkomsten nei DNAT dat dat beslút ferskint.

Docker-fjoermuorreferinsje beskriuwt dy ketens en de oerienkomst nei DNAT. Reparearje in ûntbrekkende akseptaasje net troch it fjoermuorrebehear fan Docker út te skeakeljen of elke keten tastien te meitsjen, want dat hellet de grins fuort dy't jo brûke wolle.

Meitsje de weromwei in bewuste kar

As it boarne-adres bewarre bliuwt, sjocht de applikaasje 10.90.0.x en moat antwurden werom stjoere fia de VPN-kontener. Oars stjoert syn gewoane Docker-poarte se nei de host, dy't de tunnel net besit. It alternatyf is in smel beheinde boarneoersetting by de VPN-kontener, dy't it antwurd ferienfâldiget mar de klant foar de applikaasje ferberget. Kies mei opsetsin en skriuw op hokker jo keazen hawwe.

Test in nije tastiene ferbining fan in gewoane klant, en befêstigje dan dat net-relatearre poarten ticht bliuwe. As in pakket ferdwynt, ûndersykje de VPN-nammeomte, de nammeromte fan de applikaasje en it eigen log fan 'e applikaasje. In ping nei de brêgepoarte is gjin akseptaasjetest foar de tsjinst.

Hâld de regels yn 'e stipe startkonfiguraasje fan 'e kontener, want ynteraktive bewurkings ferdwine as er opnij makke wurdt. It publisearjen fan in hostpoarte is in oar bleatstellingspaad en is net nedich allinnich om't de tsjinst fia de tunnel berikber is.

Relatearre artikelen