Meshnet, Docker in dovoljenje vmes

Dva URL-ja sta lahko v brskalniku vozlišča videti enaka, a za požarni zid pomenita povsem različne stvari. Eden kaže na storitev, ki posluša na gostitelju samem. Drugi kaže na naslov gostitelja, katerega vrata so objavljena v omrežju vsebnikov, kjer korak prevoda preda povezavo drugemu IP-ju. V enakovrednem omrežju, ki nadzoruje dostop do lokalnega omrežja z dovoljenjem za vsako vozlišče, je ta razlika celoten pregled.

Dovoljenje se nanaša na končno točko gostitelja, prevod se nanaša na Docker, prijava pa na aplikacijo. Tri odločitve, tri mesta za pogled.

Sledite cilju po objavi

Vzemite gostitelja Linux z Dockerjem, ki objavi vrata 80 vsebnika na vratih gostitelja 8080. Vozlišče se poveže z omrežnim naslovom gostitelja na 8080, gostitelj povezavo sprejme, prevod cilja pa jo prepiše na mostni naslov vsebnika, običajno nekaj kot 172.17.0.2 na vratih 80.

Ko pravilo pregleda ta tok, je zanimivi cilj vsebnik, ne gostitelj. Politika, ki razmišlja le o »storitvi na tem stroju«, razmišlja o napačnem objektu. Zahteva je pristala na gostitelju, a se dostavlja drugam.

Zato dokumentacija omrežja uvršča vsebnike Docker med vire, ki jih dovoljenje za lokalno omrežje upravlja v Linuxu. Dovoljenje ni sopomenka za običajen vnos na seznamu dovoljenih za VPN in oba nadzora se ne nadomeščata. Eden odloča, ali lahko vozlišče sploh doseže lokalne vire; drugi odloča, katere cilje nosi tunelirana pot.

Odločite, koliko lokalnega dostopa daje dovoljenje

Podelitev dostopa do lokalnega omrežja vozlišču ni odločitev o enem samem vsebniku. Lahko razkrije druge objavljene storitve na istem gostitelju in lahko seže dlje glede na to, kako gostitelj posreduje. Preden kliknete stikalo za eno nadzorno ploščo, pregledajte dejanski obseg.

Nato poglejte, kje Docker objavi vrata. Objava na 0.0.0.0 ustvari poslušalca na vsakem naslovu gostitelja, kar lahko doda običajen vnos LAN poleg omrežnega. Če je zahteva samo omrežje, povežite objavo z določenim naslovom ali vmesnikom, ki ga imate v mislih, in širšo vezavo obravnavajte kot ločeno ugotovitev in ne kot priročnost.

Naj bosta politika posredovanja gostitelja in lastna avtentikacija aplikacije dovolj ozki za storitev. URL, ki je videti zaseben, ni nadzor dostopa, in vsebnik, ki zaupa vsakemu viru v svojem mostnem omrežju, ni zaščiten s tem, da je bilo vozlišče odobreno. Avtentikacija aplikacije je tretja odločitev in edina, ki ve, kdo je uporabnik. Dovoljenje na ravni gostitelja tega znanja ne more dati.

Preizkusite dovoljenje, ne le URL

Z odobrenega vozlišča odprite točno storitev in potrdite, da deluje. Nato poskusite cilj, ki bi moral ostati zavrnjen, in potrdite, da ne deluje. Preizkušanje le srečne poti vam pove, da je bilo dovoljenje dano; ne pove, da je meja tam, kjer mislite.

Ločeno primerjajte storitev, ki je domača gostitelju. Če podatkovna baza posluša na gostitelju in nadzorna plošča teče v vsebniku, sledita različnim potem skozi isto dovoljenje in ju politika posredovanja gostitelja morda ne upravlja enako. Zapišite, kaj je kaj, preden napišete opombo pregleda.

Ne praznite Dockerjevih tabel ali pravil odjemalca omrežja, da bi »ponastavili« dostop. Oba izdelka namestita svojo integracijo politik, njeno brisanje pa ustvari gostitelja, ki je videti delujoč, a obide nadzore, ki ste jih morali oceniti. Če je pravilo videti napačno, ga preberite in spremenite prav to pravilo. Če ne morete pojasniti, kaj pravilo počne, je to ugotovitev, ne razlog za brisanje.

Ugotovitev napišite v izrazih samega sistema

Pomembna je razlika, ki jo izdelek dejansko uveljavlja, ne tista v predlogi pregleda: dovoljenje za doseganje končne točke gostitelja, dovoljenje za doseganje usmerjenih zasebnih virov in dovoljenje za uporabo aplikacije. Objava vrat pusti te tri odločitve točno tam, kjer so bile, in pregledovalec, ki jih obravnava kot eno, bo odobril napačen obseg.

Navedite naslov gostitelja, objavljena vrata, cilj vsebnika in dovoljenje vozlišča v istem stavku. Ta stavek lahko preveri nekdo drug, in prav zato je ugotovitev in ne mnenje.