rsync pola VPN: porto do daemon 873 fronte ao modo SSH

Permitir TCP 873 na interface do túnel non empuxa rsync a través de OpenVPN, nin fai que o extremo remoto acepte o módulo. Un túnel transporta unha conexión interna cuxas regras de protocolo e destino seguen exactamente como estaban. Por iso a primeira pregunta non é que porto abrir, senón que tipo de conexión establece rsync. Todo o que segue supón que o túnel xa está levantado e que só o servizo interno segue en dúbida.

Decida que conexión establece rsync en realidade

O argumento remoto da orde adoita responder a esa pregunta antes de calquera cambio no devasado. Un dobre dous puntos ou un esquema de URL elixe o daemon, mentres que un só dous puntos tras un nome de host elixe un shell remoto. Lea o argumento que realmente executa, non o do exemplo da documentación.

Unha opción explícita de shell remoto pode cambiar de novo a resposta, porque lle di a rsync que programa lanzar para o transporte. Lea toda a liña de ordes, incluídos os guións envoltorio herdados, non só a parte do host.

Modo daemon: enderezo de enlace, módulo e porto

Na sintaxe de daemon, o segmento de ruta nomea un módulo configurado, non un directorio no disco. O contrasinal do módulo só se comproba despois de aceptar a conexión, e o módulo pode ademais ser de só lectura ou estar oculto na listaxe. Esa orde importa ao ler un erro, porque unha conexión rexeitada e un módulo rexeitado son fallos en dúas etapas distintas. Ningunha das dúas mensaxes lle di nada sobre o túnel en si.

Un daemon independente pode fixarse ao enderezo do túnel no seu ficheiro de configuración, o que o mantén fóra da interface pública sen ningunha regra de devasado. O valor debe existir cando o daemon se enlaza, e un oínte activado por socket ou xestionado por inetd pode ignoralo por completo.

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

Despois probe contra o enderezo privado en lugar do nome público. Un nome de host público resólvese nun enderezo WAN e percorre unha ruta distinta, mesmo cando unha soa máquina responde en ambas.

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

Modo de shell remoto: SSH transporta a transferencia

Cun só dous puntos, rsync inicia un programa de shell remoto e fala o seu protocolo por esa canle, así que o único servizo alcanzable é SSH no porto que escoite o servidor. O daemon de rsync nunca se executa, o porto 873 é irrelevante e a decisión de acceso pasa a ser unha decisión de conta SSH. A ruta remota é entón unha ruta real do sistema de ficheiros interpretada polo shell do outro lado. Por iso un cambio de devasado dirixido ao 873 non fai absolutamente nada para este modo.

Ese deseño necesita unha conta autorizada e a verificación da chave do host, e herda a propia política de autenticación de SSH. A miúdo é a mellor opción cando a transferencia debe cruzar unha rede non fiable, porque o cifrado pertence a un protocolo creado para iso. Un daemon con solicitude de contrasinal non é o mesmo.

Abra só a ruta que escolleu

Unha vez fixado o modo, permita o único servizo interno na única interface que transporta o túnel. Limite a regra por interface, conxunto de orixe e enderezo de destino para que un cambio posterior de denegación por defecto non poida ampliala en silencio. Revise despois a orde das regras, porque unha regra permisiva anterior na cadea fai que a estrita sexa decorativa.

Se o daemon se executa nunha máquina detrás da pasarela VPN e non na pasarela mesma, a pasarela tamén necesita unha ruta de reenvío e o obxectivo necesita o seu propio permiso e ruta de retorno. Abrir o porto só na pasarela produce unha conexión que se acepta e logo non vai a ningures.

Verifique desde o cliente co mesmo modo e destino que pensa usar en produción. Unha listaxe correcta demostra xuntos o oínte, a ruta e a regra; un tempo de espera apunta á ruta, e un rexeitamento apunta ao oínte.

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