Atingi retinterfacon ene de VPN-kontenero: elektu la posedanton de la pordo

Nenio malĝustas ĉe la aplikaĵo kaj nenio malĝustas ĉe la tunelo, kaj tamen la panelo ne ŝargiĝas. Kiam servo funkcias kun network_mode: service:vpn, ĝi dividas la retan nomspacon de la VPN-kontenero, kio signifas, ke ĝia aŭskultanto kaj ĝiaj publikigitaj pordoj apartenas al tiu nomspaco, ne al la servo. Tri decidoj sekvas el tio: kie la aplikaĵo ligu sin, kiu kontenero publikigu la pordon, kaj kiom mallarĝa estas la administra vojo. Farigu ilin en la malĝusta ordo kaj ĉiu unuopa agordo aspektas ĝusta, dum la kombinaĵo ne povas funkcii.

Kiu posedas la nomspacon de la pordo

En dividita nomspaco aldoni rikordon ports: al la dependa servo faras nenion utilan, kaj pluraj retaj opcioj ne estas subtenataj por ĝi laŭ la dezajno. Publikigu anstataŭe ĉe la kontenero, kiu posedas la nomspacon. Tiu kontenero ankaŭ estas tiu, kies adreso aperas ĉe la gastiganto, do la mapado legeblas kiel unu rikordo anstataŭ unu por servo.

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

Rimarku la adreson maldekstre de la mapado. Ligi al 127.0.0.1 tenas la publikigitan pordon sur la loopback de la gastiganto, kio kutime estas tio, kion administra interfaco volas. Ligi al 0.0.0.0 elmetas ĝin sur ĉiu gastiganta interfaco, kaj tio estas alia sekureca decido, ne oportuneco.

Igu la aplikaĵon aŭskulti tie, kie la nomspaco atendas

Aŭskultanto ligita al 127.0.0.1 ene de la nomspaco atingeblas nur de ene de tiu nomspaco. Publikigitaj gastigantaj pordoj alvenas de ekstere, do la aplikaĵo devas ligi pli vastan adreson por ke la mapado funkciu. Tio estas unulinia ŝanĝo en la plej multaj serviloj, kaj ĝuste tiun paŝon homoj preterlasas post kiam ili kopiis hardigan gvidilon skribitan por starigo sen konteneroj.

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

La listo de aŭskultantoj ene de la aplikaĵo diras la veron pri la liga adreso, kaj docker port diras, kion la posedanto efektive publikigis. Se la unua montras 127.0.0.1 kaj la dua montras mapadon de la gastiganto, vi trovis la malkongruon sen tuŝi la VPN-agordon.

Elektu kiel la administra vojo envenas

Estas tri raciaj aranĝoj. Publikigu ĉe la VPN-kontenero kaj atingi ĝin de la gastiganto aŭ de la loka reto. Metu inversan prokuran servilon antaŭ la nomspaco kaj donu al la prokuro la solan elmetitan pordon. Aŭ tenu la panelon atingebla nur de ene de la nomspaco per exec-kunsido aŭ SSH-tunelo, kio estas la plej malgranda elmeto kaj la plej malgranda komforto.

Kiu taŭgas dependas de tio, kiu bezonas la interfacon kaj de kie. Unu administranto sur la sama gastiganto estas servita per loopback-ligo. Teamo atinganta ĝin tra la VPN bezonas intencitan vojon kaj nomitan posedanton. Elekti la prokuran opcion donas al vi TLS kaj alirprotokolojn, kontraŭ la kosto de ankoraŭ unu komponanto tenenda ĝisdatigita.

Malfermu la administran pordon sen malfermi ĉion

La propra politiko de loka alirado aŭ ŝloso de la VPN-kliento povas forĵeti envenantan administran peton eĉ dum la elira tunelo funkcias perfekte. Permesu unu dokumentitan escepton por la celata fonto kaj pordo, poste konfirmu, ke la ordinara protekto de la tunelo restas senŝanĝa. Malŝalti la sekurecan ŝaltilon por ŝargi panelon interŝanĝas realan regadon kontraŭ folio en retumilo.

Lasu la propran aŭtentikigon de la aplikaĵo ŝaltita. Esti ene de VPN-ligita stako ne rajtigas ĉiun lokan uzanton nek ĉiun aparaton, kiu povas atingi la gastiganton, kaj administra panelo sen aŭtentikigo malantaŭ tunelo restas administra panelo sen aŭtentikigo.

Kontrolu de la administra aparato, poste rekontrolu pli malfrue

Testu de la maŝino, kiu efektive administros la servon, ne de la gastiganto, kaj poste aparte kontrolu la interretan vojon, kiun la aplikaĵo postulas. Sukceso en administrado pruvas unu direkton kaj diras nenion pri la eliro.

Retestu post kiam la stako estas rekreita. Anstataŭigita reta posedanto ŝanĝas la nomspacon, al kiu la aplikaĵo alkroĉiĝas, kaj URL, kiu funkciis antaŭ ĝisdatigo, povas poste montri al nenio. Notu la publikigitan mapadon kaj la ligan adreson, por ke la sekva rekonstruo estu dumminuta kontrolo anstataŭ ripeta esploro.