Docker portu publicēšana pret VPN: kur aiziet atbilde

Publicēts konteiners atbild no savas adreses pirms apgrieztā NAT. Divi risinājumi var noturēt šo atbildi publiskajā ceļā, ar atšķirīgām izmaksām.

Resursdators turpina atbildēt uz SSH pēc tam, kad ir pacelts pilna tuneļa VPN, bet tajā pašā mašīnā ar Docker publicētais pakalpojums apklust. Ar klausītāju viss ir kārtībā: konteiners darbojas, portu kartējums pastāv, un pakete pienāk. Konteiners ir vesels, un pieprasījums patiešām to sasniedz. Atšķiras tas, no kā atbilde sākas, kad Linux izvēlas savu maršrutu, un šī atšķirība nosaka, kurš no diviem risinājumiem zemāk jums vajadzīgs.

Sekojiet tuple caur galamērķa NAT

Ņemiet resursdatoru 192.0.2.10, kas publicē TCP 2222 uz konteineru 172.30.240.5:22. Pieprasījums no 198.51.100.25 tiek pārtulkots pirms nonākšanas konteinerā, un konteiners atbild kā pats sevi.

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

Resursdatora maršruta lēmuma brīdī atbilde joprojām nes konteinera avota adresi. Apgrieztā tulkošana vēlāk atjauno publicēto tuple, un tieši tāpēc pakete izskatās nepareiza tieši tajā brīdī, kad maršruts tiek izvēlēts.

Kāpēc noteikums tikai resursdatoram to palaiž garām

Noteikums, kas WAN tabulu izvēlas tikai paketēm no 192.0.2.10, aptver paša resursdatora dēmonus un pilnībā palaiž garām šo pārsūtīto atbildi. Atbildes avota adrese ir 172.30.240.5, nevis resursdators.

Pārmērīgais labojums ir maršrutēt visu no konteinera caur WAN, kas arī atbrīvo konteinera nesaistītos izejošos savienojumus no VPN. Tā ir cita politika nekā pieprasītā, un tā parasti kādu vēlāk pārsteidz.

Saskaņošana pēc DNAT ir cits hook

Docker dokumentācija par ugunsmūriem norāda, ka parastā lietotāja filtrēšana redz galamērķi pēc DNAT, tāpēc publicētā porta 2222 saskaņošana parastā noteikumā nav tas pats, kas konteinera porta 22 saskaņošana. Ja sākotnējais tuple ir svarīgs, izmantojiet atbalstīto sākotnējā galamērķa mehānismu, nevis miniet, kurš ports ir redzams.

Šī hook sajaukšana rada noteikumus, kas izskatās pareizi un nekad nesakrīt. Pirms politikas pārrakstīšanas pārbaudiet skaitītājus pašā noteikumā. Noteikums bez neviena trāpījuma jums saka, ka tas tiek vērtēts vietā, kur pakete nekad nenonāk.

Risinājums A: nest lēmumu kā savienojuma stāvokli

Savienojuma atzīme var nest ieejas lēmumu caur tulkošanu, bet tā ir jāatjauno paketē pirms svarīgās maršruta meklēšanas. Posmi ir:

  1. Rezervējiet atzīmes lauku un noteikuma prioritāti, kas nesaduras ar Docker, VPN vai citu politikas īpašnieku.
  2. Identificējiet tikai paredzēto jauno WAN savienojumu punktā pirms DNAT, kur ir pieejama savienojumu izsekošana.
  3. Ierakstiet lēmumu savienojuma atzīmē, neuzspiežot pašu sākotnējo pieprasījumu WAN tabulai.
  4. Atbildes virzienā pirms maršrutēšanas atjaunojiet paketē tikai savus atzīmes bitus.
  5. Izvēlieties pilnu WAN tabulu pietiekami agri, lai VPN noteikums nevarētu uzvarēt pirmais.

Šai tabulai vajag īstos pievienotos maršrutus un vārteju. Tai vajag arī definētu uzvedību, kad maršruts trūkst. Klusa iekrišana tunelī ir sliktākais iznākums, jo konfigurācija joprojām izskatās strādājam. Tā vietā neizdodieties slēgti un reģistrējiet to.

Risinājums B: pabeigt uz resursdatora

Apzināti konfigurēts resursdatora puses frontends, piemēram, TCP starpniekserveris vai apgrieztais starpniekserveris konteinera priekšā, notur atbildi nākam no resursdatora adreses. Tad resursdatoram rakstītie noteikumi uzvedas kā gaidīts, un konteiners paliek savā privātajā tīklā.

Izmaksa ir vēl viena kustīga daļa ar savu konfigurāciju, avota adrešu apstrādi un piekļuves kontroli. Parasti tā ir vienkāršākā atbalstītā robeža, un tā bieži ir pareizā atbilde, ja maršrutēšanas politiku uzturētu viens cilvēks, kurš varētu aiziet.

Pārbaudiet izmaiņas, nevis nodomu

Atveriet jaunu atļautu savienojumu no publiskās puses un apstipriniet, ka atbilde iziet pa paredzēto saskarni. Pēc tam pārbaudiet, vai nesaistīts konteinera uzsākts pieprasījums joprojām seko VPN.

Neiztīriet mašīnas savienojumu tabulu, lai pārbaudītu vienu noteikumu: esošie ieraksti saglabā iepriekšējo kartējumu, un tīrīšana salauž visu pārējo resursdatorā. Porta publicēšana definē sasniedzamību. Tā nedefinē atbildes ceļu. Pierakstiet izvēlēto risinājumu ar tā tabulu nosaukumiem, lai nākamajam cilvēkam tas nebūtu jāatklāj no jauna incidenta laikā.

Saistītie raksti