Să ajungi la o interfață web într-un container VPN: alege proprietarul portului

Aplicația partajează spațiul de nume al VPN, deci portul aparține containerului VPN. Leagă ascultătorul corect, publică pe proprietar și menține calea îngustă.

Nimic nu este greșit la aplicație și nimic nu este greșit la tunel, și totuși tabloul de bord nu se încarcă. Când un serviciu rulează cu network_mode: service:vpn, partajează spațiul de nume de rețea al containerului VPN, ceea ce înseamnă că ascultătorul și porturile publicate aparțin acelui spațiu de nume, nu serviciului. Din asta decurg trei decizii: unde se leagă aplicația, care container publică portul și cât de îngustă este calea de administrare. Pune-le în ordinea greșită și fiecare setare individuală pare corectă, în timp ce combinația nu poate funcționa.

Cine deține spațiul de nume al portului

Într-un spațiu de nume partajat, adăugarea unei intrări ports: la serviciul dependent nu face nimic util, iar mai multe opțiuni de rețea nu sunt acceptate pentru el prin proiectare. Publică în schimb pe containerul care deține spațiul de nume. Același container este și cel a cărui adresă apare pe gazdă, așa că maparea se citește ca o singură intrare, nu una pentru fiecare serviciu.

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

Observă adresa din stânga mapării. Legarea la 127.0.0.1 ține portul publicat pe loopback-ul gazdei, ceea ce de obicei vrea o interfață de administrare. Legarea la 0.0.0.0 îl expune pe fiecare interfață a gazdei, iar asta este o altă decizie de securitate, nu o comoditate.

Fă aplicația să asculte acolo unde spațiul de nume se așteaptă

Un ascultător legat la 127.0.0.1 în interiorul spațiului de nume este accesibil doar din interiorul acelui spațiu. Porturile publicate ale gazdei vin din exterior, deci aplicația trebuie să lege o adresă mai largă pentru ca maparea să funcționeze. Asta este o modificare de o linie pe majoritatea serverelor, și exact acest pas este sărit după ce se copiază un ghid de întărire scris pentru o implementare fără containere.

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

Lista ascultătorilor din aplicație spune adevărul despre adresa de legare, iar docker port arată ce a publicat de fapt proprietarul. Dacă primul arată 127.0.0.1, iar al doilea arată o mapare pe gazdă, ai găsit nepotrivirea fără să atingi configurația VPN.

Alege cum intră calea de administrare

Există trei aranjamente rezonabile. Publică pe containerul VPN și ajunge la el de pe gazdă sau din rețeaua locală. Pune un proxy invers în fața spațiului de nume și dă proxy-ului singurul port expus. Sau ține tabloul de bord accesibil doar din interiorul spațiului de nume printr-o sesiune exec sau un tunel SSH, ceea ce este cea mai mică expunere și cea mai mică comoditate.

Care se potrivește depinde de cine are nevoie de interfață și de unde. Un singur administrator pe aceeași gazdă se mulțumește cu o legare la loopback. O echipă care ajunge la ea prin VPN are nevoie de o cale deliberată și de un proprietar numit. Alegerea opțiunii proxy îți dă TLS și jurnale de acces, cu prețul încă unei componente de întreținut.

Deschide portul de administrare fără a deschide totul

Politica proprie de acces local sau de blocare a clientului VPN poate arunca o cerere de administrare de intrare chiar și în timp ce tunelul de ieșire funcționează perfect. Permite o excepție documentată pentru sursa și portul dorite, apoi confirmă că protecția obișnuită a tunelului a rămas neschimbată. Dezactivarea comutatorului de urgență ca să se încarce un tablou de bord schimbă un control real pe o filă de browser.

Lasă autentificarea proprie a aplicației activată. Faptul că ești într-un stack conectat la VPN nu autorizează fiecare utilizator local și nici fiecare dispozitiv care poate ajunge la gazdă, iar un panou de administrare fără autentificare în spatele unui tunel rămâne un panou fără autentificare.

Verifică de pe dispozitivul de administrare, apoi verifică din nou mai târziu

Testează de pe mașina care va administra efectiv serviciul, nu de pe gazdă, apoi verifică separat calea de internet necesară aplicației. Un succes la administrare dovedește o singură direcție și nu spune nimic despre ieșire.

Testează din nou după ce stackul este recreat. Un proprietar de rețea înlocuit schimbă spațiul de nume la care se atașează aplicația, iar un URL care funcționa înainte de o actualizare poate să nu mai indice nimic după ea. Notează maparea publicată și adresa de legare, ca următoarea reconstrucție să fie o verificare de două minute, nu o investigație repetată.

Articole similare