As mesmas rotas em VPN - como contornar?

Question

Eu só tenho experiência básica com VPNs (principalmente OpenVPN) e principalmente teórico, mas agora quero configurar algo mais complexo e estou avaliando os possíveis problemas que eu possa enfrentar. Tentarei representar a situação hipotética por meio de exemplos. Vamos supor o OpenVPN para esta configuração.

Eu tenho um servidor principal que irá executar o cliente OpenVPN e diferentes locais remotos que terão diferentes servidores OpenVPN. Abrirei diferentes túneis ao mesmo tempo do servidor principal para esses locais remotos. Digamos que eu tenha dez túneis diferentes abertos ao mesmo tempo.

Cada um dos túneis terá um IP local atribuído ao cliente, por exemplo:

10.0.0.2/24 (tunnel A)

10.0.1.2/24 (tunnel B)

10.0.2.2/24 (tunnel C)

...

Assim, por exemplo, o servidor OpenVPN no túnel A seria 10.0.0.1/24 . Se eu quiser acessar algum recurso dentro da LAN do túnel A - por exemplo, um Apache rodando em 172.16.0.50 , eu apenas colocaria o IP no computador do meu cliente VPN e eu atingirei o servidor web (assumindo que todas as rotas estão ok).

Minhas principais preocupações estão em ter diferentes túneis ao mesmo tempo e vários serviços sendo executados sob o mesmo IP local. Tomando o exemplo acima:

Tunnel A: server 10.0.0.1/24, client 10.0.0.2/24, Apache 172.16.0.50

Tunnel B: server 10.0.1.1/24, client 10.0.1.2/24, Apache 172.16.0.50

Neste exemplo em particular, temos duas instâncias do Apache sendo executadas em redes diferentes, mas compartilhando o mesmo IP local, portanto, quando as entradas do cliente 172.16.0.50 enquanto os dois túneis estão ativos, eu acho que irá falhar.

Não tenho certeza se meu palpite está correto, mas aposto que essa não é uma situação tão atípica. Alguém pode explicar o que precisa ser feito nesta situação?

EDITAR: Minhas desculpas se eu não tiver sido claro o suficiente - deixe-me simplificar o problema em etapas simples:

• Dois servidores VPN (VPN1 e VPN2) e um cliente VPN
• VPN1 e VPN2 compartilham os mesmos IPs da LAN para seus serviços internos: 172.16.0.0/24
• Tanto a VPN1 quanto a VPN2 têm um Apache em execução em 172.16.0.50
• O cliente VPN se conecta a ambos os servidores VPN (VPN1 e VPN2)
• Problema - > Ambos têm a mesma numeração de LAN (172.16.0.0/24) e também o Apache está executando sob o mesmo IP
• Pergunta - > Existe uma maneira de resolver isso além de alterar a LAN (e, portanto, o IP do Apache) em um dos servidores VPN?

Answer 1

Não, não há uma maneira convincente e sem problemas de fazer isso.

Na camada 3, quando os dois túneis estão ativos, o cliente não tem como distinguir 172.16.0.50-via-tunnel-1 de 172.16.0.50-via-tunnel-2 ; O IP simplesmente não suporta esse tipo de tomada de decisão (roteamento de código-fonte do módulo, que será muito doloroso e mal suportado).

Existem alguns hacks imundos que você poderia usar: você poderia ter o NAT no cliente sobreposto a dois intervalos diferentes de RFC1918 em cima das duas redes semelhantes e usar o roteamento baseado em políticas para tornar o tráfego

Mas você terá que reescrever tudo o que fizer referência a endereços do intervalo de sobreposição com base em qual túnel ele passa.

Honestamente, será menos doloroso recodificar uma das duas redes de destino. Isso terá o benefício prático de você ser capaz de vincular as duas redes diretamente - e se for desejável para um único cliente entrar em contato com ambas as redes, é apenas uma questão de tempo até que seja desejável interconectá-las diretamente.

Editar : na configuração atual, o mesmo problema afeta essa situação: para qualquer endereço determinado no intervalo de sobreposição, o cliente não tem como saber qual é o túnel deve ser encaminhado para baixo. Você poderia resolver isso apenas dando rotas para 172.16.0.50 através do túnel 1, e 172.16.0.51 via túnel 2. No entanto, isso não vai escalar muito bem, a menos que todos os hosts interessantes em uma LAN sejam em 172.16.0.0/25 e todos os outros em 172.16.0.128/25 . Nesse caso, o re-IPing não deve ser mais doloroso do que mudar a máscara de rede em todos os lugares.

    

Answer 2

Se estiver OK que o tráfego seja roteado por VPN1 por padrão e VPN2 como backup, dividir a rota enviada em intervalos de 2/25 em VPN1 e pressionar o total / 24 em VPN2 resultaria na correção.

Caso a VPN1 esteja desativada e as rotas 2/25 sejam removidas, ela ainda terá o / 24 da VPN2, portanto, você obterá alta disponibilidade, embora sem o balanceamento de carga.

Então, na VPN1, você pode fazer:

push "route 172.16.0.0 255.255.255.128"
push "route 172.16.0.128 255.255.255.128"

enquanto na VPN2 você faria:

push "route 172.16.0.0 255.255.255.0"

Como a rota mais "estreita" tem precedência, o cliente prefere VPN1 sobre VPN2.

Você também poderia especificar um route-metric do lado do cliente nas configurações do cliente, por exemplo, na configuração do cliente para VPN1:

route-metric 200

e no da VPN2:

route-metric 201