Meshnet, Docker i dopuštenje između njih

Dva URL-a mogu izgledati jednako iz preglednika čvora, a značiti sasvim različite stvari za vatrozid. Jedan pokazuje na uslugu koja sluša na samom hostu. Drugi pokazuje na adresu hosta čiji je port objavljen u mrežu kontejnera, gdje korak prijevoda predaje vezu drugom IP-u. Na mreži čvor-do-čvora koja kontrolira pristup lokalnoj mreži dopuštenjem po čvoru, ta razlika je cijeli pregled.

Dopuštenje se odnosi na krajnju točku hosta, prijevod se odnosi na Docker, a prijava se odnosi na aplikaciju. Tri odluke, tri mjesta za pogledati.

Slijedite odredište nakon objave

Uzmite Linux Docker host koji objavljuje port 80 kontejnera na portu hosta 8080. Čvor se povezuje na mrežnu adresu hosta na 8080, host prihvaća vezu, a prijevod odredišta je prepisuje prema adresi mosta kontejnera, obično nešto poput 172.17.0.2 na portu 80.

Dok pravilo pregledava taj tok, zanimljivo odredište je kontejner, a ne host. Politika koja zaključuje samo o «usluzi na ovom stroju» zaključuje o pogrešnom objektu. Zahtjev je sletio na host, ali se dostavlja negdje drugdje.

Zato dokumentacija mreže ubraja Docker kontejnere među resurse kojima dopuštenje lokalne mreže upravlja na Linuxu. Dopuštenje nije sinonim za običan unos na popisu dopuštenja VPN-a i ta se dva mehanizma ne zamjenjuju. Jedan odlučuje može li čvor uopće dosegnuti lokalne resurse; drugi odlučuje koja odredišta nosi tunelirana ruta.

Odredite koliko lokalnog pristupa dopuštenje daje

Davanje pristupa lokalnoj mreži čvoru nije odluka o jednom kontejneru. Ono može izložiti druge objavljene usluge na istom hostu i može dosegnuti dalje ovisno o tome kako host prosljeđuje. Pregledajte stvarni opseg prije nego što kliknete prekidač za jednu nadzornu ploču.

Zatim pogledajte gdje Docker objavljuje port. Objava na 0.0.0.0 stvara slušatelja na svakoj adresi hosta, što može dodati običan LAN unos uz mrežni. Ako je uvjet samo mreža, vežite objavu na određenu adresu ili sučelje koje želite i tretirajte šire vezanje kao zaseban nalaz, a ne kao pogodnost.

Držite politiku prosljeđivanja hosta i vlastitu autentifikaciju aplikacije dovoljno uskima za uslugu. URL koji izgleda privatno nije kontrola pristupa, a kontejner koji vjeruje svakom izvoru na svojoj mreži mosta nije zaštićen činjenicom da je čvor odobren. Autentifikacija aplikacije treća je odluka i jedina zna tko je korisnik. Dopuštenje na razini hosta ne može pružiti to znanje.

Testirajte dopuštenje, ne samo URL

S odobrenog čvora otvorite točnu uslugu i potvrdite da radi. Zatim pokušajte odredište koje bi trebalo ostati odbijeno i potvrdite da ne radi. Testiranje samo sretnog puta govori vam da je dopuštenje dano; ne govori vam da je granica ondje gdje mislite.

Zasebno usporedite uslugu koja je izvorno na hostu. Ako baza podataka sluša na hostu, a nadzorna ploča radi u kontejneru, one slijede različite putove kroz isto dopuštenje i možda njima ne upravlja politika prosljeđivanja hosta na isti način. Zabilježite što je što prije pisanja bilješke o pregledu.

Ne ispraznite Dockerove tablice ni pravila mrežnog klijenta da biste «resetirali» pristup. Oba proizvoda instaliraju vlastitu integraciju politike, a njezino brisanje stvara host koji izgleda da radi dok zaobilazi kontrole koje ste trebali procijeniti. Ako pravilo izgleda pogrešno, pročitajte ga i promijenite to jedno pravilo. Ako ne možete objasniti što pravilo radi, to je nalaz, a ne razlog da ga izbrišete.

Napišite nalaz terminima samog sustava

Važna je razlika koju proizvod stvarno provodi, a ne ona iz predloška za pregled: dopuštenje za dosezanje krajnje točke hosta, dopuštenje za dosezanje usmjerenih privatnih resursa i dopuštenje za korištenje aplikacije. Objava porta ostavlja te tri odluke točno ondje gdje su bile, a pregledatelj koji ih tretira kao jednu odobrit će pogrešan opseg.

Navedite adresu hosta, objavljeni port, odredište kontejnera i dopuštenje čvora u istoj rečenici. Ta je rečenica provjerljiva od nekoga drugoga i to je čini nalazom, a ne mišljenjem.