DNAT VPN konteinerā: pāradresēšana, nevis INPUT

Pēc DNAT pieprasījums uz tuneļa adresi kļūst par pāradresētu trafiku. Sašauriniet pāradresēšanas noteikumu, izlasiet Docker ķēdi un apzināti izvēlieties atgriešanās ceļu.

Pieprasījums ierodas ar tuneļa IP adresi un atstāj to pašu konteineru ar blakus esoša servisa adresi. Starp šiem diviem brīžiem DNAT pārrakstīja galamērķi, un pakešu vairs nebija VPN konteinera ievade. Tagad tas ir pāradresēts trafiks, ko vērtē cits noteikums. Šīs izmaiņas izskaidro, kāpēc ugunsmūra noteikumam, kas izskatās pareizs tuneļa adresei, nav nekādas ietekmes uz tulkoto savienojumu.

Izsekojiet pakešu pēc tulkošanas

Ņemiet klientu kopu 10.90.0.0/24 un tuneļa adresi 10.90.0.1. Divi konteineri atrodas uz viena tilta: 192.0.2.2 darbina VPN, bet 192.0.2.3 darbina lietotni. Klients pieslēdzas 10.90.0.1:8080, un DNAT noteikums VPN konteinera nosaukumu telpā to pārraksta uz lietotnes īsto adresi un portu. Pēc tam maršruts nosūta pakešu pāri tiltam. Šīs adreses ir ilustratīvas, nevis izvietošanas recepte.

Ports, kurā lietotne patiešām klausās, var atšķirties no jebkura porta, kas publicēts uz resursdatora. Lasiet klausītāju konteinera iekšpusē, nevis pieņemiet, ka abi skaitļi sakrīt.

Atļauja pieder pāradresēšanas ceļam

VPN konteineram nepieciešama IP pāradresēšana un lēmums par pāradresēšanu, kas ierobežots ar klientu kopu, lietotnes adresi un paredzēto portu. Izveidotajām atbildēm nepieciešama sava atļauja. Noteikums, kas atbilst sākotnējai tuneļa adresei, pēc DNAT vairs neatbildīs, jo galamērķis jau ir mainījies. INPUT atļauja ir nepareizais āķis trafikam, kas vairs nav adresēts šim resursdatoram.

Turiet tvērumu šauru: viens avota diapazons, viens galamērķis, viens serviss. Atļaujošs pāradresēšanas noteikums ir vieglāk rakstāms un daudz grūtāk aizstāvams vēlāk.

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 ķēdes nav jūsu konteinera ķēdes

Noteikumi konteinera nosaukumu telpā nav Docker resursdatora noteikumi. Kad trafiks pāriet no tuneļa saskarnes uz tiltu, resursdatora tilta ugunsmūris var pieņemt citu lēmumu. Ar Docker iptables backend dokumentētās pāradresēšanas ķēdes un atbilstības punkti pēc DNAT ir vieta, kur šis lēmums parādās.

Docker ugunsmūra uzziņa apraksta šīs ķēdes un atbilstību pēc DNAT. Nelabojiet trūkstošu atļauju, izslēdzot Docker ugunsmūra pārvaldību vai padarot katru ķēdi atļaujošu, jo tas noņem robežu, ko mēģināt izmantot.

Padariet atgriešanās ceļu par apzinātu izvēli

Ja avota adrese tiek saglabāta, lietotne redz 10.90.0.x un tai atbildes jānosūta atpakaļ caur VPN konteineru. Pretējā gadījumā tās parastais Docker vārteja nosūtīs tās uz resursdatoru, kuram nepieder tunelis. Alternatīva ir šauri ierobežota avota tulkošana VPN konteinerā, kas vienkāršo atbildi, bet paslēpj klientu no lietotnes. Izvēlieties apzināti un pierakstiet, kuru izvēlējāties.

Pārbaudiet jaunu atļautu savienojumu no parasta klienta, pēc tam apstipriniet, ka nesaistīti porti paliek slēgti. Kad pakešu pazūd, pārbaudiet VPN nosaukumu telpu, lietotnes nosaukumu telpu un pašas lietotnes žurnālu. Ping uz tilta vārteju nav servisa pieņemšanas tests.

Turiet noteikumus konteinera atbalstītajā palaišanas konfigurācijā, jo interaktīvas izmaiņas pazūd, kad tas tiek izveidots no jauna. Resursdatora porta publicēšana ir cits iedarbības ceļš, un tā nav nepieciešama tikai tāpēc, ka serviss ir sasniedzams caur tuneli.

Saistītie raksti