Pääsy verkkokäyttöliittymään VPN-säilön sisällä: valitse portin omistaja

Sovelluksessa ei ole mitään vialla eikä tunnelissa ole mitään vialla, ja silti kojelauta ei lataudu. Kun palvelu toimii network_mode: service:vpn-asetuksella, se jakaa VPN-säilön verkon nimiavaruuden, mikä tarkoittaa, että sen kuuntelija ja julkaistut portit kuuluvat tuolle nimiavaruudelle eivätkä palvelulle. Siitä seuraa kolme päätöstä: mihin sovellus sitoutuu, mikä säilö julkaisee portin ja kuinka kapea hallintapolku on. Tee ne väärässä järjestyksessä, niin jokainen yksittäinen asetus näyttää oikealta, vaikka yhdistelmä ei voi toimia.

Kuka omistaa portin nimiavaruuden

Jaetussa nimiavaruudessa ports:-merkinnän lisääminen riippuvalle palvelulle ei tee mitään hyödyllistä, eikä useita verkkovaihtoehtoja tueta sille suunnittelun takia. Julkaise sen sijaan säilöllä, joka omistaa nimiavaruuden. Se säilö on myös se, jonka osoite näkyy isännässä, joten yhdistäminen luetaan yhtenä merkintänä eikä yhtenä palvelua kohden.

services:
  vpn:
    image: vpn-client-image
    cap_add: [NET_ADMIN]
    ports:
      - "127.0.0.1:8080:8080"
  app:
    network_mode: "service:vpn"

Huomaa yhdistämisen vasemmalla puolella oleva osoite. Sitominen osoitteeseen 127.0.0.1 pitää julkaistun portin isännän loopbackissa, mitä hallintakäyttöliittymä yleensä haluaa. Sitominen osoitteeseen 0.0.0.0 paljastaa sen jokaisessa isännän liitännässä, ja se on eri tietoturvapäätös, ei mukavuus.

Anna sovelluksen kuunnella siellä, missä nimiavaruus odottaa

Nimiavaruuden sisällä osoitteeseen 127.0.0.1 sidottu kuuntelija on tavoitettavissa vain sen nimiavaruuden sisältä. Julkaistut isännän portit tulevat ulkopuolelta, joten sovelluksen on sidottava leveämpi osoite, jotta yhdistäminen toimii. Se on useimmissa palvelimissa yhden rivin muutos, ja juuri se vaihe ohitetaan, kun on kopioitu koventamisohje, joka on kirjoitettu ilman säilöjä tehtävää käyttöönottoa varten.

docker compose exec app ss -lntp
docker port vpn
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/

Sovelluksen sisäinen kuuntelijaluettelo kertoo totuuden sidontaosoitteesta, ja docker port kertoo, mitä omistaja todella julkaisi. Jos ensimmäinen näyttää 127.0.0.1 ja toinen näyttää isännän yhdistämisen, olet löytänyt epäsuhdan koskematta VPN-määritykseen.

Valitse, miten hallintapolku tulee sisään

Järjestelyjä on kolme järkevää. Julkaise VPN-säilöllä ja saavuta se isännästä tai lähiverkosta. Laita käänteinen välityspalvelin nimiavaruuden eteen ja anna välityspalvelimelle ainoa paljastettu portti. Tai pidä kojelauta tavoitettavissa vain nimiavaruuden sisältä exec-istunnon tai SSH-tunnelin kautta, mikä on pienin altistus ja vähin mukavuus.

Sopivin riippuu siitä, kuka käyttöliittymää tarvitsee ja mistä. Yksi ylläpitäjä samalla isännällä tulee toimeen loopback-sidonnalla. Tiimi, joka saavuttaa sen VPN:n kautta, tarvitsee harkitun polun ja nimetyn omistajan. Välityspalvelinvaihtoehto tuo sinulle TLS:n ja käyttölokit, mutta vaatii vielä yhden komponentin pidettäväksi ajan tasalla.

Avaa hallintaportti avaamatta kaikkea

VPN-asiakkaan oma paikalliskäyttö- tai lukituskäytäntö voi pudottaa saapuvan hallintapyynnön, vaikka lähtevä tunneli toimii moitteettomasti. Salli yksi dokumentoitu poikkeus aiottua lähdettä ja porttia varten ja vahvista sitten, että tunnelin tavallinen suoja on ennallaan. Hätäkatkaisimen poistaminen käytöstä kojelaudan lataamiseksi vaihtaa todellisen hallinnan selaimen välilehteen.

Jätä sovelluksen oma todennus päälle. VPN:ään kytketyn pinon sisällä oleminen ei valtuuta jokaista paikallista käyttäjää eikä jokaista laitetta, joka pääsee isäntään, ja tunnistamaton ylläpitopaneeli tunnelin takana on edelleen tunnistamaton ylläpitopaneeli.

Vahvista hallintalaitteesta ja vahvista myöhemmin uudelleen

Testaa koneelta, joka todella hallitsee palvelua, älä isännältä, ja vahvista sitten erikseen sovelluksen vaatima internetpolku. Hallinnan onnistuminen todistaa yhden suunnan eikä kerro lähtevästä liikenteestä mitään.

Testaa uudelleen, kun pino on luotu uudelleen. Vaihdettu verkon omistaja muuttaa nimiavaruutta, johon sovellus kiinnittyy, ja ennen päivitystä toiminut URL voi sen jälkeen osoittaa tyhjään. Kirjoita julkaistu yhdistäminen ja sidontaosoite muistiin, jotta seuraava uudelleenrakennus on kahden minuutin tarkistus eikä toistettu tutkinta.