Servidor OpenVPN enviando informações de gateway padrão falsas para o cliente?

Question

Embora o cliente VPN se conecte com sucesso ao servidor OpenVPN, ele parece estar configurando um gateway incorreto e falso, independentemente das permutações de push "redirect-gateway local def1" e / ou push "route 10.240.0.0 255.255.0.0" colocadas / comentadas / descomentadas no arquivo server.conf .

O arquivo server.conf tem essa declaração server 10.8.0.0 255.255.255.0 e, de fato, o servidor é atribuído 10.8.0.1 , mas por algum motivo o cliente interpreta as mensagens enviadas durante a iniciação da VPN para rotear o tráfego através de um gateway padrão %código%. De acordo com o Wireshark, qualquer pacote subseqüente é enviado para 10.8.0.5 e nunca recebe nenhuma resposta, como se esses pacotes chegassem ao ponto final da VPN TCP, parece que eles nunca chegam à interface tun0 do servidor (de acordo com 10.8.0.5 no servidor .

Aqui estão as linhas relevantes do log do cliente OpenVPN (Tunnelblick) indicando a mudança na tabela de roteamento imediatamente após a conexão com a VPN:

2015-12-11 02:25:18 /sbin/ifconfig utun0 10.8.0.6 10.8.0.5 mtu 1500 netmask 255.255.255.255 up
2015-12-11 02:25:18 /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -d -f -m -w -pxxxxxxxxxxx utun0 1500 1543 10.8.0.6 10.8.0.5 init
                                        **********************************************
                                        Start of output from client.up.tunnelblick.sh
                                        No network configuration changes need to be made.
                                        Will NOT monitor for other network configuration changes.
                                        DNS servers '8.8.8.8 208.67.222.222' will be used for DNS queries when the VPN is active
                                        The DNS servers include only free public DNS servers known to Tunnelblick.
                                        Flushed the DNS cache via dscacheutil
                                        /usr/sbin/discoveryutil not present. Not flushing the DNS cache via discoveryutil
                                        Notified mDNSResponder that the DNS cache was flushed
                                        End of output from client.up.tunnelblick.sh
                                        **********************************************
                                        add net 104.196.7.35: gateway 192.168.0.1
                                        add net 0.0.0.0: gateway 10.8.0.5
                                        add net 128.0.0.0: gateway 10.8.0.5
                                        add net 10.240.0.0: gateway 10.8.0.5
                                        add net 10.8.0.0: gateway 10.8.0.5
2015-12-11 02:25:20 Initialization Sequence Completed

Existe alguma maneira de forçar o OpenVPN a enviar as informações corretas para o cliente? Ou estou errado e há outra razão pela qual os pacotes enviados corretamente para a porta TCP do OpenVPN não estão fazendo isso na interface tcpdump no servidor OpenVPN?

    

Answer 1

Não, isso está correto.

Seu OpenVPN funciona no modo de topologia "net30". Neste modo, o próprio processo OpenVPN é um roteador. Na realidade, o esquema de rede virtual se parece com isso:

                                   Client3
                                 10.8.0.14/30
                                    |
                                 10.8.0.13/30
Server 10.8.0.1/30 --- 10.8.0.2/30 OpenVPN 10.8.0.5/30 --- 10.8.0.6/30 Client1
                                 10.8.0.9/30
                                    |
                                 10.8.0.10/30
                                   Client2

com todos, incluindo o servidor, com a rota adicional 10.8.0.0/24 via 10.8.0.x (x - seu respectivo endereço dentro do próximo salto do OpenVPN).

Ou seja. 10.8.0.5 é realmente um endereço do roteador OpenVPN, é "escondido dentro de um processo". Isso é necessário se você quiser unir o Windows à sua VPN, pois no Windows não é possível criar uma interface TUN real e é emualted com o TAP e a configuração acima.

Este é também o motivo da existência da opção "iroute". Ele é usado para configurar rotas dentro deste roteador virtual.

Se você nunca quiser incluir clientes do Windows em sua VPN, você pode configurar o modo de topologia para p2p e esperar rotas diretas de .1 em clientes.

Por favor, consulte a seção manual de topologia do link do OpenVPN para detalhes.