rsync VPN-en át: a 873-as daemonport versus SSH mód

Ha engedélyezi a TCP 873-at a tunel interfészén, az nem nyomja át az rsyncet a OpenVPN-en, és nem éri el azt sem, hogy a túloldal elfogadja a modult. A tunel belső kapcsolatot hordoz, amelynek protokoll- és célszabályai pontosan ugyanazok maradnak, mint voltak. Ezért az első kérdés nem az, melyik portot kell megnyitni, hanem hogy milyen típusú kapcsolatot létesít az rsync. Az alábbiak mind azt feltételezik, hogy a tunel már áll, és csak a belső szolgáltatás kérdéses.

Döntse el, milyen kapcsolatot létesít valójában az rsync

A parancs távoli argumentuma általában még minden tűzfalváltozás előtt megválaszolja ezt a kérdést. A kettős kettőspont vagy egy URL-séma a daemont választja, míg egyetlen kettőspont a hosztnév után távoli shellt választ. Azt az argumentumot olvassa, amelyet valóban futtat, ne a dokumentáció példájában szereplőt.

Egy kifejezett távoli shell opció ismét megváltoztathatja a választ, mert megmondja az rsyncnek, melyik programot indítsa a szállításhoz. Az egész parancssort olvassa, beleértve az örökölt burkoló szkripteket is, ne csak a hoszt részt.

Daemon mód: kötési cím, modul és port

A daemon szintaxisban az útvonal-szegmens egy beállított modult nevez meg, nem egy könyvtárat a lemezen. A modul jelszava csak a kapcsolat elfogadása után ellenőrződik, és a modul emellett csak olvasható vagy a listából rejtett is lehet. Ez a sorrend számít, amikor hibát olvas, mert az elutasított kapcsolat és az elutasított modul két különböző szakaszban bekövetkező hiba. Egyik üzenet sem mond semmit magáról a tunelről.

Egy önálló daemon a konfigurációs fájljában a tunel címéhez köthető, ami minden tűzfalszabály nélkül távol tartja a nyilvános interfésztől. Az értéknek léteznie kell, amikor a daemon kötődik, és egy socket által aktivált vagy inetd által kezelt figyelő teljesen figyelmen kívül hagyhatja.

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

Ezután a nyilvános név helyett a privát cím ellen teszteljen. A nyilvános hosztnév WAN-címmé oldódik fel, és más útvonalat jár be, akkor is, ha egy gép mindkettőre válaszol.

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

Távoli shell mód: az SSH hordozza az átvitelt

Egyetlen kettősponttal az rsync elindít egy távoli shell programot, és annak protokollját beszéli ezen a csatornán, így az egyetlen elérhető szolgáltatás az SSH, azon a porton, amelyen a szerver figyel. Az rsync daemon soha nem fut, a 873-as port lényegtelen, és a hozzáférési döntés SSH-fiók döntéssé válik. A távoli útvonal ekkor valódi fájlrendszer-útvonal, amelyet a túloldali shell értelmez. Ezért a 873-at célzó tűzfalváltozás ehhez a módhoz egyáltalán semmit nem tesz.

Ehhez a kialakításhoz kell jogosult fiók és a hosztkulcs ellenőrzése, és örökli az SSH saját hitelesítési szabályzatát. Gyakran ez a jobb választás, ha az átvitelnek nem megbízható hálózaton kell áthaladnia, mert a titkosítás egy erre épített protokollhoz tartozik. A jelszót kérő daemon nem ugyanaz.

Csak a választott útvonalat nyissa meg

Amint a mód eldőlt, engedélyezze az egyetlen belső szolgáltatást azon az egyetlen interfészen, amely a tunelt hordozza. Szűkítse a szabályt interfész, forráspool és célcím szerint, hogy egy későbbi alapértelmezett elutasítás ne tudja csendben kiszélesíteni. Ezután vizsgálja felül a szabályok sorrendjét, mert a láncban korábbi engedélyező szabály díszítővé teszi a szűk szabályt.

Ha a daemon a VPN-átjáró mögötti gépen fut, nem magán az átjárón, az átjárónak is kell továbbítási útvonal, a célnak pedig saját engedély és visszaút. Ha csak az átjárón nyitja meg a portot, olyan kapcsolat jön létre, amelyet elfogadnak, majd sehová nem jut.

Ellenőrizze a kliensről ugyanazzal a móddal és céllal, amelyeket éles környezetben használni kíván. Egy sikeres listázás egyszerre bizonyítja a figyelőt, az útvonalat és a szabályt; az időtúllépés az útvonalra, az elutasítás a figyelőre mutat.

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