OpenVPN com o MacOS X Client e as mesmas sub-redes na rede local e remota

2

Eu tenho uma homenetwork 192.168.1.0/24 com o gateway 192.168.1.1 e uma rede remota com os mesmos parâmetros. Agora eu quero criar um túnel OpenVPN entre essas redes.

Não tenho problemas com o Windows, porque o Windows direciona tudo para 192.168.1.0/24, exceto 192.168.1.1 através do túnel.

No Mac OS X, porém, vejo a seguinte linha na janela Detalhes:

2010-05-10 09:13:01 WARNING: potential route subnet conflict between local LAN [192.168.1.0/255.255.255.0] and remote VPN [192.168.1.0/255.255.255.0]

Quando eu listo as rotas, recebo o seguinte:

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            192.168.1.1        UGSc       13        3    en1
127                localhost          UCS         0        0    lo0
localhost          localhost          UH         12     3589    lo0
169.254            link#5             UCS         0        0    en1
192.168.1          link#5             UCS         1        0    en1
192.168.1.1        0:1e:e5:f4:ec:7f   UHLW       13       17    en1   1103
192.168.1.101      localhost          UHS         0        0    lo0
192.168.6          192.168.6.5        UGSc        0        0   tun0
192.168.6.5        192.168.6.6        UH          1        0   tun0

Minhas Interfaces são

en1 - My local Wifi network
tun0 - The tunnel interface

Como pode ser visto nas rotas acima, não há entrada para 192.168.1.0/24 que direciona o tráfego pela interface do túnel.

Quando eu rotear manualmente um único IP como 192.168.1.16 pelo gateway de túnel 192.168.6.6, isso funciona.

P: Como faço para configurar minhas rotas no MacOS X para o mesmo comportamento das janelas, para rotear tudo, exceto 192.168.1.1, através do túnel, mas deixar o gateway padrão como meu 192.168.1.1 local?

EDIT: reabri a questão porque não foi totalmente respondida na primeira vez.

A máquina VPN-Client não precisa acessar sua própria sub-rede, exceto o roteador, e os pacotes TCP devem pegar o túnel, exceto os próprios pacotes tunnelled.

    
por Daniel 10.05.2010 / 07:19

2 respostas

1

Eu não acho que o roteamento deva funcionar assim. Essencialmente, suas duas redes são as mesmas no que diz respeito ao IPv4. A VPN não muda isso. Você não usa roteadores para conectar duas partes da mesma rede; você precisa de pontes para isso.

Eu nunca fiz isso, mas acho que você tem algumas opções.

  • Configure os gateways do OpenVPN em modo de ponte . Contanto que não haja conflitos de IP (uma máquina em cada rede com o mesmo IP, por exemplo, 192.168.1.100), isso deve funcionar. Se você estiver usando o DHCP, precisará lidar com possíveis sobreposições; você não quer dois servidores DHCP na mesma rede.

    De acordo com o link, você tem duas opções para alocação de IP:

    • Let OpenVPN manage its own client IP address pool using the server-bridge directive, or
    • configure the DHCP server on the LAN to also grant IP address leases to VPN clients.


  • Configure uma rede para outro endereço de rede. Basta alterar 192.168.1 / 24 em uma rede para 192.168.7 / 24 (ou algum outro endereço). Isso definitivamente funcionará e você só precisará reconfigurar uma rede.

  • Sub-rede 192.168.1 / 24 em duas / 25 redes (por exemplo, 192.168.1.0/25 e > 192.168.1.128/25 ). Isso também funcionará, mas você terá que reconfigurar ambas as redes. (Para referência, a máscara de rede em um / 25 é 255.255.255.128 ).

por 10.05.2010 / 08:18
2

Eu tive exatamente o problema. Adicionando a seguinte chamada de script no meu arquivo de configuração de conexão do ovpn resolveu:

route-delay 2
route-up /Users/user/.local/bin/vpn-routes

Em que o script atribui novamente a rota padrão manualmente, conforme mostrado abaixo:

#!/bin/bash

/sbin/route delete default
/sbin/route delete 0/1
/sbin/route add default $route_net_gateway

Isso funcionou muito bem até que eu fiz o upgrade para o Mountain Lion. Atualizei para a versão beta mais recente do Tunnelblick, mas o script acima parece não funcionar (acho que por causa de problemas de permissão, ainda estou investigando isso)

    
por 28.07.2012 / 21:00