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