rsync přes VPN: port démonu 873 versus režim SSH

Povolení TCP 873 na rozhraní tunelu neprotlačí rsync přes OpenVPN, a nepřiměje protější stranu přijmout modul. Tunel nese vnitřní spojení, jehož pravidla protokolu a cíle zůstávají přesně taková, jaká byla. První otázka tedy není, který port otevřít, ale jaký druh spojení rsync navazuje. Vše níže předpokládá, že tunel už běží a sporná je pouze vnitřní služba.

Určete, jaké spojení rsync skutečně navazuje

Vzdálený argument v příkazu obvykle odpoví na tuto otázku dřív než jakákoli změna firewallu. Dvojtečka dvakrát nebo schéma URL volí démona, zatímco jediná dvojtečka za názvem hostitele volí vzdálený shell. Čtěte argument, který skutečně spouštíte, ne ten z příkladu v dokumentaci.

Výslovná volba vzdáleného shellu může odpověď znovu změnit, protože rsync říká, který program má pro transport spustit. Čtěte celý příkazový řádek včetně zděděných obalových skriptů, ne jen část s hostitelem.

Režim démonu: adresa pro vazbu, modul a port

V syntaxi démonu segment cesty pojmenovává nakonfigurovaný modul, ne adresář na disku. Heslo modulu se kontroluje až po přijetí spojení a modul může být navíc jen pro čtení nebo skrytý z výpisu. Toto pořadí je důležité při čtení chyby, protože odmítnuté spojení a odmítnutý modul jsou selhání ve dvou různých fázích. Ani jedna zpráva vám neřekne nic o tunelu samotném.

Samostatného démona lze v konfiguračním souboru připoutat k adrese tunelu, což ho udrží mimo veřejné rozhraní bez jakéhokoli pravidla firewallu. Hodnota musí existovat v okamžiku, kdy se démon váže, a posluchač aktivovaný socketem nebo řízený inetd ji může zcela ignorovat.

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

Pak testujte proti soukromé adrese, ne proti veřejnému jménu. Veřejné jméno hostitele se přeloží na adresu WAN a jde jinou cestou, i když jeden stroj odpovídá na obojí.

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

Režim vzdáleného shellu: přenos nese SSH

S jedinou dvojtečkou rsync spustí program vzdáleného shellu a mluví jeho protokolem přes tento kanál, takže jediná dosažitelná služba je SSH na tom portu, na kterém server poslouchá. Démon rsync nikdy neběží, port 873 je irelevantní a rozhodnutí o přístupu se stává rozhodnutím o účtu SSH. Vzdálená cesta je pak skutečná cesta v souborovém systému, kterou interpretuje shell na druhé straně. Proto změna firewallu zaměřená na 873 pro tento režim neudělá vůbec nic.

Takový návrh potřebuje oprávněný účet a ověření klíče hostitele, a dědí vlastní politiku ověřování SSH. Často je to lepší volba, když přenos musí projít nedůvěryhodnou sítí, protože šifrování patří protokolu, který byl pro to postaven. Démon s výzvou k zadání hesla není totéž.

Otevřete jen cestu, kterou jste si vybrali

Když je režim stanoven, povolte jedinou vnitřní službu na jediném rozhraní, které nese tunel. Zužte pravidlo podle rozhraní, fondu zdrojů a cílové adresy, aby ho pozdější změna výchozího zamítnutí nemohla tiše rozšířit. Poté zkontrolujte pořadí pravidel, protože povolující pravidlo dříve v řetězu dělá úzké pravidlo jen na ozdobu.

Pokud démon běží na stroji za VPN bránou, a ne na bráně samotné, brána potřebuje také cestu pro předávání a cíl potřebuje vlastní oprávnění a zpětnou trasu. Otevření portu jen na bráně vytvoří spojení, které je přijato a pak nikam nevede.

Ověřte z klienta se stejným režimem a cílem, které hodláte používat v produkci. Úspěšný výpis prokazuje posluchače, trasu i pravidlo společně; vypršení času ukazuje na cestu a odmítnutí na posluchače.

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