Un cliente de WireGuard non pode chegar a un cliente de OpenVPN?

Os dous túneles conéctanse, cada cliente chega á pasarela, e no momento en que un proba o enderezo do outro os paquetes desaparecen. Nada falla en ningunha das dúas apertas de mans, e ningunha reemisión de chaves o cambia. A pasarela transporta paquetes IP normais sen cifrar entre dúas das súas propias interfaces, así que os protocolos nunca necesitan entenderse entre si; o que necesitan son tres cousas que ningunha aperta de mans fornece. Cobertura de destino no cliente de orixe, propiedade da orixe na pasarela e un camiño de volta no lado remoto. O síntoma é o mesmo para as tres, por iso se diagnostican xuntas.

Ao síntoma fáltalle unha peza á vez

Este deseño usa un pool de WireGuard 10.71.0.0/24 en wg1 e un pool de OpenVPN 10.72.0.0/24 en tun1, ambos terminando nunha soa pasarela. A petición en probas vai de 10.71.0.5 a HTTPS en 10.72.0.30. Cada paso de embaixo trata dese único fluxo. Cada comprobación ten unha sinatura de fallo distinta aínda que o usuario as vive igual, e normalmente só falta unha das tres á vez.

Comeza confirmando que ambos os pools están realmente nesta pasarela e que o reenvío está activado no espazo de nomes onde viven os túneles. Unha pasarela que termina ambos os protocolos en espazos de nomes distintos non reenvía nada entre eles, e paga a pena descartalo antes de ler calquera configuración de par.

Amplía a cobertura de destino do nodo radial

No cliente de WireGuard, a entrada de par existente ten que seleccionar a pasarela para o destino de OpenVPN, o que significa que o prefixo de destino debe aparecer na lista permitida dese par. Engadilo non crea un segundo túnel; cambia que par escolle o cliente cando busca ese enderezo, e con wg-quick a ruta normalmente segue a lista de forma automática.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Deixa intactas as liñas reais de chave e punto final, e lembra que un xestor que use Table = off non toma ningunha ruta desta lista. Nese caso o mesmo prefixo ten que instalalo na táboa de rutas do sistema quen o posúa, e unha ruta que falte alí vese exactamente igual que un prefixo permitido que falta.

Mantén a propiedade da orixe na pasarela

A entrada de par deste cliente na pasarela debe seguir posuíndo exactamente o enderezo de orixe dese cliente. Os enderezos permitidos compróbanse en ambos os sentidos: elixen un par para o tráfico saínte e validan que a orixe dun paquete entrante pertence ao par que o enviou. Poñer o pool de OpenVPN na entrada do nodo radial porque o nodo radial quere alcanzalo é o erro que manda o tráfico cara ao participante equivocado.

AllowedIPs = 10.71.0.5/32

Le esa entrada como unha declaración de propiedade e non como unha comodidade de encamiñamento. Todo o demais ao que o cliente deba chegar pertence á lista de destinos do cliente, non á idea que a pasarela ten do que este par pode enviar.

Dálle ao lado de OpenVPN unha ruta de volta

O obxectivo necesita agora unha ruta de volta cara á orixe de WireGuard, e para os clientes de pool normalmente chega como unha ruta empurrada desde o servidor de OpenVPN. Empúrxaa só aos clientes que deban tela, e confirma no cliente que se aceptou no canto de supor que a directiva se aplicou.

push "route 10.71.0.0 255.255.255.0"

A distribución de rutas non é autorización. Cando o destino está detrás doutro cliente de OpenVPN no canto de dentro do pool, a propiedade da propia LAN dese cliente e os seus requisitos de reenvío engádense ao deseño, e a ruta empurrada é só a primeira metade. Reformula o requisito como un grafo antes de engadir directivas: que nodo posúe que prefixo e que nodo reenvía cara a el.

Permite só o servizo que querías permitir

Co reenvío activado e ambos os pools encamiñables, a pregunta que queda é de política. Escribe a regra para o fluxo concreto e non para o par de interfaces en xeral, previsualízaa antes de aplicala e mantén o camiño de volta con estado para que as respostas non se bloqueen como conexións novas. Unha proba en seco non custa nada e mostra exactamente que se engadiría.

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

Estas son regras de tráfico reenviado, distintas das regras de escoita da pasarela para os dous servizos VPN. Abrir os portos UDP exteriores non autoriza a petición interior, e autorizar a petición interior non esixe SSH sen restricións á pasarela nin un permiso por defecto no reenvío. O cortafuegos propio do obxectivo e o enderezo de escoita tamén teñen que coincidir, xa que un servizo ligado a loopback rexeita o paquete mellor encamiñado. Unha política que só cobre un sentido da conversa adoita fallar cunha petición correcta e unha resposta silenciosa, que é o resultado máis confuso dos tres.

As rutas recíprocas adoitan significar que non fai falta tradución de orixe, o que conserva o enderezo de WireGuard no obxectivo e fai lexibles os rexistros. Non engadas unha mascarada xeral porque haxa dous protocolos implicados, e non quites unha regra de tradución existente sen saber que depende dela. Despois verifica o único fluxo de extremo a extremo, e proba tamén unha orixe ou un porto non permitidos: unha aperta de mans que funciona en cada lado non demostra nin a ruta cruzada nin o illamento.