rsync oor die VPN: daemon-poort 873 teenoor SSH-modus

As jy TCP 873 op die tonnel-koppelvlak toelaat, stuur dit nie rsync deur OpenVPN, en dit maak ook nie dat die ander kant die module aanvaar nie. ’n Tonnel dra ’n binneste verbinding waarvan die protokol- en bestemmingsreëls presies bly soos hulle was. Die eerste vraag is dus nie watter poort om oop te maak nie, maar watter soort verbinding rsync maak. Alles hieronder aanvaar dat die tonnel reeds op is en net die binneste diens nog onseker is.

Bepaal watter verbinding rsync werklik maak

Die remote-argument in die opdrag beantwoord gewoonlik daardie vraag voor enige firewall-verandering. ’n Dubbele dubbelpunt of ’n URL-skema kies die daemon, terwyl ’n enkele dubbelpunt ná ’n gasheernaam ’n remote shell kies. Lees die argument wat jy werklik gebruik, nie dié in die dokumentasie-voorbeeld nie.

’n Eksplisiete remote-shell-opsie kan die antwoord weer verander, want dit sê vir rsync watter program om vir die vervoer te begin. Lees die hele opdragreël, insluitend geërfde wrapper-skripte, nie net die gasheerdeel nie.

Daemon-modus: bindadres, module en poort

In daemon-sintaksis wys die padsegment na ’n gekonfigureerde module, nie na ’n gids op skyf nie. ’n Module-wagwoord word eers nagegaan nadat die verbinding aanvaar is, en die module kan boonop net-lees of van die lys versteek wees. Daardie volgorde maak saak wanneer jy ’n fout lees, want ’n geweierde verbinding en ’n verwerpte module is mislukkings in twee verskillende stadiums. Nie een van die boodskappe sê iets oor die tonnel self nie.

’n Selfstandige daemon kan in sy konfigurasielêer aan die tonneladres vasgepen word, wat hom sonder enige firewall-reël van die openbare koppelvlak hou. Die waarde moet bestaan wanneer die daemon bind, en ’n socket-geaktiveerde of inetd-bestuurde luisteraar kan dit heeltemal ignoreer.

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

Toets dan teen die private adres eerder as die openbare naam. ’n Openbare gasheernaam los op na ’n WAN-adres en volg ’n ander pad, selfs wanneer een masjien op albei antwoord.

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

Remote-shell-modus: SSH dra die oordrag

Met ’n enkele dubbelpunt begin rsync ’n remote-shell-program en praat sy protokol oor daardie kanaal, so die enigste bereikbare diens is SSH op watter poort die bediener ook al luister. Die rsync-daemon loop nooit nie, poort 873 is irrelevant, en die toegangsbesluit word ’n SSH-rekeningbesluit. Die remote-pad is dan ’n werklike lêerstelselpad wat deur die shell aan die ander kant vertolk word. Daarom doen ’n firewall-verandering gerig op 873 heeltemal niks vir hierdie modus nie.

Daardie ontwerp vereis ’n gemagtigde rekening en verifikasie van die gasheersleutel, en dit erf SSH se eie verifikasiebeleid. Dit is dikwels die beter keuse wanneer die oordrag ’n onbetroubare netwerk moet oorsteek, want die enkripsie behoort aan ’n protokol wat daarvoor gebou is. ’n Daemon met ’n wagwoordprompt is nie dieselfde ding nie.

Maak net die pad oop wat jy gekies het

Sodra die modus vasgestel is, laat die een binneste diens toe op die een koppelvlak wat die tonnel dra. Beperk die reël volgens koppelvlak, bronpoel en bestemmingsadres, sodat ’n latere standaard-weieringsverandering dit nie stilweg kan verbreed nie. Hersien daarna die reëlvolgorde, want ’n toegeeflike reël vroeër in die ketting maak die noue een bloot versierend.

As die daemon op ’n masjien agter die VPN-grendel loop eerder as op die grendel self, het die grendel ook ’n doorstuurpad nodig en die teiken sy eie toestemming en terugroete. Om die poort net op die grendel oop te maak, lewer ’n verbinding wat aanvaar word en dan nêrens heen gaan nie.

Verifieer vanaf die kliënt met dieselfde modus en bestemming wat jy in produksie wil gebruik. ’n Suksesvolle lys bewys die luisteraar, die roete en die reël saam; ’n tydsverloop wys na die pad, en ’n weiering wys na die luisteraar.

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