Ná í vefflöt inni í VPN-gámi: veldu eiganda gáttarinnar

Ekkert er að forritinu og ekkert er að göngunum, en stjórnborðið hleðst samt ekki. Þegar þjónusta keyrir með network_mode: service:vpn, deilir hún netnafnrými VPN-gámsins, sem þýðir að hlustarinn og birtar gáttir hennar tilheyra því nafnrými en ekki þjónustunni. Þrjár ákvarðanir fylgja: hvar forritið tengist, hvaða gámur birtir gáttina og hversu þröng slóð stjórnunarinnar er. Setjið þær í ranga röð og hver einstök stilling virðist rétt á meðan samsetningin getur ekki virkað.

Hver á nafnrými gáttarinnar

Í deildu nafnrými gerir það ekkert gagn að bæta ports: færslu við háðu þjónustuna, og nokkrir netvalkostir eru ekki studdir fyrir hana að hönnun. Birtið í staðinn á gáminum sem á nafnrýmið. Sá gámur er líka sá sem heimilisfang hans birtist á hýsilnum, svo vörpunin er lesin sem ein færsla en ekki ein fyrir hverja þjónustu.

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

Takið eftir heimilisfanginu vinstra megin við vörpunina. Tenging við 127.0.0.1 heldur birtu gáttinni á loopback hýsilsins, sem stjórnviðmót vill venjulega. Tenging við 0.0.0.0 afhjúpar hana á hverju viðmóti hýsilsins, og það er önnur öryggisákvörðun, ekki þægindi.

Látið forritið hlusta þar sem nafnrýmið býst við því

Hlustari sem er tengdur við 127.0.0.1 inni í nafnrýminu er aðeins aðgengilegur innan þess nafnrýmis. Birtar hýsilgáttir koma að utan, svo forritið verður að tengjast víðara heimilisfangi til að vörpunin virki. Þetta er einnar línu breyting á flestum þjónum, og þetta er einmitt skrefið sem fólk sleppir eftir að hafa afritað herðsluleiðbeiningar sem skrifaðar eru fyrir uppsetningu án gáma.

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

Hlustaralistinn inni í forritinu segir sannleikann um tengingarheimilisfangið, og docker port segir hvað eigandinn birti í raun. Ef sá fyrri sýnir 127.0.0.1 og sá seinni sýnir vörpun á hýsil, þá hafið þið fundið misræmið án þess að snerta VPN-stillinguna.

Veldu hvernig stjórnunarslóðin kemst inn

Þrjár sanngjarnar ráðstafanir eru til. Birtið á VPN-gáminum og náið í hann af hýsilnum eða staðarnetinu. Setjið öfugt milliþjón fyrir framan nafnrýmið og gefið milliþjóninum eina opnu gáttina. Eða haldið stjórnborðinu aðgengilegu aðeins innan nafnrýmisins í gegnum exec-lotu eða SSH-göng, sem er minnsta afhjúpunin og minnst þægindin.

Hvað hentar fer eftir því hver þarf viðmótið og hvaðan. Einn stjórnandi á sama hýsil fær sér loopback-tengingu. Teymi sem nær í hana gegnum VPN þarf yfirvegaða slóð og nafngreindan eiganda. Að velja milliþjónsvalkostinn færir þér TLS og aðgangsskrár, gegn kostnaði við eina íhlut til viðbótar sem halda þarf uppfærðri.

Opnið stjórngáttina án þess að opna allt

Eigin stefna VPN-biðlarans um staðbundinn aðgang eða læsingu getur hent út komandi stjórnunarbeiðni, jafnvel þótt útgangsgöngin virki fullkomlega. Leyfið eina skráða undantekningu fyrir fyrirhugaða uppsprettu og gátt og staðfestið síðan að venjuleg vernd gangnanna sé óbreytt. Að slökkva á neyðarrofanum til að láta stjórnborð hlaðast skiptir raunverulegri stjórn fyrir flipa í vafranum.

Látið eigin auðkenningu forritsins vera virka. Að vera inni í VPN-tengdum stakkri auðkennir ekki hvern staðbundinn notanda né hvert tæki sem nær í hýsilinn, og stjórnborð án auðkenningar bak við göng er enn stjórnborð án auðkenningar.

Sannprófið frá stjórntækinu og sannprófið svo aftur síðar

Prófið frá vélinni sem á í raun að stjórna þjónustunni, ekki frá hýsilnum, og sannprófið svo nettengisleið forritsins sérstaklega. Árangur í stjórnun sannar aðra átt og segir ekkert um útganginn.

Prófið aftur eftir að stakkurinn hefur verið endurskapaður. Skiptur neteigandi breytir nafnrýminu sem forritið tengist, og slóð sem virkaði fyrir uppfærslu getur eftir hana ekki vísað neitt. Skrifið niður birtu vörpunina og tengingarheimilisfangið svo næsta endurbygging verði tveggja mínútna staðfesting í stað endurtekinnar rannsóknar.