Publikování portů v Dockeru versus VPN: kam odpověď odchází

Publikovaný kontejner odpovídá ze své vlastní adresy ještě před reverzním NAT. Dva návrhy mohou tuto odpověď udržet na veřejné cestě, s různými náklady.

Hostitel dál odpovídá na SSH i poté, co se zvedne VPN s plným tunelem, ale služba publikovaná přes Docker na stejném stroji ztichne. Se serverem není nic špatně: kontejner běží, mapování portu existuje a paket dorazí. Kontejner je zdravý a požadavek k němu skutečně dojde. Rozdíl je v tom, odkud odpověď začíná, když Linux volí svou trasu, a ten rozdíl rozhoduje o tom, který ze dvou návrhů níže potřebujete.

Sledujte tuple přes cílový NAT

Vezměte hostitele na 192.0.2.10, který publikuje TCP 2222 na kontejner na 172.30.240.5:22. Požadavek z 198.51.100.25 se přeloží, než dorazí ke kontejneru, a kontejner odpovídá jako 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

V okamžiku rozhodnutí hostitele o trase nese odpověď stále zdrojovou adresu kontejneru. Reverzní překlad později obnoví publikovaný tuple, a právě proto paket vypadá špatně přesně v momentě, kdy se trasa volí.

Proč to pravidlo jen pro hostitele mine

Pravidlo, které volí tabulku WAN jen pro pakety z 192.0.2.10 pokrývá vlastní démony hostitele a tuto přesměrovanou odpověď úplně mine. Zdrojová adresa odpovědi je 172.30.240.5, ne hostitel.

Překorekce znamená posílat všechno z kontejneru přes WAN, což také vyjímá nesouvisející odchozí spojení kontejneru z VPN. To je jiná politika, než jaká byla požadována, a obvykle to někoho později překvapí.

Párování po DNAT je jiný hook

Dokumentace Dockeru k firewallu upozorňuje, že běžné uživatelské filtrování vidí cíl po DNAT, takže párování publikovaného portu 2222 v normálním pravidle není totéž jako párování portu kontejneru 22. Pokud záleží na původním tuple, použijte podporovaný mechanismus původního cíle místo hádání, který port je viditelný.

Toto zmatení hooků vytváří pravidla, která vypadají správně a nikdy se netrefí. Než přepíšete politiku, zkontrolujte čítače na samotném pravidle. Pravidlo s nulovými zásahy vám říká, že se vyhodnocuje někde, kam paket nikdy nedorazí.

Návrh A: nést rozhodnutí jako stav spojení

Značka spojení může nést rozhodnutí o příchodu skrz překlad, ale musí být vrácena paketu dřív než vyhledání trasy, na kterém záleží. Fáze jsou:

  1. Rezervujte pole značky a prioritu pravidla, které nekolidují s Dockerem, VPN ani jiným vlastníkem politiky.
  2. Identifikujte jen zamýšlené nové spojení WAN v bodě před DNAT, kde je dostupné sledování spojení.
  3. Zaznamenejte rozhodnutí do značky spojení, aniž byste samotný původní požadavek nutili do tabulky WAN.
  4. Ve směru odpovědi vraťte paketu před směrováním jen své vlastní bity značky.
  5. Zvolte úplnou tabulku WAN dostatečně brzy, aby pravidlo VPN nemohlo vyhrát první.

Tato tabulka potřebuje skutečné připojené trasy a bránu. Potřebuje také definované chování, když trasa chybí. Tiché propadnutí do tunelu je nejhorší výsledek, protože konfigurace pořád vypadá, že funguje. Místo toho selhejte zavřeně a zaznamenejte to.

Návrh B: ukončete to na hostiteli

Záměrně nastavený frontend na straně hostitele, například TCP proxy nebo reverzní proxy před kontejnerem, drží odpověď vycházející z adresy hostitele. Pravidla psaná pro hostitele se pak chovají podle očekávání a kontejner zůstává ve své privátní síti.

Cena je další pohyblivá část s vlastní konfigurací, zpracováním zdrojové adresy a řízením přístupu. Obvykle je to jednodušší podporovaná hranice a často to je správná odpověď, když by politiku směrování udržoval jeden člověk, který může odejít.

Ověřte změnu, ne záměr

Otevřete nové autorizované spojení z veřejné strany a potvrďte, že odpověď odchází zamýšleným rozhraním. Pak ověřte, že nesouvisející požadavek zahájený kontejnerem stále sleduje VPN.

Nevyprazdňujte tabulku spojení stroje, abyste otestovali jedno pravidlo: stávající záznamy si drží dřívější mapování a výmaz rozbije všechno ostatní na hostiteli. Publikování portu definuje dosažitelnost. Nedefinuje cestu odpovědi. Zapište zvolený návrh s názvy jeho tabulek, aby ho příští člověk nemusel během incidentu objevovat znovu.

Související články