Docker portu publicēšana un VPN avoti: divas sakritības, ko palaižat garām

Noteikums saka atļaut VPN servera adresi publicētajam servisam, un savienojums tomēr pārtrūkst. Šāds iznākums ir izplatīts, un tā nav Docker kļūda. Divas atsevišķas sakritības ir nepareizas: avots, ko ierakstījāt, var nebūt tas avots, ko saņem resursdators, un ports, ko ierakstījāt, var nebūt tas ports, ko redz filtrs. Lai izlabotu abus, jāskatās pakešu ceļš, nevis servisa shēma.

Mīts: atļaujiet VPN serveri, un viss

Maršrutēts VPN var saglabāt klienta tuneļa adresi līdz pat Docker resursdatoram. Vārteja, kas veic avota tulkošanu, var aizstāt šo adresi ar savējo. Abi risinājumi ir likumīgi, un tie dod dažādus avotus vienai un tai pašai lietotāja darbībai.

Tātad frāze VPN servera IP apraksta pieņēmumu, nevis novērojumu. Kamēr nezināt, kurš no abiem risinājumiem ir jūsu priekšā, noteikums ir minējums.

Avots: klientu kopums vai tulkota vārteja

Pārbaudiet četras lietas pēc kārtas. Pirmkārt, klientu adrešu kopums, piemēram 10.90.0.0/24. Otrkārt, vai vārteja tulko šo kopumu pirms tas sasniedz resursdatoru. Treškārt, avots, ko resursdators patiešām novēro vienam jaunam savienojumam. Ceturtkārt, vai lietojumprogrammas autentifikācija atšķir atsevišķus lietotājus, jo kopīga tulkota adrese to nevar.

Ja kopums tiek saglabāts, noteikums, kas atbilst tikai vārtejas publiskajai adresei, palaiž garām katru klientu. Ja vārteja apzināti tulko, tulkotās adreses atļaušana ielaiž katru lietotāju aiz tās, kas var būt pieņemami servisam ar savu pieteikšanos un nepieņemami visam citam.

Ports: DNAT maina skaitli, ko saskaņojat

Parastā Linux tilta publicēšanā ar Docker iptables resursdatora kartējums no 8443 uz konteinera portu 443 tiek tulkots pirms pārsūtīšanas filtra darbības. Pakete nonāk pie filtra ar mērķa portu 443. Noteikums, kas tajā brīdī atbilst 8443, nekad neiedarbojas, lai gan 8443 ir tas, ko klients ierakstīja.

Publicētais ports joprojām pastāv savienojumu izsekošanā, tāpēc sākotnējo mērķi tur var saskaņot, kad tas patiešām ir vajadzīgs.

Izlemiet, kurš skaitlis izsaka nodomu. Saskaņojiet konteinera portu pēc DNAT, kad noteikums aizsargā servisu konteinera iekšienē. Saskaņojiet sākotnējo mērķi ar conntrack opciju, kad noteikumam jāapraksta, ko klients pieprasīja, un pieņemiet papildu saskaņošanas izmaksas un rūpību ar noteikumu secību, kas ar to nāk.

Ķēde: DOCKER-USER, nevis INPUT

Docker iptables rokasgrāmata ievieto lietotāja pārsūtīšanas politiku ķēdē DOCKER-USER, kas tiek novērtēta pirms pašiem Docker pārsūtīšanas noteikumiem. Noteikums, kas nokopēts no resursdatora servisa uz ķēdi INPUT, filtrē trafiku, kas adresēts resursdatoram, nevis trafiku, kas pārsūtīts uz konteineru. Šī kļūda rada noteikumu, kas izskatās pareizs un kam nav nekādas ietekmes uz konteinera ceļu.

Turiet avota diapazonu, efektīvo mērķa portu, protokolu un ieejas saskarni kopā tajā pašā noteikumā. Atļauja tikai pēc avota katram pārsūtītajam mērķim ir plašāka nekā viena publicēta servisa atļaušana.

Pārbaudiet ar jauniem savienojumiem

Pārbaudiet abus virzienus ar jauniem savienojumiem: vienu atļautu VPN klientu un vienu avotu, kam jāpaliek atteiktam. Esošais savienojuma stāvoklis var uzturēt sesiju dzīvu pēc politikas maiņas, tāpēc vecs savienojums neko nepierāda par jauno noteikumu. Pēc tam pārbaudiet atbildes ceļu, jo konteineram joprojām jāmaršrutē atpakaļ uz avotu, ko tas redz.

Ķēžu secību un portu tulkošanas uzvedību aiz šīm pārbaudēm dokumentē Docker iptables rokasgrāmata. Izlasiet to pirms receptes kopēšanas un pārliecinieties, kuru aizmuguri izmanto instalētais Docker, jo nftables aizmugure politiku integrē citādi.