Экспонирование веб-сервиса за NAT через обратный SSH-туннель

Вопрос или проблема

Я пытаюсь получить доступ к своему домашнему серверу (за резидентским NAT) онлайн через SSH обратный прокси. Домашний сервер является веб-сервером (точнее Onlyoffice Workspace).

На домашнем сервере я могу подтвердить, что веб-сервер работает нормально:

root@workspace:# curl "127.0.0.1/Auth.aspx?refererurl=%2fDefault.aspx"

Теперь хост с публичным IP — это облачный сервер с Coolify (если что, Coolify — это как самохостинговый сервер Heroku). С помощью Coolify я создал сервис, чтобы быть SSH-туннелем через Docker compose:

version: '3.8'
services:
  reverse-ssh-tunnel:
    image: 'linuxserver/openssh-server:latest'
    container_name: reverse-ssh-tunnel
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
      - USER_NAME=webmaster
      - USER_PASSWORD=password
      - PASSWORD_ACCESS=true
      - SUDO_ACCESS=true
      - PUBLIC_KEY_FILE=/config/ssh/authorized_keys
    volumes:
      - './config:/config'
    ports:
      - '8889:2222'
    restart: unless-stopped
    labels:
      - traefik.enable=true
      - traefik.tcp.routers.ssh-tunnel.entrypoints=ssh
      - 'traefik.tcp.routers.ssh-tunnel.rule=HostSNI(`*`)'
      - traefik.tcp.routers.ssh-tunnel.service=ssh-tunnel-svc
      - traefik.tcp.services.ssh-tunnel-svc.loadbalancer.server.port=2222

И установил домен сервиса как https://<MY_DOMAIN>

Далее, из терминала веб-сервера домашнего сервера я могу подключиться к Docker SSH серверу (reverse-ssh-tunnel) на облачном сервере Coolify через:

ssh -R 80:localhost:80 webmaster@1<PUBLIC_IP> -p 8889

Однако, при доступе к https://<MY_DOMAIN> или https://<MY_DOMAIN>/Auth.aspx?refererurl=%2fDefault.aspx после вероятного туннелирования

Выдает внутреннюю ошибку сервера. Что может быть не так с моей настройкой туннеля?

Ответ или решение

Теория

Настройка обратного SSH-туннеля может быть идеальным решением для доступа к сервисам, находящимся за NAT, таких как ваш домашний веб-сервер, на основе Onlyoffice Workspace. Обратный SSH-туннель предоставляется с использованием SSH-соединения, где локальный сервер инициирует туннель через удаленный сервер с публичным IP-адресом, обычно находящимся в облаке.

При использовании обратных туннелей SSH необходимо помнить о нескольких теоретических аспектах. Во-первых, убедитесь, что SSH-сервер на вашей удаленной машине правильным образом сконфигурирован для поддержки туннелей. Это значит, что SSH-сервер должен позволять форвардинг портов с помощью директивы AllowTcpForwarding yes в файле конфигурации SSH-сервера.

Кроме того, при использовании контейнеризированных решений, таких как Docker, важно правильно конфигурировать сетевые соединения, так как Docker по умолчанию не всегда соответствует методу взаимодействия с внешними сетями, что может привести к ошибкам.

Пример

Вы развернули SSH-сервер в контейнере с использованием Docker Compose и настроили его для прослушивания SSH-подключений с интерфейсом на порту 8889. Кроме того, вы настроили Traefik, чтобы управлять трафиком TCP. На первом этапе в конфигурации Traefik вы используете правила на уровне TCP, что является вполне нормальной практикой для SSH-подключений.

Как вы объяснили, ваш SSH-туннель из домашнего сервера до облачного сервера предполагает, что локальный HTTP-сервис (порт 80) может быть доступен через публичную точку входа MY_DOMAIN. Однако в текущей конфигурации вы столкнулись с внутренней ошибкой сервера при попытке доступа к веб-страницам после настроенного туннеля.

Применение

Теперь давайте разберёмся в деталях вашей конфигурации. Ваша основная проблема заключается в неправильной конфигурации обоих ссылок и управления трафиком. Вот шаги по поиску и устранению проблемы:

Проверка SSH туннелей:
Убедитесь, что туннель действительно установлен. Для этого попробуйте запустить команду netstat -tuln на обеих сторонах и убедитесь, что порт 80 действительно открывается на наружной стороне туннеля. Также убедитесь, что на удалённой машине ваш SSH-сервер позволяет переадресацию портов: удостоверьтесь, что AllowTcpForwarding включён в /etc/ssh/sshd_config.
Конфигурация Traefik:
Убедитесь, что Traefik правильно настроен для маршрутизации HTTP(S) трафика через туннель. Так как вы создаёте имеено SSH туннель, должен быть указан HTTP/HTTPS-сервис для последующей маршрутизации трафика внутри контейнера Traefik. Возможно, вам потребуется создать конфигурацию на уровне HTTP для маршрутизации запросов к вашему установленному веб-серверу.
Проверка контейнерной сети:
Убедитесь, что контейнер с туннелем и Traefik имеют доступ к одной сети Docker, чтобы правильно обмениваться данными. Контейнер с веб-сервером на вашей домашней машине также должен быть правильно подключен к вашему туннелю.
Логирование и отладка:
Используйте логи SSH и Traefik для диагностики. Возможно, они укажут на основания внутренней ошибки сервера. Проверьте их на наличие возможных отказов в установке соединений.
Проверка доменов и интерфейсов:
Убедитесь, что домены и сетевые интерфейсы правильно сопоставлены в DNS и настроены в сетевых конфигурациях. Очевидно, что Traefik и туннель должны знать о правильных alias DNS, которые используются в процессе маршрутизации.

Ранее указанные шаги помогут вам точно определить, где и почему конфигурация не работает, и откорректировать туннель для успешного проксирования Onlyoffice через интернет. Предмет вашей ошибки может варьироваться от нехватки разрешений до проблем маршрутизации или неправильно настроенных протоколов на уровне контейнеров.