Publikovanie portov v Dockeri a zdroje VPN: dve zhody, ktoré míňate

Pravidlo hovorí povoľte adresu VPN servera k publikovanej službe, a spojenie napriek tomu padá. Taký výsledok je bežný a nie je to chyba Dockeru. Dve samostatné zhody sú nesprávne: zdroj, ktorý ste napísali, nemusí byť zdroj, ktorý prijíma hostiteľ, a port, ktorý ste napísali, nemusí byť port, ktorý vidí filter. Oprava oboch vyžaduje pohľad na cestu paketu, nie na schému služby.

Mýtus: povoľte VPN server a je hotovo

Smerovaná VPN môže zachovať adresu klientskeho tunela až po hostiteľa Dockeru. Brána, ktorá vykonáva preklad zdroja, môže túto adresu nahradiť svojou. Obe riešenia sú legitímne a pre rovnakú akciu používateľa dávajú rôzne zdroje.

Takže fráza IP adresa VPN servera opisuje predpoklad, nie pozorovanie. Kým neviete, ktoré z oboch riešení je pred vami, je pravidlo odhad.

Zdroj: klientsky fond alebo preložená brána

Skontrolujte štyri veci v poradí. Po prvé, fond klientskych adries, napríklad 10.90.0.0/24. Po druhé, či brána tento fond prekladá skôr, než dorazí k hostiteľovi. Po tretie, aký zdroj hostiteľ skutočne pozoruje pre jedno nové spojenie. Po štvrté, či overovanie v aplikácii rozlišuje jednotlivých používateľov, pretože zdieľaná preložená adresa to nedokáže.

Ak sa fond zachová, pravidlo zodpovedajúce iba verejnej adrese brány minie každého klienta. Ak brána prekladá zámerne, povolenie preloženej adresy pustí každého používateľa za ňou, čo môže byť prijateľné pre službu s vlastným prihlásením a neprijateľné pre čokoľvek iné.

Port: DNAT mení číslo, ktoré porovnávate

Pri bežnom publikovaní cez most Linuxu s Docker iptables sa mapovanie hostiteľa z 8443 na port kontajnera 443 preloží skôr, než sa spustí filter preposielania. Paket dorazí k filtru s cieľovým portom 443. Pravidlo, ktoré v tom okamihu zodpovedá 8443, sa nikdy neuplatní, aj keď 8443 je to, čo klient napísal.

Publikovaný port stále existuje v sledovaní spojení, preto sa pôvodný cieľ dá porovnať tam, keď ho naozaj potrebujete.

Rozhodnite, ktoré číslo vyjadruje zámer. Porovnávajte port kontajnera po DNAT, keď pravidlo chráni službu vnútri kontajnera. Porovnávajte pôvodný cieľ s voľbou conntrack, keď pravidlo musí opísať, čo klient požadoval, a prijmite vyššie náklady na porovnávanie aj starostlivosť o poradie pravidiel, ktoré s tým prichádzajú.

Reťaz: DOCKER-USER, nie INPUT

Príručka Dockeru k iptables umiestňuje používateľskú politiku preposielania do reťaze DOCKER-USER, ktorá sa vyhodnocuje pred vlastnými pravidlami preposielania Dockeru. Pravidlo skopírované zo služby hostiteľa do reťaze INPUT filtruje prevádzku adresovanú hostiteľovi, nie prevádzku preposielanú do kontajnera. Táto chyba vytvorí pravidlo, ktoré vyzerá správne a nemá žiadny vplyv na cestu kontajnera.

Držte rozsah zdroja, efektívny cieľový port, protokol a vstupné rozhranie spolu v tom istom pravidle. Povolenie len podľa zdroja pre každý preposielaný cieľ je širšie než povolenie jednej publikovanej služby.

Overte novými spojeniami

Otestujte oba smery novými spojeniami: jeden povolený klient VPN a jeden zdroj, ktorý má zostať zakázaný. Existujúci stav spojenia môže udržať reláciu živú po zmene politiky, takže staré spojenie o novom pravidle nič nedokazuje. Potom skontrolujte cestu odpovede, pretože kontajner sa stále musí smerovať späť k zdroju, ktorý vidí.

Poradie reťazí a správanie prekladu portov za týmito kontrolami dokumentuje príručka Dockeru k iptables. Prečítajte si ju pred kopírovaním receptu a overte, ktorý backend nainštalovaný Docker používa, pretože backend nftables integruje politiku inak.