rsync over VPN: daemonport 873 kontra SSH-modus

Å tillate TCP 873 på tunellgrensesnittet skyv ikkje rsync gjennom OpenVPN, og det får heller ikkje den andre enden til å godta modulen. Ein tunnel ber ei indre forbinding der protokoll- og målreglane blir nøyaktig som dei var. Det første spørsmålet er derfor ikkje kva port som skal opnast, men kva type forbinding rsync lagar. Alt nedanfor føreset at tunnelen alt er oppe og at berre den indre tenesta framleis er usikker.

Avgjer kva forbinding rsync faktisk lagar

Fjernargumentet i kommandoen svarar vanlegvis på det spørsmålet før ei endring i brannmuren. Eit dobbelt kolon eller eit URL-skjema vel daemonen, medan eit enkelt kolon etter eit vertsnamn vel eit fjernskal. Les argumentet du faktisk køyrer, ikkje det i dokumentasjonseksempelet.

Eit eksplisitt fjernskal-alternativ kan endre svaret igjen, fordi det fortel rsync kva program som skal startast for transporten. Les heile kommandolinja, inkludert arva wrapper-skript, ikkje berre vertsdelen.

Daemonmodus: bindeadresse, modul og port

I daemonsyntaks nemner stisegmentet ein konfigurert modul, ikkje ein katalog på disken. Eit modulpassord blir først kontrollert etter at forbindinga er godteken, og modulen kan i tillegg vere skriveverna eller skjult frå lista. Den rekkjefølgja har noko å seie når du les ein feil, fordi ei avvist forbinding og ein avvist modul er feil på to ulike trinn. Ingen av meldingane fortel deg noko om sjølve tunnelen.

Ein frittståande daemon kan festast til tunelladressa i konfigurasjonsfila, noko som held han unna det offentlege grensesnittet utan noka brannmurregel. Verdien må finnast når daemonen bind, og ein socket-aktivert eller inetd-styrt lyttar kan ignorere han heilt.

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

Test deretter mot den private adressa i staden for det offentlege namnet. Eit offentleg vertsnamn blir løyst til ei WAN-adresse og går ein annan veg, sjølv når éin maskin svarar på begge.

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

Fjernskalmodus: SSH ber overføringa

Med eit enkelt kolon startar rsync eit fjernskalprogram og snakkar protokollen over den kanalen, så den einaste tenesta som er tilgjengeleg, er SSH på kva port serveren enn lyttar på. rsync-daemonen køyrer aldri, port 873 er irrelevant, og tilgangsavgjerda blir ei SSH-kontoavgjerd. Fjernvegen er då ein ekte filsystemveg som skalet på den andre sida tolkar. Derfor gjer ei brannmurendring retta mot 873 absolutt ingenting for denne modusen.

Den utforminga treng ein autorisert konto og stadfesting av vertsnøkkelen, og ho arvar SSH sin eigen autentiseringspolitikk. Det er ofte det betre valet når overføringa må krysse eit upåliteleg nettverk, fordi krypteringa høyrer til ein protokoll som vart bygd for det. Ein daemon med passordspørsmål er ikkje det same.

Opne berre vegen du valde

Når modusen er fastsett, tillat den eine indre tenesta på det eine grensesnittet som ber tunnelen. Afgrens regelen etter grensesnitt, kjeldebasseng og måladresse, slik at ei seinare standard-avvising ikkje lydlaust kan utvide han. Gå gjennom reglerekkjefølgja etterpå, fordi ein tillatande regel tidlegare i kjeda gjer den smale regelen dekorativ.

Viss daemonen køyrer på ein maskin bak VPN-gatewayen i staden for på sjølve gatewayen, treng gatewayen også ein vidaresendingsveg, og målet treng si eiga løyve og returrute. Å opne porten berre på gatewayen gir ei forbinding som blir godteken og deretter ikkje fører nokon stad.

Stadfest frå klienten med same modus og mål som du planlegg å bruke i produksjon. Ei vellukka liste provar lyttaren, ruta og regelen saman; ein tidsavbrot peikar på vegen, og ei avvising peikar på lyttaren.

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