rsync через VPN: порт демона 873 против режима SSH

Разрешение TCP 873 на интерфейсе туннеля не проталкивает rsync через OpenVPN, и не заставляет удалённую сторону принять модуль. Туннель несёт внутреннее соединение, правила протокола и назначения которого остаются точно такими, какими были. Поэтому первый вопрос — не какой порт открыть, а какое соединение устанавливает rsync. Всё ниже предполагает, что туннель уже поднят и под сомнением только внутренняя служба.

Определите, какое соединение rsync действительно устанавливает

Удалённый аргумент в команде обычно отвечает на этот вопрос ещё до любого изменения межсетевого экрана. Двойное двоеточие или схема URL выбирают демон, а одиночное двоеточие после имени хоста выбирает удалённую оболочку. Читайте аргумент, который вы действительно запускаете, а не тот, что в примере из документации.

Явный параметр удалённой оболочки может снова изменить ответ, потому что он говорит rsync, какую программу запускать для транспорта. Читайте всю командную строку, включая унаследованные скрипты-обёртки, а не только часть с хостом.

Режим демона: адрес привязки, модуль и порт

В синтаксисе демона сегмент пути называет настроенный модуль, а не каталог на диске. Пароль модуля проверяется только после того, как соединение принято, и модуль может дополнительно быть только для чтения или скрытым из списка. Этот порядок важен при чтении ошибки, потому что отклонённое соединение и отклонённый модуль — сбои на двух разных этапах. Ни одно из сообщений ничего не говорит о самом туннеле.

Отдельный демон можно привязать к адресу туннеля в его файле конфигурации, что удерживает его вне публичного интерфейса без единого правила межсетевого экрана. Значение должно существовать в момент привязки демона, а слушатель, запускаемый сокетом или управляемый inetd, может полностью его игнорировать.

address = 10.44.0.1
port = 873
[archive]
    path = /srv/archive
    read only = yes

Затем проверяйте по частному адресу, а не по публичному имени. Публичное имя хоста разрешается в адрес WAN и идёт другим путём, даже если одна машина отвечает на оба.

rsync --list-only rsync://10.44.0.1/archive/

Режим удалённой оболочки: SSH несёт передачу

С одним двоеточием rsync запускает программу удалённой оболочки и говорит её протоколом по этому каналу, поэтому единственная доступная служба — SSH на любом порту, который слушает сервер. Демон rsync никогда не работает, порт 873 не имеет значения, а решение о доступе становится решением об учётной записи SSH. Удалённый путь тогда — настоящий путь файловой системы, который интерпретирует оболочка на той стороне. Поэтому изменение межсетевого экрана, нацеленное на 873, для этого режима не делает ровно ничего.

Такой подход требует авторизованной учётной записи и проверки ключа хоста, и наследует собственную политику аутентификации SSH. Часто это лучший выбор, когда передача должна пройти через недоверенную сеть, потому что шифрование принадлежит протоколу, созданному для этого. Демон с запросом пароля — не то же самое.

Откройте только выбранный путь

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

Если демон работает на машине за VPN-шлюзом, а не на самом шлюзе, шлюзу тоже нужен путь пересылки, а цели — собственное разрешение и обратный маршрут. Открытие порта только на шлюзе даёт соединение, которое принимается, а затем никуда не приводит.

Проверьте с клиента в том же режиме и с тем же назначением, которые собираетесь использовать в рабочей среде. Успешный список доказывает слушатель, маршрут и правило вместе; истечение времени указывает на путь, а отказ — на слушатель.

ufw allow in on tun0 from 10.44.0.0/24 to 10.44.0.1 port 873 proto tcp
ss -ltnp | grep 873