rsync per VPN: 873 prievadas ir SSH režimas

Leidus TCP 873 tunelio sąsajoje, rsync nepatenka pro OpenVPN, ir toli esantis galas nepriima modulio. Tunelis neša vidinį ryšį, kurio protokolo ir paskirties taisyklės lieka lygiai tokios, kokios buvo. Todėl pirmas klausimas ne kurią prievadą atidaryti, o kokio tipo ryšį rsync užmezga. Visa toliau remiasi prielaida, kad tunelis jau veikia, o abejonių kelia tik vidinė paslauga.

Nustatykite, kokį ryšį rsync iš tikrųjų užmezga

Nuotolinis argumentas komandoje paprastai atsako į šį klausimą prieš bet kokį ugniasienės pakeitimą. Dvigubas dvitaškis arba URL schema pasirenka diegimą, o vienas dvitaškis po hosto vardo pasirenka nuotolinę apvalkalą. Skaitykite argumentą, kurį iš tikrųjų vykdote, o ne tą, kuris yra dokumentacijos pavyzdyje.

Aiškus nuotolinės apvalkalos parametras gali vėl pakeisti atsakymą, nes jis nurodo rsync, kurią programą paleisti transportui. Skaitykite visą komandos eilutę, įskaitant paveldėtus apvalkalų scenarijus, ne tik hosto dalį.

Diegimo režimas: susiejimo adresas, modulis ir prievadas

Diegimo sintaksėje kelio segmentas įvardija sukonfigūruotą modulį, o ne disko katalogą. Modulio slaptažodis tikrinamas tik po to, kai ryšys priimtas, o modulis papildomai gali būti tik skaitomas arba paslėptas nuo sąrašo. Ši tvarka svarbi skaitant klaidą, nes atmestas ryšys ir atmestas modulis yra gedimai dviejuose skirtinguose etapuose. Nė vienas pranešimas nieko nesako apie patį tunelį.

Savarankišką diegimą galima prisegti prie tunelio adreso jo konfigūracijos faile, taip jis laikomas toli nuo viešosios sąsajos be jokios ugniasienės taisyklės. Reikšmė turi egzistuoti diegimui susiejant, o lizdo aktyvuojamas arba inetd valdomas klausytojas gali visiškai ją ignoruoti.

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

Tada bandykite su privačiu adresu, o ne viešuoju vardu. Viešas hosto vardas išsprendžiamas į WAN adresą ir eina kitu keliu, net kai viena mašina atsako abiem.

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

Nuotolinės apvalkalos režimas: SSH neša perdavimą

Su vienu dvitaškiu rsync paleidžia nuotolinės apvalkalos programą ir kalba jos protokolu šiuo kanalu, todėl vienintelė pasiekiama paslauga yra SSH tame prievade, kuriame serveris klauso. rsync diegimas niekada neveikia, 873 prievadas nesvarbus, o prieigos sprendimas tampa SSH paskyros sprendimu. Nuotolinis kelias tada yra tikras failų sistemos kelias, kurį interpretuoja priešingos pusės apvalkala. Štai kodėl į 873 nukreiptas ugniasienės pakeitimas šiam režimui nedaro visiškai nieko.

Tokiai konstrukcijai reikia įgaliotos paskyros ir hosto rakto patikrinimo, ir ji paveldi SSH autentifikacijos politiką. Tai dažnai geresnis pasirinkimas, kai perdavimas turi kirsti nepatikimą tinklą, nes šifravimas priklauso tam skirtam protokolui. Diegimas, prašantis slaptažodžio, nėra tas pats.

Atidarykite tik pasirinktą kelią

Kai režimas nustatytas, leiskite vienintelę vidinę paslaugą vienintelėje sąsajoje, kuri neša tunelį. Susiaurinkite taisyklę pagal sąsają, šaltinių telkinį ir paskirties adresą, kad vėlesnis numatytojo draudimo pakeitimas negalėtų tyliai jos išplėsti. Po to peržiūrėkite taisyklių tvarką, nes leidžianti taisyklė anksčiau grandinėje daro siaurąją taisyklę tik dekoratyvią.

Jei diegimas veikia mašinoje už VPN vartų, o ne pačiuose vartuose, vartams taip pat reikia persiuntimo kelio, o tikslui – savo leidimo ir grįžimo maršruto. Atidarius prievadą tik vartuose, gaunamas ryšys, kuris priimamas ir paskui niekur neveda.

Patikrinkite iš kliento tuo pačiu režimu ir paskirties vieta, kuriuos ketinate naudoti gamyboje. Sėkmingas sąrašas kartu įrodo klausytoją, maršrutą ir taisyklę; laiko limitas rodo kelią, o atsisakymas – klausytoją.

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