rsync över VPN: daemonport 873 kontra SSH-läge

Att tillåta TCP 873 på tunnelns gränssnitt knuffar inte rsync genom OpenVPN, och det får inte heller den andra änden att acceptera modulen. En tunnel bär en inre förbindelse vars protokoll- och destinationsregler förblir exakt som de var. Den första frågan är därför inte vilken port som ska öppnas, utan vilken typ av förbindelse rsync skapar. Allt nedan förutsätter att tunneln redan är uppe och att bara den inre tjänsten fortfarande är oklar.

Avgör vilken förbindelse rsync faktiskt skapar

Fjärrargumentet i kommandot svarar vanligtvis på den frågan före varje brandväggsändring. Ett dubbelt kolon eller ett URL-schema väljer daemonen, medan ett enda kolon efter ett värdnamn väljer ett fjärrskal. Läs det argument du faktiskt kör, inte det i dokumentationsexemplet.

Ett uttryckligt fjärrskalsalternativ kan ändra svaret igen, eftersom det talar om för rsync vilket program som ska startas för transporten. Läs hela kommandoraden, inklusive ärvda wrapper-skript, inte bara värddelen.

Daemonläge: bindningsadress, modul och port

I daemonsyntaxen namnger sökvägssegmentet en konfigurerad modul, inte en katalog på disken. Ett modullösenord kontrolleras först efter att anslutningen har accepterats, och modulen kan dessutom vara skrivskyddad eller dold från listningen. Den ordningen spelar roll när du läser ett fel, eftersom en avvisad anslutning och en avvisad modul är fel i två olika steg. Ingen av meddelandena berättar något om själva tunneln.

En fristående daemon kan fästas vid tunneladressen i sin konfigurationsfil, vilket håller den borta från det offentliga gränssnittet utan någon brandväggsregel. Värdet måste finnas när daemonen binder, och en socketaktiverad eller inetd-styrd lyssnare kan ignorera det helt.

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

Testa sedan mot den privata adressen i stället för det offentliga namnet. Ett offentligt värdnamn löses till en WAN-adress och går en annan väg, även när en enda maskin svarar på båda.

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

Fjärrskalsläge: SSH bär överföringen

Med ett enda kolon startar rsync ett fjärrskalsprogram och talar dess protokoll över den kanalen, så den enda tjänst som går att nå är SSH på vilken port servern än lyssnar på. rsync-daemonen körs aldrig, port 873 är irrelevant och åtkomstbeslutet blir ett SSH-kontobeslut. Fjärrvägen är då en verklig filsökväg som skalet på andra sidan tolkar. Det är därför en brandväggsändring riktad mot 873 inte gör någonting alls för det här läget.

Den konstruktionen behöver ett auktoriserat konto och verifiering av värdnyckeln, och den ärver SSH:s egen autentiseringspolicy. Det är ofta det bättre valet när överföringen måste korsa ett otillförlitligt nätverk, eftersom krypteringen tillhör ett protokoll som byggdes för det. En daemon med lösenordsfråga är inte samma sak.

Öppna bara den väg du valde

När läget är fastställt, tillåt den enda inre tjänsten på det enda gränssnitt som bär tunneln. Begränsa regeln efter gränssnitt, källpool och destinationsadress så att en senare standardavvisning inte tyst kan vidga den. Gå igenom regelordningen efteråt, eftersom en tillåtande regel tidigare i kedjan gör den smala regeln bara dekorativ.

Om daemonen körs på en maskin bakom VPN-gatewayen i stället för på själva gatewayen, behöver gatewayen också en vidarebefordringsväg och målet behöver sin egen tillåtelse och returväg. Att bara öppna porten på gatewayen ger en anslutning som accepteras och sedan inte leder någonstans.

Verifiera från klienten med samma läge och destination som du tänker använda i produktion. En lyckad listning bevisar lyssnaren, vägen och regeln tillsammans; en timeout pekar på vägen, och en avvisning pekar på lyssnaren.

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