Problemas de Roteamento Site-to-Site do OpenVPN

1

Estou lutando com uma configuração openVPN para conectar dois sites. É assim que o cenário se parece

Office 1 (servidor):

  • rede local: 192.168.178.0/24
  • servidor openvpn ip público: 192.168.178.2 em br0
  • ip interno do servidor openvpn: 192.168.0.1 no tun0

Office 2 (cliente):

  • rede local: 192.168.177.0/24
  • ip público do cliente openvpn: 192.168.177.2 no p2p1
  • ip interno do cliente do openvpn: 192.168.0.6 no tun0

  • rede interna openvpn: 192.168.0.0/24

Ambos, o cliente e o servidor, estão atrás de roteadores NAT com endereços IP atribuídos dinamicamente.

Basicamente, as máquinas envolvidas em qualquer escritório devem "ver" umas as outras. Depois de configurar o túnel e configurar corretamente as tabelas de roteamento em ambos os sites, os hosts regulares em ambas as redes podem executar ping em todas essas duas redes. Bom até agora.

No entanto, os pontos de extremidade só podem ver um ao outro, mas nenhum dos hosts em sua respectiva rede de extremidade distante. Por exemplo, se um

ping 192.168.178.2

do endpoint VPN 192.168.177.2, ele funciona muito bem, qualquer outro endereço não funcionará; os anfitriões não responderão.

Agora, observe a saída do tcpdump, quando faço ping em outro endereço, por exemplo, 192.168.178.3.

11:11:28.104640 IP 192.168.0.6 > 192.168.178.3: ICMP echo request, id 2130, seq 1, length 64

O IP de origem não parece correto. Pertence à rede interna do OpenVPN e não recebo resposta do ICMP.

As coisas começam a funcionar quando eu instruo explicitamente o ping a usar o IP de origem adequado:

ping 192.168.178.3 -I 192.168.177.2

Agora, a saída do tcpdump também está ok:

11:20:08.266271 IP 192.168.177.2 > 192.168.178.3: ICMP echo request, id 7883, seq 17, length 64 11:20:08.316037 IP 192.168.178.3 > 192.168.177.2: ICMP echo reply, id 7883, seq 17, length 64

Olhando para a entrada crítica na tabela de roteamento do cliente, é óbvio que o endereço de origem é da rede interna:

default via 192.168.177.1 dev p2p1 
192.168.0.1 via 192.168.0.5 dev tun0 
192.168.0.5 dev tun0  proto kernel  scope link  src 192.168.0.6 
192.168.177.0/24 dev p2p1  proto kernel  scope link  src 192.168.177.2 
192.168.178.0/24 via 192.168.0.5 dev tun0

Existe a possibilidade de fazer o OpenVPN criar essa entrada com um src ??

apropriado?

Aqui estão os meus arquivos de configuração do openVPN. Vou pular as partes do TLS, já que o próprio túnel funciona como esperado.

Servidor no escritório 1:

local 192.168.178.2
server 192.168.0.0 255.255.255.0
proto tcp-server
port 1194
dev tun
mssfix
user nobody
group nogroup

keepalive 20 120
ping-timer-rem
persist-tun
persist-key
float
comp-lzo
push "comp-lzo"

push "route 192.168.178.0 255.255.255.0"
route 192.168.177.0 255.255.255.0
client-config-dir client-configs

Existe uma configuração de cliente, que se parece com isso:

iroute  192.168.177.0 255.255.255.0
push    "route 192.168.178.0 255.255.255.0 vpn_gateway"

Cliente no escritório 2:

client
dev tun0
remote <server address>
proto tcp-client
port 1194
connect-retry 15


comp-lzo
user nobody
group nogroup

persist-tun
persist-key

Eu estou realmente perdido aqui ... sua ajuda é muito apreciada.

    
por Armin Schmidt 23.07.2014 / 14:12

1 resposta

2

O comportamento que você está vendo é por design. Um host em uma rede usará por padrão o endereço IP da interface onde o tráfego está saindo como o IP de origem.

Uma máquina cliente em uma das LANs usará, por exemplo, 192.168.178.10 como seu IP de origem, porque não é multihomed. O gateway roteará o pacote para sua caixa OpenVPN e passará pelo túnel sem problemas.

No entanto, se você estiver indo da própria caixa OpenVPN, ele usará o endereço IP da interface do OpenVPN, já que é onde o pacote deve sair.

O que está bem. Atinge o site remoto. Mas então o site remoto quer enviar pacotes para a resposta do ping para 192.168.0.6. A resposta vai para o gateway, mas desde que o gateway (eu estou assumindo, desde que você não postou as tabelas de roteamento do gateway na rede) não tem uma rota para essa rede, ele não sabe como prossiga.

A maneira mais fácil de resolver isso seria simplesmente adicionar uma rota para 192.168.0.0/24 (sua rede OpenVPN) aos gateways de ambas as redes.

Outra opção, se o seu sistema operacional o suportar (você não especificou em qual SO você está executando o OpenVPN), será para ver se você pode usar o parâmetro "src" de uma rota para sobrescrever este comportamento padrão de escolha o endereço IP da interface de saída. Consulte a pergunta intitulada Como definir uma rota personalizada fonte em openvpn para mais informações.

    
por 23.07.2014 / 17:04