OpenVPN precisa de um parâmetro de gateway para a opção --route

Question

Eu tenho um cliente OpenVPN que não está se conectando ao servidor vpn. Eu colei o log completo abaixo, mas, em particular, estou recebendo esses problemas com a rota:

OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options

OpenVPN ROUTE: failed to parse/resolve route for host/network: 10.8.0.1

Existem muitos clientes com a mesma configuração de cliente que estão se conectando muito bem. Este cliente (e alguns outros) foi conectado, perdeu a conexão devido ao tempo do sistema ficar muito fora de sincronia (acredito), já sincronizou a hora do sistema, mas agora ainda é incapaz de se conectar. Geralmente, reiniciar o sistema corrige o problema. Por isso, não parece ser um problema com a configuração da VPN, mas algo com o sistema do cliente.

Eu realmente não sei o suficiente para entender os problemas de rota ou corrigi-los. Eu preciso lidar com a recuperação do problema de sincronização de horário, mas, por enquanto, por que não consigo iniciar manualmente uma conexão VPN desse cliente? O que faria com que o OpenVPN agora precisasse de um parâmetro de gateway?

log

$ openvpn gatewaymaster.conf
Fri Sep 30 12:03:07 2016 OpenVPN 2.2.1 arm-linux-gnueabihf [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Dec  1 2014
Fri Sep 30 12:03:07 2016 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Fri Sep 30 12:03:07 2016 LZO compression initialized
Fri Sep 30 12:03:07 2016 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri Sep 30 12:03:07 2016 Socket Buffers: R=[163840->131072] S=[163840->131072]
Fri Sep 30 12:03:07 2016 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Fri Sep 30 12:03:07 2016 Local Options hash (VER=V4): '41690919'
Fri Sep 30 12:03:07 2016 Expected Remote Options hash (VER=V4): '530fdded'
Fri Sep 30 12:03:07 2016 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Fri Sep 30 12:03:07 2016 UDPv4 link local: [undef]
Fri Sep 30 12:03:07 2016 UDPv4 link remote: [AF_INET]NNN.NNN.NNN.NNN:NNNN
Fri Sep 30 12:03:07 2016 TLS: Initial packet from [AF_INET]NNN.NNN.NNN.NNN:NNNN, sid=679c9108 60cb4eaf
Fri Sep 30 12:03:07 2016 VERIFY OK: depth=1, <redacted>
Fri Sep 30 12:03:07 2016 VERIFY OK: nsCertType=SERVER
Fri Sep 30 12:03:07 2016 VERIFY OK: depth=0, <redacted>
Fri Sep 30 12:03:08 2016 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 30 12:03:08 2016 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 30 12:03:08 2016 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Sep 30 12:03:08 2016 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Sep 30 12:03:08 2016 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Fri Sep 30 12:03:08 2016 [server] Peer Connection Initiated with [AF_INET]NNN.NNN.NNN.NNN:NNNN
Fri Sep 30 12:03:10 2016 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Fri Sep 30 12:03:10 2016 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,route 10.8.0.1,topology net30,ping 10,ping-restart 120'
Fri Sep 30 12:03:10 2016 OPTIONS IMPORT: timers and/or timeouts modified
Fri Sep 30 12:03:10 2016 OPTIONS IMPORT: --ifconfig/up options modified
Fri Sep 30 12:03:10 2016 OPTIONS IMPORT: route options modified
Fri Sep 30 12:03:10 2016 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Fri Sep 30 12:03:10 2016 ROUTE default_gateway=10.1.10.1
Fri Sep 30 12:03:10 2016 OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
Fri Sep 30 12:03:10 2016 OpenVPN ROUTE: failed to parse/resolve route for host/network: 10.8.0.1
Fri Sep 30 12:03:10 2016 TUN/TAP device tun1 opened
Fri Sep 30 12:03:10 2016 TUN/TAP TX queue length set to 100
Fri Sep 30 12:03:10 2016 GID set to nogroup
Fri Sep 30 12:03:10 2016 UID set to nobody
Fri Sep 30 12:03:10 2016 Initialization Sequence Completed

servidor

port NNNN
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS NNN.NN.NNN.NNN"
push "dhcp-option DNS NNN.NN.NNN.NNN"
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
hand-window 120

cliente

client
dev tun
proto udp
remote XXXXX.XXXXX.xxx NNNN
resolve-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
cert client.crt
key client.key
ns-cert-type server
comp-lzo
verb 3

    

Answer 1

Não deve ser obrigatório, mas sugiro adicionar topology subnet no servidor.

A topologia de sub-rede é geralmente uma opção melhor para clientes mais novos. Quando você usa a sub-rede de topologia, ele executa automaticamente um push "route-gateway 10.8.0.1" para enviar um gateway correto para o cliente.

There are currently 62 connected clients. That alone sounds promising. Can you point me to options that increase the max number of hosts?

Ah, esta é a sua explicação. Sua opção server 10.8.0.0 255.255.255.0 com a topologia net30 padrão aloca uma rede / 30 desse pool 10.8.0.0/24 por sistema. Portanto, 10.8.0.0/30 vai para o servidor, 10.8.0.4/30 vai para o primeiro cliente, 10.8.0.8/30 vai para o segundo cliente e assim por diante até 10.8.0.252.0/30 para o último cliente.

Você tem duas opções para corrigir isso, pode alterar seu tamanho de sub-rede na instrução do servidor e aumentar sua sub-rede. Isso pode me fazer você precisar atualizar qualquer tabela de roteamento em outros dispositivos em sua rede e alterar regras de firewall.

Ou a solução provavelmente mais fácil é mudar para a sub-rede de topologia . Isso faz com que você não use essa topologia ponto-a-ponto do psuedo e faz com que ela funcione basicamente como um switch ethernet. Cada host em uma topologia de sub-rede usa um e apenas um dos ~ 253 clientes conectados em vez dos clientes conectados (256 / 4-1). A única razão para ficar com a topologia mais antiga é se você tem clientes realmente antigos se conectando.