У меня есть клиент OpenVPN, который не подключается к серверу vpn. Я вставил полный журнал ниже, но, в частности, у меня возникают следующие проблемы с маршрутом:
OpenVPN ROUTE: OpenVPN нуждается в параметре шлюза для параметра --route, а параметры по умолчанию не были указаны ни в параметрах --route-gateway, ни в параметрах --ifconfig.
OpenVPN ROUTE: не удалось проанализировать / разрешить маршрут для хоста / сети: 10.8.0.1
Есть много клиентов с одинаковой конфигурацией, которые нормально подключаются. Этот клиент (и несколько других) был подключен, потерял соединение из-за того, что системное время стало слишком далеко от синхронизации (я полагаю), с тех пор синхронизировал системное время, но теперь все еще не может подключиться. Обычно проблема решается перезапуском системы. Так что проблема не в конфигурации VPN, а в клиентской системе.
Я действительно не знаю достаточно, чтобы понять проблемы маршрута или исправить их. Мне действительно нужно решить проблему с синхронизацией времени, но почему я не могу вручную запустить VPN-соединение с этого клиента? Что может заставить OpenVPN теперь нуждаться в параметре шлюза?
журнал
$ 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
сервер
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
клиент
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
Это не обязательно, но я предлагаю добавить topology subnet на сервере.
Топология подсети обычно является лучшим вариантом для новых клиентов. Когда вы используете подсеть топологии, она автоматически выполняет push "route-gateway 10.8.0.1" чтобы отправить клиенту правильный шлюз.
В настоящее время подключено 62 клиента. Уже одно это звучит многообещающе. Можете ли вы указать мне варианты, которые увеличивают максимальное количество хостов?
А вот ваше объяснение. Ваш server 10.8.0.0 255.255.255.0 вариант со значением по умолчанию net30 топология выделяет сеть / 30 из этого пула 10.8.0.0/24 на систему. Так 10.8.0.0/30 идет на сервер, 10.8.0.4/30 идет к первому клиенту, 10.8.0.8/30 переходит ко второму клиенту, и так до 10.8.0.252/30 последнему клиенту.
У вас есть два варианта исправить это, вы можете измените размер вашей подсети в операторе сервера и увеличьте вашу подсеть. Это может означать, что вам необходимо обновить любые таблицы маршрутизации на других устройствах в вашей сети и изменить правила брандмауэра.
Или, вероятно, более простое решение - переключиться на подсеть топологии. Это заставляет вас не использовать эту псевдо-двухточечную топологию и заставляет ее действовать как коммутатор Ethernet. Каждый хост в топологии подсети использует одного и только одного из ~ 253 подключенных клиентов вместо (256 / 4-1) подключенных клиентов. Единственная причина, по которой следует придерживаться старой топологии, - это если у вас действительно старые клиенты подключаются.