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