rsync over VPN: daemonport 873 kontra SSH-tilstand

At tillade TCP 873 på tunnelinterfacet sender ikke rsync gennem OpenVPN, og det får heller ikke den anden ende til at acceptere modulet. En tunnel bærer en indre forbindelse, hvis protokol- og destinationsregler forbliver præcis som de var. Det første spørgsmål er derfor ikke, hvilken port der skal åbnes, men hvilken slags forbindelse rsync opretter. Alt nedenfor forudsætter, at tunnelen allerede er oppe, og at kun den indre tjeneste stadig er usikker.

Afgør, hvilken forbindelse rsync faktisk opretter

Fjernargumentet i kommandoen besvarer normalt det spørgsmål, før nogen firewallændring. Et dobbelt kolon eller et URL-skema vælger daemonen, mens et enkelt kolon efter et værtsnavn vælger en fjernshell. Læs det argument, du faktisk kører, ikke det i dokumentationseksemplet.

En eksplicit fjernshell-indstilling kan ændre svaret igen, fordi den fortæller rsync, hvilket program der skal startes til transporten. Læs hele kommandolinjen, inklusive nedarvede wrapper-scripts, ikke kun værtsdelen.

Daemon-tilstand: bindeadresse, modul og port

I daemonsyntaks navngiver stisegmentet et konfigureret modul, ikke en mappe på disken. En moduladgangskode kontrolleres først, efter forbindelsen er accepteret, og modulet kan desuden være skrivebeskyttet eller skjult fra visning. Den rækkefølge betyder noget, når du læser en fejl, fordi en afvist forbindelse og et afvist modul er fejl på to forskellige trin. Ingen af meddelelserne fortæller dig noget om selve tunnelen.

En selvstændig daemon kan fastgøres til tunneladressen i sin konfigurationsfil, hvilket holder den væk fra det offentlige interface uden nogen firewallregel. Værdien skal findes, når daemonen binder, og en socket-aktiveret eller inetd-styret lytter kan ignorere den helt.

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

Test derefter mod den private adresse i stedet for det offentlige navn. Et offentligt værtsnavn opløses til en WAN-adresse og går en anden vej, selv når én maskine svarer på begge.

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

Fjernshell-tilstand: SSH bærer overførslen

Med et enkelt kolon starter rsync et fjernshell-program og taler dets protokol over den kanal, så den eneste tilgængelige tjeneste er SSH på hvilken som helst port, serveren lytter på. rsync-daemonen kører aldrig, port 873 er irrelevant, og adgangsbeslutningen bliver en SSH-kontobeslutning. Fjernstien er derefter en rigtig filsystemsti, som shellen i den anden ende fortolker. Derfor gør en firewallændring rettet mod 873 slet ingenting for denne tilstand.

Det design kræver en autoriseret konto og verifikation af værtsnøglen, og det arver SSH's egen godkendelsespolitik. Det er ofte det bedre valg, når overførslen skal krydse et utroværdigt netværk, fordi krypteringen tilhører en protokol, der blev bygget til det. En daemon med adgangskodeprompt er ikke det samme.

Åbn kun den vej, du valgte

Når tilstanden er fastlagt, tillad den ene indre tjeneste på det ene interface, der bærer tunnelen. Afgræns reglen efter interface, kildebasseng og destinationsadresse, så en senere standard-afvisning ikke lydløst kan udvide den. Gennemgå derefter reglerækkefølgen, fordi en tilladende regel tidligere i kæden gør den snævre regel dekorativ.

Hvis daemonen kører på en maskine bag VPN-gatewayen i stedet for på selve gatewayen, har gatewayen også brug for en videresendelsesvej, og målet har brug for sin egen tilladelse og returrute. At åbne porten alene på gatewayen giver en forbindelse, der accepteres og derefter ikke fører nogen steder hen.

Verificér fra klienten med den samme tilstand og destination, som du vil bruge i produktion. En vellykket visning beviser lytteren, ruten og reglen sammen; en timeout peger på vejen, og en afvisning peger på lytteren.

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