Domaćin nastavlja odgovarati na SSH nakon što se podigne VPN s 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 zahtjev 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. Zahtjev sa 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 tabelu samo za pakete sa 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 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 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 sa nula pogodaka 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. Rezervišite 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 tabelu.
  4. U smjeru odgovora vratite na paket samo vlastite bitove oznake prije usmjeravanja.
  5. Odaberite potpunu WAN tabelu dovoljno rano da VPN pravilo ne može pobijediti prvo.

Ta tabela 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 neka padne 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 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 definira dosegljivost. Ono ne definira put odgovora. Zapišite odabrani dizajn s njegovim nazivima tabela, da ga sljedeća osoba ne otkriva ponovno tokom incidenta.

Povezani članci