rsync prin VPN: portul daemonului 873 sau modul SSH

Portul 873 este un serviciu intern transportat de tunel, nu un substitut al acestuia. Distingeți modul daemon de modul SSH, apoi deschideți doar calea pe care o folosiți efectiv.

Permiterea TCP 873 pe interfața tunelului nu împinge rsync prin OpenVPN, și nici nu face capătul îndepărtat să accepte modulul. Un tunel transportă o conexiune internă ale cărei reguli de protocol și de destinație rămân exact cum erau. Așadar prima întrebare nu este ce port să deschideți, ci ce tip de conexiune face rsync. Tot ce urmează presupune că tunelul este deja activ și că doar serviciul intern este încă incert.

Stabiliți ce conexiune face de fapt rsync

Argumentul la distanță din comandă răspunde de obicei la această întrebare înainte de orice modificare a paravanului. Un dublu două puncte sau o schemă URL selectează daemonul, în timp ce un singur două puncte după un nume de gazdă selectează un shell la distanță. Citiți argumentul pe care îl executați efectiv, nu cel din exemplul din documentație.

O opțiune explicită de shell la distanță poate schimba din nou răspunsul, pentru că îi spune lui rsync ce program să pornească pentru transport. Citiți întreaga linie de comandă, inclusiv scripturile înveliș moștenite, nu doar partea de gazdă.

Remote argumentWhat it opens
rsync://vault.corp.internal/archive/rsync daemon, normally TCP 873
vault.corp.internal::archive/rsync daemon, normally TCP 873
[email protected]:/srv/archive/Remote shell, normally SSH on its configured port

Modul daemon: adresa de legare, modulul și portul

În sintaxa daemonului, segmentul de cale numește un modul configurat, nu un director de pe disc. Parola unui modul este verificată abia după ce conexiunea a fost acceptată, iar modulul poate fi suplimentar doar-citire sau ascuns din listare. Această ordine contează când citiți o eroare, pentru că o conexiune refuzată și un modul respins sunt eșecuri în două etape diferite. Niciunul dintre cele două mesaje nu vă spune nimic despre tunelul în sine.

Un daemon independent poate fi fixat pe adresa tunelului în fișierul său de configurare, ceea ce îl ține departe de interfața publică fără nicio regulă de paravan. Valoarea trebuie să existe când daemonul se leagă, iar un ascultător activat prin socket sau administrat de inetd poate să o ignore complet.

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

Apoi testați pe adresa privată, nu pe numele public. Un nume de gazdă public se rezolvă la o adresă WAN și urmează o cale diferită, chiar și atunci când o singură mașină răspunde la ambele.

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

Modul shell la distanță: SSH transportă transferul

Cu un singur două puncte, rsync pornește un program de shell la distanță și vorbește protocolul acestuia pe canalul respectiv, așa că singurul serviciu accesibil este SSH pe orice port ascultă serverul. Daemonul rsync nu rulează niciodată, portul 873 este irelevant, iar decizia de acces devine o decizie de cont SSH. Calea la distanță este atunci o cale reală de sistem de fișiere interpretată de shellul de cealaltă parte. De aceea o modificare a paravanului îndreptată spre 873 nu face absolut nimic pentru acest mod.

Acel design are nevoie de un cont autorizat și de verificarea cheii gazdei, și moștenește politica proprie de autentificare a SSH. Este adesea alegerea mai bună când transferul trebuie să traverseze o rețea nesigură, pentru că criptarea aparține unui protocol construit pentru asta. Un daemon care cere parolă nu este același lucru.

Deschideți doar calea pe care ați ales-o

Odată stabilit modul, permiteți singurul serviciu intern pe singura interfață care transportă tunelul. Limitați regula după interfață, grupul sursă și adresa de destinație, astfel încât o modificare ulterioară a refuzului implicit să nu o poată lărgi în tăcere. Verificați apoi ordinea regulilor, pentru că o regulă permisivă mai sus în lanț face regula îngustă doar decorativă.

Dacă daemonul rulează pe o mașină din spatele gatewayului VPN, nu pe gatewayul însuși, gatewayul are nevoie și de o cale de redirecționare, iar ținta are nevoie de propria permisiune și de ruta de întoarcere. Deschiderea portului doar pe gateway produce o conexiune acceptată care apoi nu duce nicăieri.

Verificați din client cu același mod și aceeași destinație pe care intenționați să le folosiți în producție. O listare reușită dovedește împreună ascultătorul, ruta și regula; o expirare indică calea, iar un refuz indică ascultătorul.

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

Articole similare