Dockeri portide avaldamine ja VPN-i allikad: kaks vastet, mille te kahe silma vahele jätate

Reegel ütleb lubada VPN-i serveri aadress avaldatud teenusele, ja ühendus katkeb ikkagi. See tulemus on tavaline ega ole Dockeri viga. Kaks eraldi vastet on valed: allikas, mille kirjutasite, ei pruugi olla allikas, mille host vastu võtab, ja port, mille kirjutasite, ei pruugi olla port, mida filter näeb. Mõlema parandamine nõuab paketi tee vaatamist teenuse diagrammi asemel.

Müüt: luba VPN-i server ja ongi valmis

Marsruuditud VPN saab säilitada kliendi tunneliaadressi kuni Dockeri hostini. Lüüs, mis teeb allika tõlkimist, võib selle aadressi asendada enda omaga. Mõlemad lahendused on lubatud ja annavad sama kasutajatoimingu jaoks erinevad allikad.

Seega väljend VPN-i serveri IP kirjeldab oletust, mitte vaatlust. Kuni te ei tea, milline kahest lahendusest on teie ees, on reegel oletus.

Allikas: kliendikogu või tõlgitud lüüs

Kontrollige nelja asja järjekorras. Esiteks kliendi aadressikogu, näiteks 10.90.0.0/24. Teiseks, kas lüüs tõlgib seda kogu enne, kui see hostini jõuab. Kolmandaks allikas, mida host ühe uue ühenduse jaoks tegelikult näeb. Neljandaks, kas rakenduse autentimine eristab üksikuid kasutajaid, sest jagatud tõlgitud aadress ei suuda seda.

Kui kogu säilib, jätab reegel, mis vastab ainult lüüsi avalikule aadressile, iga kliendi vahele. Kui lüüs tõlgib meelega, lubab tõlgitud aadressi lubamine sisse iga kasutaja selle taga, mis võib olla vastuvõetav oma sisselogimisega teenuse jaoks ja vastuvõetamatu kõige muu jaoks.

Port: DNAT muudab numbrit, millega sobite

Tavalise Linuxi silla avaldamise korral Docker iptablesiga tõlgitakse hosti vastendus 8443-lt konteineri pordile 443 enne, kui edastusfilter tööle hakkab. Pakett jõuab filtrisse sihtpordiga 443. Reegel, mis vastab selles punktis 8443-le, ei käivitu kunagi, kuigi 8443 on see, mille klient sisestas.

Avaldatud port on endiselt ühenduste jälgimises olemas, seetõttu saab algse sihtkoha seal sobitada, kui seda tõesti vajate.

Otsustage, milline number väljendab kavatsust. Sobitage konteineri porti pärast DNAT-i, kui reegel kaitseb teenust konteineri sees. Sobitage algset sihtkohta conntrack-valikuga, kui reegel peab kirjeldama, mida klient küsis, ja nõustuge täiendava sobivuskuluga ning reeglite järjekorra hoolikusega, mis sellega kaasnevad.

Ahel: DOCKER-USER, mitte INPUT

Dockeri iptablesi juhend paigutab kasutaja edastuspoliitika ahelasse DOCKER-USER, mida hinnatakse enne Dockeri enda edastusreegleid. Hostiteenusest ahelasse INPUT kopeeritud reegel filtreerib hostile adresseeritud liiklust, mitte konteinerisse edastatavat liiklust. See viga annab reegli, mis näeb õige välja ja ei mõjuta konteineri teed.

Hoidke allika vahemik, tegelik sihtport, protokoll ja sissetulev liides samas reeglis koos. Ainult allikapõhine luba iga edastatava sihtkoha jaoks on laiem kui ühe avaldatud teenuse lubamine.

Kontrollige värskete ühendustega

Testige mõlemat suunda uute ühendustega: üks lubatud VPN-i klient ja üks allikas, mis peaks jääma keelatuks. Olemasolev ühenduse olek võib hoida seansi elus pärast poliitika muutmist, seega vana ühendus ei tõesta uue reegli kohta midagi. Seejärel kontrollige vastuse teed, sest konteiner peab ikkagi marsruutima tagasi allikasse, mida ta näeb.

Dockeri iptablesi juhend dokumenteerib ahelate järjekorra ja portide tõlkimise käitumise nende kontrollide taga. Lugege seda enne retsepti kopeerimist ja kinnitage, millist backendi paigaldatud Docker kasutab, sest nftablesi backend integreerib poliitikat teisiti.