rsync over VPN: daemonport 873 kontra SSH-modus

Å tillate TCP 873 på tunellgrensesnittet skyver ikke rsync gjennom OpenVPN, og det får heller ikke den andre enden til å godta modulen. En tunell bærer en indre forbindelse der protokoll- og destinasjonsreglene forblir nøyaktig som de var. Det første spørsmålet er derfor ikke hvilken port som skal åpnes, men hvilken type forbindelse rsync oppretter. Alt nedenfor forutsetter at tunnelen allerede er oppe og at bare den indre tjenesten fortsatt er usikker.

Avgjør hvilken forbindelse rsync faktisk oppretter

Fjernargumentet i kommandoen svarer vanligvis på det spørsmålet før noen brannmur endres. Et dobbelt kolon eller et URL-skjema velger daemonen, mens et enkelt kolon etter et vertsnavn velger et fjernskall. Les argumentet du faktisk kjører, ikke det i dokumentasjonseksemplet.

Et eksplisitt fjernskall-alternativ kan endre svaret igjen, fordi det forteller rsync hvilket program som skal startes for transporten. Les hele kommandolinjen, inkludert arvede wrapper-skript, ikke bare vertsdelen.

Daemon-modus: bindeadresse, modul og port

I daemonsyntaks navngir stisegmentet en konfigurert modul, ikke en katalog på disken. En modulpassord kontrolleres først etter at forbindelsen er akseptert, og modulen kan i tillegg være skrivebeskyttet eller skjult fra listen. Den rekkefølgen betyr noe når du leser en feil, fordi en avvist forbindelse og en avvist modul er feil på to forskjellige trinn. Ingen av meldingene forteller deg noe om selve tunnelen.

En frittstående daemon kan festes til tunelladressen i konfigurasjonsfilen, noe som holder den unna det offentlige grensesnittet uten noen brannmurregel. Verdien må finnes når daemonen binder, og en socket-aktivert eller inetd-styrt lytter kan ignorere den helt.

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

Test deretter mot den private adressen i stedet for det offentlige navnet. Et offentlig vertsnavn løses til en WAN-adresse og går en annen vei, selv når én maskin svarer på begge.

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

Fjernskall-modus: SSH bærer overføringen

Med et enkelt kolon starter rsync et fjernskallprogram og snakker protokollen over den kanalen, så den eneste tjenesten som er tilgjengelig, er SSH på hvilken som helst port serveren lytter på. rsync-daemonen kjører aldri, port 873 er irrelevant, og tilgangsbeslutningen blir en SSH-kontobeslutning. Fjernstien er da en ekte filsystemsti som skallet på den andre siden tolker. Derfor gjør en brannmur-endring rettet mot 873 absolutt ingenting for denne modusen.

Den utformingen trenger en autorisert konto og verifisering av vertsnøkkelen, og den arver SSH sin egen autentiseringspolicy. Det er ofte det bedre valget når overføringen må krysse et upålitelig nettverk, fordi krypteringen tilhører en protokoll som ble bygget for det. En daemon med passordforespørsel er ikke det samme.

Åpne bare veien du valgte

Når modusen er fastsatt, tillat den ene indre tjenesten på det ene grensesnittet som bærer tunnelen. Begrens regelen etter grensesnitt, kildebasseng og destinasjonsadresse, slik at en senere standard-avvisning ikke lydløst kan utvide den. Gå gjennom regelrekkefølgen etterpå, fordi en tillatende regel tidligere i kjeden gjør den smale regelen dekorativ.

Hvis daemonen kjører på en maskin bak VPN-gatewayen i stedet for på selve gatewayen, trenger gatewayen også en videresendingsvei, og målet trenger sin egen tillatelse og returrute. Å åpne porten bare på gatewayen gir en forbindelse som godtas og deretter ikke fører noe sted.

Verifiser fra klienten med samme modus og destinasjon som du planlegger å bruke i produksjon. En vellykket oppføring beviser lytteren, ruten og regelen sammen; en tidsavbrudd peker på veien, og en avvisning peker 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