Docker prievadų publikavimas ir VPN šaltiniai: du sutapimai, kuriuos praleidžiate

Taisyklė sako leisti VPN serverio adresą publikuotai paslaugai, o ryšys vis tiek nutrūksta. Toks rezultatas įprastas ir tai nėra Docker klaida. Du atskiri sutapimai yra neteisingi: šaltinis, kurį įrašėte, gali būti ne tas šaltinis, kurį gauna mazgas, o prievadas, kurį įrašėte, gali būti ne tas prievadas, kurį mato filtras. Norint ištaisyti abu, reikia žiūrėti į paketo kelią, o ne į paslaugos schemą.

Mitas: leiskite VPN serverį ir viskas

Maršrutizuotas VPN gali išsaugoti kliento tunelio adresą iki Docker mazgo. Šliuzas, kuris atlieka šaltinio vertimą, gali pakeisti tą adresą savuoju. Abi konstrukcijos yra teisėtos, ir jos duoda skirtingus šaltinius tam pačiam naudotojo veiksmui.

Taigi formuluotė VPN serverio IP aprašo prielaidą, o ne stebėjimą. Kol nežinote, kuri iš dviejų konstrukcijų yra priešais, taisyklė yra spėjimas.

Šaltinis: klientų telkinys ar verčiamas šliuzas

Patikrinkite keturis dalykus iš eilės. Pirma, klientų adresų telkinys, pavyzdžiui 10.90.0.0/24. Antra, ar šliuzas verčia tą telkinį prieš jam pasiekiant mazgą. Trečia, šaltinis, kurį mazgas iš tikrųjų stebi vienam naujam ryšiui. Ketvirta, ar programos autentifikavimas atskiria atskirus naudotojus, nes bendras verčiamas adresas to negali.

Jei telkinys išsaugomas, taisyklė, atitinkanti tik viešą šliuzo adresą, praleidžia kiekvieną klientą. Jei šliuzas sąmoningai verčia, verčiamo adreso leidimas įleidžia kiekvieną už jo esantį naudotoją, o tai gali būti priimtina paslaugai su savo prisijungimu ir nepriimtina viskam kitam.

Prievadas: DNAT pakeičia skaičių, kurį atitinkate

Įprasto Linux tiltų publikavimo su Docker iptables atveju mazgo susiejimas iš 8443 į konteinerio prievadą 443 išverčiamas prieš paleidžiant perdavimo filtrą. Paketas pasiekia filtrą su paskirties prievadu 443. Taisyklė, kuri tuo metu atitinka 8443, niekada nesuveikia, nors 8443 yra tai, ką įvedė klientas.

Publikuotas prievadas vis dar egzistuoja ryšių sekime, todėl pradinę paskirtį ten galima atitikti, kai to tikrai reikia.

Nuspręskite, kuris skaičius išreiškia ketinimą. Atitikite konteinerio prievadą po DNAT, kai taisyklė saugo paslaugą konteinerio viduje. Atitikite pradinę paskirtį su conntrack parinktimi, kai taisyklė turi aprašyti, ko prašė klientas, ir priimkite papildomas atitikimo sąnaudas bei taisyklių tvarkos kruopštumą, kurie su tuo ateina.

Grandinė: DOCKER-USER, o ne INPUT

Docker iptables vadovas naudotojo perdavimo politiką deda į grandinę DOCKER-USER, kuri vertinama prieš pačias Docker perdavimo taisykles. Taisyklė, nukopijuota iš mazgo paslaugos į grandinę INPUT, filtruoja srautą, adresuotą mazgui, o ne srautą, perduodamą į konteinerį. Ši klaida sukuria taisyklę, kuri atrodo teisinga ir neturi jokio poveikio konteinerio keliui.

Laikykite šaltinio diapazoną, efektyvų paskirties prievadą, protokolą ir įeinančią sąsają kartu toje pačioje taisyklėje. Leidimas tik pagal šaltinį kiekvienai perduodamai paskirčiai yra platesnis nei vienos publikuotos paslaugos leidimas.

Patikrinkite naujais ryšiais

Išbandykite abi kryptis naujais ryšiais: vieną leistą VPN klientą ir vieną šaltinį, kuris turi likti atmestas. Esama ryšio būsena gali išlaikyti sesiją gyvą po politikos pakeitimo, todėl senas ryšys nieko neįrodo apie naują taisyklę. Tada patikrinkite atsakymo kelią, nes konteineris vis tiek turi maršrutizuoti atgal į šaltinį, kurį mato.

Grandinių tvarką ir prievadų vertimo elgseną už šių patikrų dokumentuoja Docker iptables vadovas. Perskaitykite jį prieš kopijuodami receptą ir patvirtinkite, kurią vidinę sistemą naudoja įdiegtas Docker, nes nftables sistema politiką integruoja kitaip.