Deixa que un cliente OpenVPN faga SSH a outro sen abrir o grupo

Un cliente necesita chegar ao servizo SSH doutro cliente, e o resto do grupo debe seguir tan illado como hoxe. O interruptor tentador é client-to-client, que activa o acceso entre pares para todos á vez e entrega a decisión a OpenVPN en lugar de ao núcleo. Unha resposta máis estreita mantén ese interruptor apagado e deixa que o enrutamento e a devasa do propio servidor leven exactamente un fluxo.

O mecanismo importa máis que o texto da regra, porque os dous enfoques colocan o paquete en lugares distintos. Saber cal escolliches explica tanto a regra que parece non facer nada como o par que se conecta sen ela.

Onde move o paquete client-to-client

Con client-to-client activado, o servidor retransmite un paquete de par internamente en lugar de envialo de volta polo dispositivo de túnel, así que o paquete nunca chega á ruta de reenvío do núcleo. Iso é cómodo e tamén significa que a túa devasa nunca ve o fluxo que debería vixiar. Déixao desactivado e o servidor encamiña o paquete de volta pola mesma interface, o que o pon diante de netfilter. A mesma interface á entrada, a mesma á saída, e a cadea FORWARD ten o voto.

O intercambio é explícito: gañas un punto de política e asumes o traballo de enrutamento e reenvío que o atallo facía por ti. Ese traballo é pequeno para un só fluxo e medra con cada excepción que engades. Conta as excepcións agora, porque o conxunto de regras é onde vive de verdade a política entre pares.

A ruta que segue realmente un paquete de par

Supón un servizo OpenVPN 2.6 Community sobre Linux, procesamento TUN en espazo de usuario en lugar de DCO, topoloxía de subrede, tun0 e un grupo de 10.44.0.0/24 co cliente A en 10.44.0.21 e o cliente B en 10.44.0.37. Con topoloxía de subrede, o enderezo e a máscara que recibiu A xa cobren o grupo, así que A envía o paquete ao dispositivo de túnel sen necesidade dunha ruta empurrada extra. Comproba a ruta efectiva en A en lugar de supoñer unha.

No servidor o paquete chega dirixido a B, que non é un enderezo local, así que se reenvía. O reenvío IPv4 ten que estar activado para que iso ocorra, e a consulta de ruta ten que enviar o paquete de volta por tun0. Por tanto a devasa ve un fluxo reenviado coa mesma interface nos dous lados, e ese é o detalle que case todos os conxuntos de regras pasan por alto. Aquí non fai falta tradución de orixe, e manter intacto o enderezo de A é o que permite que B aplique a súa propia regra baseada na orixe.

Dúas regras no servidor, nesta orde

Tres regras levan toda a concesión: o reenvío, a excepción do par e un descarte por defecto para o par de túnel. A regra de aceptación nomea o par e o servizo, así que a concesión sobrevive a un grupo que medra. Colócaa antes de calquera denegación xeral do tráfico túnel a túnel, porque gaña a primeira coincidencia:

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o tun0 -s 10.44.0.21 -d 10.44.0.37 -p tcp --dport 22 -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -j DROP

Eses comandos son ilustrativos e pertencen ao mecanismo que use o teu anfitrión para persistir regras; unha inserción en tempo de execución desaparece no seguinte arranque. A regra con estado é a que permite que as respostas de B e o aperto de mans TCP volvan sen unha segunda aceptación espello.

Comproba os contadores despois, non a listaxe de regras, porque unha regra que nunca coincide é idéntica a unha que funciona. Se os contadores quedan a cero, o paquete non segue o camiño que cres.

O que B aínda debe permitir

B executa o servizo SSH, así que B decide se algo escoita no enderezo do túnel e se a súa propia devasa de anfitrión acepta a orixe. Un permiso de rede no servidor non é permiso para ningunha conta de B, e a verificación da clave de anfitrión e a autenticación de usuario seguen aplicándose como desde calquera outro sitio.

Proba primeiro o caso positivo: unha conexión SSH nova de A ao enderezo do túnel de B, aceptada coa clave de anfitrión agardada. Despois proba outro par ou outro porto e confirma que se rexeita, porque unha concesión que permite todo en silencio é indistinguible dunha que funciona ata que importa. As dúas metades desa proba son necesarias, e a segunda é a que a xente salta.

Anota os enderezos asignados, as rutas efectivas nos dous clientes e as regras exactas no servidor e en B. Un ping correcto á pasarela ou un porto aberto no servidor non demostra nada disto, xa que ambas as cousas poden ser certas mentres o reenvío entre pares segue bloqueado. Escribe eses números co túnel levantado, porque o enderezo que un cliente recibe tras reconectarse pode ser outro.