Poden os clientes de dous servidores OpenVPN chegar uns a outros?

Levantar un segundo OpenVPN servidor dálle un segundo lugar onde os clientes poden conectarse, e nada máis. Non pon eses clientes na rede do primeiro servidor, e a opción chamada client-to-client só cambia o reenvío dentro dun único proceso de servidor. Os dous grupos convértense nunha rede cando encamiña entre eles a propósito, cun responsable para cada dirección. Todo o seguinte supón o modo TUN en espazo de usuario con ese reenvío interno desactivado, de xeito que o núcleo toma a decisión.

O mito: unha lista de contas, unha rede

Autenticación e alcance confúndense porque ambos viven na configuración do servidor. Un usuario que pode iniciar sesión en calquera das dúas pasarelas parece, desde fóra, un usuario dun só sistema con dúas portas. Dentro, cada servidor reparte enderezos do seu propio grupo e instala rutas só para os clientes que remata. Así, un cliente na pasarela A que envía un paquete a un cliente na pasarela B pide un destino do que o seu propio servidor nunca oíu falar. O paquete vai á ruta predeterminada de A, sae do túnel e chega a un cortalumes ao que nunca se lle pediu permitilo.

Engadir un segundo servidor, polo tanto, non engade redundancia, descuberta nin un dominio de difusión compartido. Engade unha rede encamiñada que necesita un plan, e o plan comeza polo enderezamento.

Dea a cada pasarela o seu propio grupo e enderezo de tránsito

Dous rangos que non poden solaparse con nada máis, máis unha pequena ligazón de tránsito entre os hosts, son todo o plan de enderezos. Manteña o tránsito nun segmento privado que controle, e anote os números antes de que ningún servidor entregue un arrendamento.

Resista a tentación de dar a ambos servidores o mesmo grupo para que os perfís sigan idénticos. Unha ruta do núcleo non pode dicir cal de dous hosts posúe agora un enderezo arbitrario dentro dun rango compartido, así que a táboa de encamiñamento apuntaría a unha pasarela e o cliente podería estar conectado á outra. Os nomes de interface son convencións locais, non estado compartido. Ambos hosts aquí chaman ao dispositivo de túnel tun0 e á ligazón de tránsito transit0, o cal está ben porque ningún paquete leva eses nomes.

Instale a ruta en ambos os dous lados

Cada pasarela necesita unha ruta para o grupo da outra a través do enderezo de tránsito, e o reenvío debe estar activo para que calquera actúe como salto. Confirme primeiro a táboa actual, logo engada a entrada e faga que persista mediante o xestor de rede do host en lugar dun gancho de reconexión.

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

Reflicta iso no outro host cos grupos intercambiados. Engadir repetidamente a mesma ruta desde un script non relacionado é como un host acaba con varias copias e un cambio misterioso a próxima vez que alguén le a táboa. Se a ligazón de tránsito é á súa vez un túnel, a ruta apunta á topoloxía dese túnel e o salto debe sobrevivir á súa reconexión. Un enderezo de tránsito que desaparece durante trinta segundos leva consigo o camiño entre grupos, o que é unha propiedade de deseño que convén declarar en lugar de descubrir.

Empurre a ruta do cliente sen falsificar a propiedade

Os clientes necesitan unha ruta cara ao grupo remoto, se non o seu propio sistema operativo envía o paquete á súa pasarela predeterminada e o túnel nunca o ve. A configuración do servidor é o lugar natural para entregala.

push "route 10.64.20.0 255.255.255.0"

Pon a liña espello na configuración do outro servidor, logo reconecta un cliente de proba e le a súa táboa. Un cliente que ignora as rutas empurradas necesita a súa propia configuración aprobada, e unha ruta que nunca chega non é un control de acceso. Non dea a un cliente un iroute para todo o grupo da outra pasarela. Esa directiva existe para unha subrede detrás dun cliente conectado, e usala para tapar unha ruta ausente entre pasarelas produce un servidor que cre posuír enderezos que non pode acadar.

Demostre unha petición e rexeite outra

Escolla unha operación real, por exemplo HTTPS desde un cliente en 10.64.10.21 cara a un servizo en 10.64.20.37, e permita exactamente iso en ambos os dous hosts. Cada cortalumes admite a petición no seu lado de entrada e a resposta seguida no lado de retorno; a política de servizo do destino aínda ten que aceptala.

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Con rutas recíprocas, o NAT de orixe é innecesario e aquí activamente prexudicial: traducir a orixe oculta que cliente fixo a petición e derrota a política baseada en orixe no lado do destino. Comprobe que unha regra de masquerade existente para a saída a internet non captura tamén este camiño. Despois probe o rexeitamento. Un servizo que debe quedar local no grupo B debe seguir inalcanzable desde o grupo A, e as parellas de clientes da mesma pasarela tamén precisan proba, xa que a política de reenvío que acaba de cambiar tamén lles afecta.

Unha corrección máis ao modelo mental: a ligazón de tránsito leva paquetes internos descifrados, así que é un límite de confianza e non unha garantía privada. Se cruza unha rede que non controla, protexa ese salto cun túnel cifrado aprobado e encamiñe pola súa topoloxía real. O TLS de extremo a extremo segue autenticando a aplicación pola súa conta, e por iso o servizo interno debe seguir usándoo.