Domaćin nastavlja odgovarati na SSH nakon što se podigne VPN s punim tunelom, a usluga objavljena kroz Docker na istom računalu utihne. Sa slušateljem nije ništa u redu: kontejner radi, mapiranje porta postoji i paket stiže. Kontejner je zdrav i zahtjev ga doista dosegne. Razlika je u tome odakle odgovor počinje kada Linux bira svoju rutu, a ta razlika odlučuje koji od dva dizajna ispod vam treba.

Pratite tuple kroz odredišni NAT

Uzmite domaćina na 192.0.2.10 koji objavljuje TCP 2222 na kontejner na 172.30.240.5:22. Zahtjev s 198.51.100.25 prevodi se prije nego što dosegne kontejner, a kontejner odgovara kao on sam.

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

U trenutku odluke domaćina o ruti odgovor još nosi izvornu adresu kontejnera. Obrnuto prevođenje kasnije vraća objavljeni tuple, i zato paket izgleda pogrešno baš u trenutku kada se ruta bira.

Zašto pravilo samo za domaćina to promašuje

Pravilo koje bira WAN tablicu samo za pakete s 192.0.2.10 pokriva vlastite demone domaćina i potpuno promašuje ovaj proslijeđeni odgovor. Izvorna adresa na odgovoru je 172.30.240.5, a ne domaćin.

Prekomjerna korekcija je usmjeriti sve iz kontejnera kroz WAN, što također izuzima nepovezane odlazne veze kontejnera od VPN-a. To je drugačija politika od one koja je zatražena i obično nekoga kasnije iznenadi.

Podudaranje nakon DNAT-a je druga kuka

Dockerova dokumentacija o vatrozidu napominje da uobičajeno korisničko filtriranje vidi odredište nakon DNAT-a, pa podudaranje objavljenog porta 2222 u normalnom pravilu nije isto kao podudaranje porta 22 kontejnera. Ako je izvorni tuple važan, koristite podržani mehanizam izvornog odredišta umjesto nagađanja koji je port vidljiv.

Ova zbrka oko kuka stvara pravila koja izgledaju ispravno i nikada se ne podudaraju. Provjerite brojače na samom pravilu prije nego što prepišete politiku. Pravilo bez ijednog pogotka govori vam da se ocjenjuje negdje gdje paket nikada ne stiže.

Dizajn A: nosite odluku kao stanje veze

Oznaka veze može prenijeti odluku o ulazu kroz prevođenje, ali mora se vratiti na paket prije pretraživanja rute koje je važno. Faze su:

  1. Rezervirajte polje oznake i prioritet pravila koji se ne sudaraju s Dockerom, VPN-om ili drugim vlasnikom politike.
  2. Identificirajte samo predviđenu novu WAN vezu u točki prije DNAT-a gdje je praćenje veza dostupno.
  3. Zabilježite odluku na oznaku veze, bez prisiljavanja samog izvornog zahtjeva na WAN tablicu.
  4. U smjeru odgovora vratite na paket samo vlastite bitove oznake prije usmjeravanja.
  5. Odaberite potpunu WAN tablicu dovoljno rano da VPN pravilo ne može pobijediti prvo.

Ta tablica treba stvarne povezane rute i pristupnik. Također treba definirano ponašanje kada ruta nedostaje. Tiho propadanje u tunel najgori je ishod, jer konfiguracija još izgleda kao da radi. Umjesto toga padnite zatvoreno i zabilježite to.

Dizajn B: završite na domaćinu

Namjerno konfiguriran frontend na strani domaćina, poput TCP proxyja ili obrnutog proxyja ispred kontejnera, drži odgovor da potječe s adrese domaćina. Pravila napisana za domaćina tada se ponašaju očekivano, a kontejner ostaje na svojoj privatnoj mreži.

Cijena je još jedan pokretni dio s vlastitom konfiguracijom, obradom izvorne adrese i kontrolama pristupa. To je obično jednostavnija podržana granica i često ispravan odgovor kada bi politiku usmjeravanja održavala jedna osoba koja bi mogla otići.

Provjerite promjenu, ne namjeru

Otvorite novu ovlaštenu vezu s javne strane i potvrdite da odgovor izlazi kroz predviđeno sučelje. Zatim provjerite da nepovezani zahtjev koji pokrene kontejner još uvijek slijedi VPN.

Ne ispraznite tablicu veza računala da biste testirali jedno pravilo: postojeći unosi zadržavaju ranije mapiranje, a pražnjenje kvari sve ostalo na domaćinu. Objavljivanje porta definira dosegljivost. Ono ne definira put odgovora. Zapišite odabrani dizajn s njegovim nazivima tablica, da ga sljedeća osoba ne otkriva ponovno tijekom incidenta.

Povezani članci