Um cliente WireGuard não alcança um cliente OpenVPN?

Ambos os túneis conectam, cada cliente alcança o gateway, e no momento em que um tenta o endereço do outro os pacotes desaparecem. Nada está errado em nenhum dos dois handshakes, e nenhuma reemissão de chaves muda isso. O gateway transporta pacotes IP comuns não cifrados entre duas das suas próprias interfaces, portanto os protocolos nunca precisam entender um ao outro; o que eles precisam são três coisas que nenhum handshake fornece. Cobertura de destino no cliente de origem, propriedade da origem no gateway e um caminho de volta do lado remoto. O sintoma é o mesmo para os três, por isso são diagnosticados em conjunto.

Falta ao sintoma uma peça de cada vez

Este desenho usa um pool de WireGuard 10.71.0.0/24 em wg1 e um pool de OpenVPN 10.72.0.0/24 em tun1, ambos terminando num único gateway. O pedido em teste vai de 10.71.0.5 para HTTPS em 10.72.0.30. Cada passo abaixo diz respeito a esse único fluxo. Cada verificação tem uma assinatura de falha diferente embora o utilizador as viva da mesma forma, e normalmente falta apenas uma das três de cada vez.

Comece por confirmar que ambos os pools estão realmente neste gateway e que o encaminhamento está ativo no espaço de nomes onde vivem os túneis. Um gateway que termina os dois protocolos em espaços de nomes diferentes não encaminha nada entre eles, e vale a pena excluir isso antes de ler qualquer configuração de par.

Amplie a cobertura de destino do nó radial

No cliente WireGuard, a entrada de par existente tem de selecionar o gateway para o destino OpenVPN, o que significa que o prefixo de destino deve aparecer na lista permitida desse par. Acrescentá-lo não cria um segundo túnel; muda qual par o cliente escolhe quando procura esse endereço, e com wg-quick a rota normalmente segue a lista de forma automática.

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

Deixe intactas as linhas reais de chave e de ponto final e lembre-se de que um gestor que use Table = off não retira nenhuma rota desta lista. Nesse caso o mesmo prefixo tem de ser instalado na tabela de rotas do sistema por quem o possui, e uma rota em falta ali parece exatamente um prefixo permitido em falta.

Mantenha a propriedade da origem no gateway

A entrada de par deste cliente no gateway deve continuar a possuir exatamente o endereço de origem desse cliente. Os endereços permitidos são verificados nos dois sentidos: escolhem um par para o tráfego de saída e validam que a origem de um pacote de entrada pertence ao par que o enviou. Colocar o pool OpenVPN na entrada do nó radial porque o nó radial o quer alcançar é o erro que envia o tráfego para o participante errado.

AllowedIPs = 10.71.0.5/32

Leia essa entrada como uma declaração de propriedade e não como uma comodidade de encaminhamento. Tudo o resto a que o cliente tenha de chegar pertence à lista de destinos do cliente, não à ideia que o gateway tem do que este par pode enviar.

Dê ao lado OpenVPN uma rota de retorno

O destino precisa agora de uma rota de volta para a origem WireGuard, e para os clientes de um pool chega normalmente como uma rota empurrada a partir do servidor OpenVPN. Empurre-a apenas para os clientes que a devem ter, e confirme no cliente que foi aceite em vez de assumir que a diretiva foi aplicada.

push "route 10.71.0.0 255.255.255.0"

A distribuição de rotas não é autorização. Quando o destino está atrás de outro cliente OpenVPN em vez de dentro do pool, a propriedade da própria LAN desse cliente e os seus requisitos de encaminhamento juntam-se ao desenho, e a rota empurrada é apenas a primeira metade. Reformule o requisito como um grafo antes de acrescentar diretivas: que nó possui que prefixo e que nó encaminha na sua direção.

Permita apenas o serviço que queria permitir

Com o encaminhamento ativo e os dois pools encaminháveis, a pergunta que resta é de política. Escreva a regra para o fluxo concreto e não para o par de interfaces em geral, pré-visualize-a antes de a aplicar e mantenha o caminho de volta com estado para que as respostas não sejam bloqueadas como novas ligações. Um ensaio a seco não custa nada e mostra exatamente o que seria acrescentado.

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 são regras de tráfego encaminhado, distintas das regras de escuta do gateway para os dois serviços VPN. Abrir as portas UDP exteriores não autoriza o pedido interior, e autorizar o pedido interior não exige SSH sem restrições ao gateway nem uma permissão por omissão no encaminhamento. A firewall do próprio destino e o seu endereço de escuta também têm de coincidir, porque um serviço ligado a loopback recusa o pacote mais cuidadosamente encaminhado. Uma política que só cobre um sentido da conversa falha normalmente com um pedido bem-sucedido e uma resposta silenciosa, que é o resultado mais confuso dos três.

Rotas recíprocas normalmente significam que não é necessária tradução de origem, o que preserva o endereço WireGuard no destino e torna os registos legíveis. Não acrescente masquerading geral por estarem envolvidos dois protocolos, e não remova uma regra de tradução existente sem saber do que depende. Depois verifique o único fluxo de ponta a ponta e teste também uma origem ou porta não permitida: um handshake a funcionar de cada lado não prova nem a rota cruzada nem o isolamento.