Maabot ang web interface sa loob ng VPN container: piliin ang may-ari ng port

Walang mali sa app at walang mali sa tunnel, at hindi pa rin naglo-load ang dashboard. Kapag tumatakbo ang isang serbisyo gamit ang network_mode: service:vpn, ibinabahagi nito ang network namespace ng VPN container, ibig sabihin, ang listener at ang mga nai-publish na port nito ay pag-aari ng namespace na iyon at hindi ng serbisyo. Tatlong desisyon ang sumusunod: saan nagbibit ang app, aling container ang nag-publish ng port, at gaano kamakitid ang landas ng pamamahala. Ilagay ang mga ito sa maling pagkakasunod-sunod at ang bawat indibidwal na setting ay mukhang tama habang ang kombinasyon ay hindi maaaring gumana.

Sino ang may-ari ng namespace ng port

Sa isang shared namespace, walang nagagawa ang pagdaragdag ng ports: entry sa dependent na serbisyo, at ilang opsyon sa network ay hindi sinusuportahan para dito ayon sa disenyo. Sa halip, i-publish sa container na may-ari ng namespace. Ang container ding iyon ang may address na lumalabas sa host, kaya binabasa ang mapping bilang isang entry at hindi isa sa bawat serbisyo.

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

Pansinin ang address sa kaliwa ng mapping. Ang pagkabit sa 127.0.0.1 ay nagpapanatili ng nai-publish na port sa loopback ng host, na karaniwang kailangan ng isang management interface. Ang pagkabit sa 0.0.0.0 ay naglalantad nito sa bawat interface ng host, at iyon ay ibang desisyon sa seguridad, hindi kaginhawahan.

Hayaang makinig ang app sa lugar kung saan inaasahan ng namespace

Ang listener na nakakabit sa 127.0.0.1 sa loob ng namespace ay maaabot lamang mula sa loob ng namespace na iyon. Ang mga nai-publish na host port ay dumarating mula sa labas, kaya kailangang ikabit ng app ang mas malawak na address upang gumana ang mapping. Ito ay isang linyang pagbabago sa karamihan ng server, at ito mismo ang hakbang na nilalaktawan ng mga tao pagkatapos kopyahin ang gabay sa pagpapatibay na isinulat para sa deployment na walang container.

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

Sinasabi ng listahan ng listener sa loob ng app ang totoo tungkol sa bind address, at ipinapakita ng docker port kung ano ang aktwal na nai-publish ng may-ari. Kung ang una ay nagpapakita ng 127.0.0.1 at ang pangalawa ay nagpapakita ng mapping sa host, natagpuan mo ang hindi pagkakatugma nang hindi hinahawakan ang configuration ng VPN.

Piliin kung paano papasok ang landas ng pamamahala

May tatlong makatwirang kaayusan. I-publish sa VPN container at maabot ito mula sa host o sa lokal na network. Maglagay ng reverse proxy sa harap ng namespace at ibigay sa proxy ang nag-iisang nakalantad na port. O panatilihing maaabot ang dashboard mula sa loob ng namespace lamang sa pamamagitan ng exec session o SSH tunnel, na siyang pinakamaliit na paglalantad at pinakamaliit na kaginhawahan.

Alin ang bagay ay depende sa kung sino at saan kailangan ang interface. Ang isang administrador sa parehong host ay sapat na ang loopback binding. Ang team na umaabot dito sa pamamagitan ng VPN ay kailangan ng sinadyang landas at pinangalanang may-ari. Ang pagpili ng opsyong proxy ay nagbibigay sa iyo ng TLS at access logs, kapalit ng isa pang bahagi na dapat panatilihing napapanahon.

Buksan ang management port nang hindi binubuksan ang lahat

Ang sariling patakaran ng VPN client sa lokal na access o lockdown ay maaaring magtapon ng papasok na kahilingan sa pamamahala kahit na perpektong gumagana ang palabas na tunnel. Payagan ang isang dokumentadong eksepsyon para sa nilalayong pinagmulan at port, pagkatapos ay kumpirmahin na hindi nagbago ang karaniwang proteksyon ng tunnel. Ang patayin ang kill switch upang mag-load ang dashboard ay ipinagpapalit ang tunay na kontrol sa isang tab ng browser.

Iwanang naka-enable ang sariling authentication ng app. Ang pagiging nasa isang stack na konektado sa VPN ay hindi nagbibigay ng awtoridad sa bawat lokal na user o bawat device na makakaabot sa host, at ang admin panel na walang authentication sa likod ng tunnel ay admin panel pa rin na walang authentication.

I-verify mula sa management device, pagkatapos ay i-verify muli mamaya

Subukan mula sa makina na aktwal na mamamahala ng serbisyo, hindi mula sa host, pagkatapos ay i-verify nang hiwalay ang internet path na kailangan ng app. Ang tagumpay sa pamamahala ay nagpapatunay ng isang direksyon at walang sinasabi tungkol sa palabas.

Subukan muli pagkatapos muling likhain ang stack. Ang pinalitan na network owner ay nagbabago ng namespace kung saan kumakabit ang app, at ang URL na gumagana bago ang update ay maaaring hindi na tumuro kahit saan pagkatapos. Isulat ang nai-publish na mapping at ang bind address upang ang susunod na muling pagbuo ay dalawang minutong pagsusuri at hindi paulit-ulit na imbestigasyon.