Publikovanie portov v Dockeri verzus VPN: kam odchádza odpoveď

Publikovaný kontajner odpovedá zo svojej vlastnej adresy pred reverzným NAT. Dva návrhy môžu udržať tú odpoveď na verejnej ceste, s rôznymi nákladmi.

Hostiteľ ďalej odpovedá na SSH aj po tom, čo sa zdvihne VPN s plným tunelom, ale služba publikovaná cez Docker na tom istom stroji stíchne. S listenerom nie je nič v poriadku: kontajner beží, mapovanie portu existuje a paket prichádza. Kontajner je zdravý a požiadavka sa k nemu naozaj dostane. Rozdiel je v tom, odkiaľ odpoveď začína, keď Linux volí svoju trasu, a ten rozdiel rozhoduje, ktorý z dvoch návrhov nižšie potrebujete.

Sledujte tuple cez cieľový NAT

Vezmite hostiteľa na 192.0.2.10, ktorý publikuje TCP 2222 na kontajner na 172.30.240.5:22. Požiadavka z 198.51.100.25 sa preloží skôr, než dorazí ku kontajneru, a kontajner odpovedá ako on sám.

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

Pri rozhodovaní hostiteľa o trase nesie odpoveď stále zdrojovú adresu kontajnera. Reverzný preklad obnoví publikovaný tuple až neskôr, a práve preto paket vyzerá nesprávne presne v momente, keď sa trasa volí.

Prečo to pravidlo len pre hostiteľa minie

Pravidlo, ktoré volí tabuľku WAN len pre pakety z 192.0.2.10, pokrýva vlastné démony hostiteľa a túto preposlanú odpoveď úplne minie. Zdrojová adresa v odpovedi je 172.30.240.5, nie hostiteľ.

Prehnaná oprava je posielať všetko z kontajnera cez WAN, čo tiež vyjme nesúvisiace odchádzajúce spojenia kontajnera z VPN. To je iná politika, než aká bola požadovaná, a zvyčajne to niekoho neskôr prekvapí.

Párovanie po DNAT je iný hook

Dokumentácia Dockeru k firewallu upozorňuje, že bežné používateľské filtrovanie vidí cieľ po DNAT, takže párovanie publikovaného portu 2222 v normálnom pravidle nie je to isté ako párovanie portu 22 kontajnera. Ak záleží na pôvodnom tuple, použite podporovaný mechanizmus pôvodného cieľa namiesto hádania, ktorý port je viditeľný.

Tento zmätok okolo hookov vytvára pravidlá, ktoré vyzerajú správne a nikdy sa nezhodujú. Pred prepísaním politiky skontrolujte počítadlá na samotnom pravidle. Pravidlo bez jediného zásahu vám hovorí, že sa vyhodnocuje niekde, kam paket nikdy nedorazí.

Návrh A: niesť rozhodnutie ako stav spojenia

Značka spojenia môže preniesť rozhodnutie o vstupe cez preklad, ale musí sa vrátiť na paket pred tým vyhľadaním trasy, ktoré je dôležité. Fázy sú:

  1. Rezervujte pole značky a prioritu pravidla, ktoré nekolidujú s Dockerom, VPN ani iným vlastníkom politiky.
  2. Identifikujte len zamýšľané nové spojenie WAN v bode pred DNAT, kde je dostupné sledovanie spojení.
  3. Zaznamenajte rozhodnutie do značky spojenia, bez toho aby ste samotnú pôvodnú požiadavku nútili do tabuľky WAN.
  4. V smere odpovede vráťte na paket pred smerovaním len svoje vlastné bity značky.
  5. Vyberte úplnú tabuľku WAN dostatočne skoro, aby pravidlo VPN nemohlo vyhrať prvé.

Táto tabuľka potrebuje skutočné pripojené trasy a bránu. Potrebuje aj definované správanie, keď trasa chýba. Tiché prepadnutie do tunela je najhorší výsledok, pretože konfigurácia stále vyzerá, že funguje. Namiesto toho zlyhajte zatvorene a zaznamenajte to.

Návrh B: ukončite to na hostiteľovi

Zámerne nastavený frontend na strane hostiteľa, napríklad TCP proxy alebo reverzná proxy pred kontajnerom, drží odpoveď vychádzajúcu z adresy hostiteľa. Pravidlá napísané pre hostiteľa sa potom správajú podľa očakávania a kontajner zostáva vo svojej privátnej sieti.

Cena je ďalšia pohyblivá časť s vlastnou konfiguráciou, spracovaním zdrojovej adresy a riadením prístupu. Zvyčajne je to jednoduchšia podporovaná hranica a často je to správna odpoveď, keď by politiku smerovania udržiaval jeden človek, ktorý môže odísť.

Overte zmenu, nie zámer

Otvorte nové autorizované spojenie z verejnej strany a potvrďte, že odpoveď odchádza zamýšľaným rozhraním. Potom skontrolujte, či nesúvisiaca požiadavka spustená kontajnerom stále sleduje VPN.

Nečistite tabuľku spojení stroja, aby ste otestovali jedno pravidlo: existujúce záznamy si držia skoršie mapovanie a vyčistenie pokazí všetko ostatné na hostiteľovi. Publikovanie portu definuje dosiahnuteľnosť. Nedefinuje cestu odpovede. Zapíšte zvolený návrh s názvami jeho tabuliek, aby ho nasledujúci človek nemusel znovu objavovať počas incidentu.

Súvisiace články