Domaćin nastavlja da odgovara na SSH nakon što se podigne VPN sa punim tunelom, a usluga objavljena kroz Docker na istom računaru utihne. Sa slušaocem nije ništa u redu: kontejner radi, mapiranje porta postoji i paket stiže. Kontejner je zdrav i zahtev ga zaista 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. Zahtev sa 198.51.100.25 prevodi se pre 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 tabelu samo za pakete sa 192.0.2.10 pokriva sopstvene demone domaćina i potpuno promašuje ovaj prosleđeni odgovor. Izvorna adresa na odgovoru je 172.30.240.5, a ne domaćin.

Prekomerna korekcija je usmeriti sve iz kontejnera kroz WAN, što takođe 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 firewallu 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 umesto nagađanja koji je port vidljiv.

Ova zbrka oko kuka stvara pravila koja izgledaju ispravno i nikada se ne podudaraju. Proverite brojače na samom pravilu pre nego što prepišete politiku. Pravilo bez ijednog pogotka govori vam da se ocenjuje negde gde paket nikada ne stiže.

Dizajn A: nosite odluku kao stanje veze

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

  1. Rezervišite polje oznake i prioritet pravila koji se ne sudaraju sa Dockerom, VPN-om ili drugim vlasnikom politike.
  2. Identifikujte samo predviđenu novu WAN vezu u tački pre DNAT-a gde je praćenje veza dostupno.
  3. Zabeležite odluku na oznaku veze, bez prisiljavanja samog izvornog zahteva na WAN tabelu.
  4. U smeru odgovora vratite na paket samo sopstvene bitove oznake pre usmeravanja.
  5. Odaberite potpunu WAN tabelu dovoljno rano da VPN pravilo ne može pobediti prvo.

Ta tabela treba stvarne povezane rute i pristupnik. Takođe treba definisano ponašanje kada ruta nedostaje. Tiho propadanje u tunel najgori je ishod, jer konfiguracija još izgleda kao da radi. Umesto toga padnite zatvoreno i zabeležite to.

Dizajn B: završite na domaćinu

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

Cena je još jedan pokretni deo sa sopstvenom konfiguracijom, obradom izvorne adrese i kontrolama pristupa. To je obično jednostavnija podržana granica i često ispravan odgovor kada bi politiku usmeravanja održavala jedna osoba koja bi mogla otići.

Proverite promenu, ne nameru

Otvorite novu ovlašćenu vezu sa javne strane i potvrdite da odgovor izlazi kroz predviđeno sučelje. Zatim proverite da nepovezani zahtev koji pokrene kontejner još uvek sledi VPN.

Ne ispraznite tabelu veza računara da biste testirali jedno pravilo: postojeći unosi zadržavaju ranije mapiranje, a pražnjenje kvari sve ostalo na domaćinu. Objavljivanje porta definiše dosegljivost. Ono ne definiše put odgovora. Zapišite odabrani dizajn sa njegovim nazivima tabela, da ga sledeća osoba ne otkriva ponovo tokom incidenta.

Povezani članci