Gostitelj še naprej odgovarja na SSH, potem ko se dvigne VPN s polnim tunelom, medtem ko storitev, objavljena prek Dockerja na istem stroju, utihne. S poslušalcem ni nič narobe: vsebnik teče, preslikava vrat obstaja in paket prispe. Vsebnik je zdrav in zahteva res pride do njega. Razlika je v tem, od kod se odgovor začne, ko Linux izbere svojo pot, in ta razlika odloči, katero od dveh zasnov spodaj potrebujete.

Sledite tuple skozi ciljni NAT

Vzemite gostitelja na 192.0.2.10, ki objavlja TCP 2222 na vsebnik na 172.30.240.5:22. Zahteva z 198.51.100.25 se prevede, preden doseže vsebnik, in vsebnik odgovori kot 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

Pri odločitvi gostitelja o poti odgovor še vedno nosi izvorni naslov vsebnika. Obratni prevod pozneje obnovi objavljeni tuple, in prav zato je paket videti napačen točno v trenutku, ko se pot izbere.

Zakaj pravilo samo za gostitelja to zgreši

Pravilo, ki izbere tabelo WAN samo za pakete z 192.0.2.10, pokrije lastne demone gostitelja in to posredovani odgovor popolnoma zgreši. Izvorni naslov v odgovoru je 172.30.240.5, ne gostitelj.

Prekomerni popravek je usmeriti vse iz vsebnika skozi WAN, kar prav tako izvzame nepovezane odhodne povezave vsebnika iz VPN. To je drugačna politika od zahtevane in običajno koga pozneje preseneti.

Ujemanje po DNAT je drug hook

Dokumentacija Dockerja o požarnih zidovih ugotavlja, da običajno uporabniško filtriranje vidi cilj po DNAT, zato ujemanje objavljenih vrat 2222 v običajnem pravilu ni isto kot ujemanje vrat 22 vsebnika. Če je prvotni tuple pomemben, uporabite podprti mehanizem prvotnega cilja, namesto da ugibate, katera vrata so vidna.

Ta zmeda s hooki ustvarja pravila, ki so videti pravilna in se nikoli ne ujemajo. Preden prepišete politiko, preverite števce na samem pravilu. Pravilo brez zadetkov vam pove, da se vrednoti nekje, kamor paket nikoli ne prispe.

Zasnova A: odločitev nosite kot stanje povezave

Oznaka povezave lahko prenese odločitev o vstopu skozi prevod, vendar jo je treba vrniti na paket pred iskanjem poti, ki je pomembno. Faze so:

  1. Rezervirajte polje oznake in prednost pravila, ki se ne zaletita v Docker, VPN ali drugega lastnika politike.
  2. Prepoznajte samo predvideno novo povezavo WAN na točki pred DNAT, kjer je sledenje povezavam na voljo.
  3. Zabeležite odločitev na oznako povezave, ne da bi samo prvotno zahtevo silili v tabelo WAN.
  4. V smeri odgovora vrnite na paket pred usmerjanjem samo lastne bite oznake.
  5. Izberite celotno tabelo WAN dovolj zgodaj, da pravilo VPN ne more zmagati prvo.

Ta tabela potrebuje dejanske povezane poti in prehod. Potrebuje tudi definirano vedenje, ko poti ni. Tiho padanje v tunel je najslabši izid, ker je konfiguracija videti še vedno delujoča. Namesto tega odpovejte zaprto in to zabeležite.

Zasnova B: zaključite na gostitelju

Namenoma nastavljen sprednji del na strani gostitelja, kot je proxy TCP ali obratni proxy pred vsebnikom, drži odgovor izvirajoč z naslova gostitelja. Pravila, napisana za gostitelja, se nato obnašajo po pričakovanjih, vsebnik pa ostane v svojem zasebnem omrežju.

Cena je še en gibajoči del z lastno konfiguracijo, obravnavo izvornih naslovov in nadzorom dostopa. Običajno je to preprostejša podprta meja in pogosto je to pravi odgovor, ko bi politiko usmerjanja vzdrževala ena oseba, ki bi lahko odšla.

Preverite spremembo, ne namena

Odprite novo pooblaščeno povezavo z javne strani in potrdite, da odgovor zapusti predvideni vmesnik. Nato preverite, ali nepovezana zahteva, ki jo sproži vsebnik, še vedno sledi VPN.

Ne praznite tabele povezav stroja, da bi preizkusili eno pravilo: obstoječi vnosi obdržijo prejšnje preslikave, praznjenje pa pokvari vse drugo na gostitelju. Objava vrat opredeljuje dosegljivost. Ne opredeljuje poti odgovora. Zapišite izbrano zasnovo z imeni njenih tabel, da je naslednja oseba ne bo morala znova odkrivati med incidentom.

Sorodni članki