Достъп до уеб интерфейс вътре в контейнер за VPN: изберете собственика на порта

Приложението споделя именното пространство на VPN, така че портът принадлежи на контейнера за VPN. Обвържете слушателя правилно, публикувайте върху собственика, дръжте пътя тесен.

С приложението няма нищо сбъркано и с тунела няма нищо сбъркано, а таблото все още не се зарежда. Когато услуга работи с network_mode: service:vpn, тя споделя мрежовото именно пространство на контейнера за VPN, което означава, че нейният слушател и публикуваните ѝ портове принадлежат на това именно пространство, а не на услугата. Оттук следват три решения: къде приложението се обвързва, кой контейнер публикува порта и колко тесен е пътят за управление. Направете ги в грешен ред и всяка отделна настройка изглежда вярна, докато комбинацията не може да работи.

Кой притежава именното пространство на порта

При споделено именно пространство добавянето на запис ports: към зависимата услуга не прави нищо полезно, а няколко мрежови опции не се поддържат за нея по дизайн. Вместо това публикувайте върху контейнера, който притежава именното пространство. Този контейнер е и този, чийто адрес се появява на хоста, така че съпоставянето се чете като един запис, а не по един на услуга.

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

Обърнете внимание на адреса отляво на съпоставянето. Обвързването към 127.0.0.1 оставя публикувания порт на loopback на хоста, което обикновено е това, което иска интерфейсът за управление. Обвързването към 0.0.0.0 го излага на всеки интерфейс на хоста и това е различно решение за сигурност, а не удобство.

Накарайте приложението да слуша там, където именното пространство очаква

Слушател, обвързан към 127.0.0.1 вътре в именното пространство, е достъпен само отвътре в него. Публикуваните портове на хоста идват отвън, така че приложението трябва да се обвърже към по-широк адрес, за да работи съпоставянето. Това е промяна в един ред в повечето сървъри и точно тази стъпка се пропуска след копиране на ръководство за затягане, написано за разгръщане без контейнер.

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

Списъкът на слушателите вътре в приложението казва истината за адреса на обвързване, а docker port показва какво всъщност е публикувал собственикът. Ако първото показва 127.0.0.1, а второто показва съпоставяне на хоста, намерили сте несъответствието, без да пипате конфигурацията на VPN.

Изберете как пътят за управление да влиза

Има три разумни подредби. Публикувайте върху контейнера за VPN и го достигайте от хоста или от локалната мрежа. Поставете обратен прокси пред именното пространство и дайте на проксито единствения открит порт. Или дръжте таблото достъпно само отвътре в именното пространство чрез exec сесия или SSH тунел, което е най-малката експозиция и най-малкото удобство.

Кой вариант пасва зависи от това кой има нужда от интерфейса и откъде. Един администратор на същия хост се обслужва от обвързване към loopback. Екип, който го достига през VPN, се нуждае от обмислен път и посочен собственик. Изборът на прокси варианта ви дава TLS и логове за достъп, срещу още един компонент, който да поддържате актуален.

Отворете порта за управление, без да отваряте всичко

Собствената политика за локален достъп или блокировка на VPN клиента може да отхвърли входяща заявка за управление, дори докато изходящият тунел работи безупречно. Разрешете едно документирано изключение за предвидения източник и порт, после потвърдете, че обичайната защита на тунела не е променена. Изключването на аварийния прекъсвач, за да се зареди табло, разменя реален контрол срещу един раздел в браузъра.

Оставете собствената автентикация на приложението включена. Да си в стек, свързан с VPN, не оторизира всеки локален потребител или всяко устройство, което може да достигне хоста, а панел за администриране без автентикация зад тунел си остава панел без автентикация.

Проверете от устройството за управление, после проверете отново по-късно

Тествайте от машината, която действително ще управлява услугата, не от хоста, и след това проверете отделно интернет пътя, който приложението изисква. Успехът в управлението доказва една посока и не казва нищо за изходящия трафик.

Тествайте отново след пресъздаване на стека. Сменен собственик на мрежата променя именното пространство, към което приложението се прикачва, а URL, който е работил преди ъпдейт, може след него да не сочи никъде. Запишете публикуваното съпоставяне и адреса на обвързване, за да е следващото преизграждане проверка за две минути, а не повторно разследване.

Подобни статии