rsync tra la VPN: pordo 873 de la demono kontraŭ SSH-reĝimo

Permesi TCP 873 sur la tunela interfaco ne puŝas rsync tra OpenVPN, kaj ĝi ankaŭ ne igas la alian flankon akcepti la modulon. Tunelo portas internan konekton, kies reguloj pri protokolo kaj celo restas ĝuste tiaj, kiaj ili estis. La unua demando do ne estas, kiun pordon malfermi, sed kian konekton rsync faras. Ĉio sube supozas, ke la tunelo jam funkcias kaj ke nur la interna servo estas ankoraŭ dubinda.

Decidu, kiun konekton rsync efektive faras

La fora argumento en la komando kutime respondas tiun demandon antaŭ ajna fajroŝirma ŝanĝo. Duobla dupunkto aŭ URL-skemo elektas la demonon, dum unuopa dupunkto post gastiga nomo elektas foran ŝelon. Legu la argumenton, kiun vi efektive rulas, ne tiun el la dokumenta ekzemplo.

Eksplicita fora-ŝela opcio povas denove ŝanĝi la respondon, ĉar ĝi diras al rsync, kiun programon lanĉi por la transporto. Legu la tutan komandlinion, inkluzive de hereditaj ĉirkaŭskriptoj, ne nur la gastigan parton.

Demona reĝimo: bindoadreso, modulo kaj pordo

En demona sintakso la voja segmento nomas agordan modulon, ne dosierujon sur la disko. Modula pasvorto estas kontrolata nur post kiam la konekto estis akceptita, kaj la modulo povas krome esti nurlegebla aŭ kaŝita de la listo. Tiu ordo gravas, kiam vi legas eraron, ĉar rifuzita konekto kaj rifuzita modulo estas malsukcesoj en du malsamaj etapoj. Neniu el la mesaĝoj diras al vi ion pri la tunelo mem.

Memstara demono povas esti fiksita al la tunela adreso en sia agorda dosiero, kio tenas ĝin for de la publika interfaco sen ajna fajroŝirma regulo. La valoro devas ekzisti kiam la demono bindas, kaj soket-aktivigita aŭ inetd-administrata aŭskultanto povas tute ignori ĝin.

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

Poste testu kontraŭ la privata adreso anstataŭ la publika nomo. Publika gastiga nomo solviĝas al WAN-adreso kaj iras alian vojon, eĉ kiam unu maŝino respondas al ambaŭ.

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

Fora-ŝela reĝimo: SSH portas la transigon

Kun unuopa dupunkto rsync lanĉas foran-ŝelan programon kaj parolas ĝian protokolon tra tiu kanalo, do la sola atingebla servo estas SSH sur kiu ajn pordo la servilo aŭskultas. La demono de rsync neniam funkcias, pordo 873 estas senrilata, kaj la alirkonsento fariĝas konsento pri SSH-konto. La fora vojo tiam estas reala dosiersistema vojo interpretata de la ŝelo ĉe la alia flanko. Tial fajroŝirma ŝanĝo celanta 873 tute faras nenion por ĉi tiu reĝimo.

Tiu dezajno bezonas rajtigitan konton kaj kontrolon de la gastiga ŝlosilo, kaj ĝi heredas la propran aŭtentikigan politikon de SSH. Ĝi ofte estas la pli bona elekto kiam la transigo devas transiri nefidindan reton, ĉar la ĉifrado apartenas al protokolo konstruita por tio. Demono kun pasvorta invito ne estas la sama afero.

Malfermu nur la vojon, kiun vi elektis

Post kiam la reĝimo estas fiksita, permesu la solan internan servon sur la sola interfaco, kiu portas la tunelon. Limigu la regulon laŭ interfaco, fonta baseno kaj cela adreso, por ke posta defaŭlta malpermeso ne povu silente larĝigi ĝin. Revizu poste la ordon de la reguloj, ĉar permesa regulo pli frue en la ĉeno faras la mallarĝan regulon dekoracia.

Se la demono funkcias sur maŝino malantaŭ la VPN-pordego anstataŭ sur la pordego mem, la pordego bezonas ankaŭ plusendan vojon kaj la celo bezonas sian propran permeson kaj revenan itineron. Malfermi la pordon nur sur la pordego produktas konekton, kiu estas akceptita kaj poste iras nenie.

Kontrolu de la kliento kun la sama reĝimo kaj celo, kiujn vi intencas uzi en produkto. Sukcesa listo pruvas la aŭskultanton, la itineron kaj la regulon kune; tempolimo indikas la vojon, kaj rifuzo indikas la aŭskultanton.

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