Jump to content
KorDen

Вопросы по интеграции OpenVPN в NDMS

Recommended Posts

1 минуту назад, Вежливый Снайпер сказал:

Без проблем, но придется в ручную настраивать маршруты. Либо через конфиг файл, например:

либо напрямую, в интерфейсе роутера Сетевые правила > Маршрутизация с выбором интерфейса.

Собственно только так у меня antizapret и работал. Потом купил VPS за 4 еврика и сам все настроил. Без роутера, ибо не помощник он при канале 100 Мбит/с до VPN.

Гнать весь трафик через VPN ради обхода блокировок это всё-равно что использовать Камаз как личное авто. Даже если ресурсы роутера позволяют, то задержка всё-равно ощутимая. Да и Антизапрет бесплатен и 4 еврика можно оставить при себе. И маршруты никакие настраивать не надо.

Share this post


Link to post
Share on other sites

дайте пожалуйста рабочий конфиг для антизапрета уже с ключами......пробовал по инструкции соединение устанавливается но сайты не открывает....может я с конфигом,что напортачил))))

Edited by Дмитрий Воронцов

Share this post


Link to post
Share on other sites
1 час назад, Кинетиковод сказал:

Гнать весь трафик через VPN ради обхода блокировок это всё-равно что использовать Камаз как личное авто. Даже если ресурсы роутера позволяют, то задержка всё-равно ощутимая. Да и Антизапрет бесплатен и 4 еврика можно оставить при себе. И маршруты никакие настраивать не надо.

Вы наверное имеете какое-то отношение к администрации форума и/или разработчикам кинетика? Раз про камаз заговорили.

Ничего подобного. +~20ms (в моем случае) погоды не сделают. IP адреса блокируются огромными пачками.. да и не все из них попадают в выгрузку к маленьким операторам и становятся доступными широкой общественности. И если вы не в курсе, то действует пакет яровой, что меня лично не очень устраивает. Пусть хранят на здоровье зашифрованный трафик.

Пробовал уже антизапрет настраивать. Костыльно все это в случае с кинетиками. Когда накроется мой старичок, куплю что-то от нормальных производителей, куда встанет OpenWRT.

Если маршруты настраивать не надо, дайте ТСу готовый рецепт.

Share this post


Link to post
Share on other sites

Господа, добрый вечер!

Настраиваю OpenVPN клиент на своём Keenetic Extra. Что-то голову сломал - не могу понять в чём дело. Стоит свой Ubuntu 16.04 со сконфигурированный OpenVPN сервером, телефон и ноут цепляются без вопросов через OpenVPN приложения, а вот роутер ведёт себя странно. Подскажите пожалуйста, в чем может быть проблема. Забавно то, что соединение как будто происходит, в UI написано, что соединение установлено, написан по идее внутренний адрес роутера, но на деле ping этого адреса с машины-сервера 100% packet loss:

image.png.fe11bf03286e115114e791383d747f2f.png

Вот конфигурация клиента:

client
dev tun
proto tcp
remote 168.63.78.151 443
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
comp-lzo
verb 3
cipher AES-128-CBC
auth SHA256

key-direction 1

<tls-auth>
</tls-auth>
<ca>
</ca>
<cert>
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----
</key>

Вот лог с роутера:

Dec 22 23:07:56 OpenVPN0
OpenVPN 2.4.6 [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [AEAD]
Dec 22 23:07:56 OpenVPN0
library versions: OpenSSL 1.1.1a 20 Nov 2018, LZO 2.10
Dec 22 23:07:56 OpenVPN0
Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Dec 22 23:07:56 OpenVPN0
Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Dec 22 23:07:56 OpenVPN0
Socket Buffers: R=[87380->87380] S=[16384->16384]
Dec 22 23:07:56 OpenVPN0
Attempting to establish TCP connection with [AF_INET]168.63.78.151:443 [nonblock]
Dec 22 23:07:57 OpenVPN0
TCP connection established with [AF_INET]168.63.78.151:443
Dec 22 23:07:57 OpenVPN0
TCP_CLIENT link local: (not bound)
Dec 22 23:07:57 OpenVPN0
TCP_CLIENT link remote: [AF_INET]168.63.78.151:443
Dec 22 23:07:57 OpenVPN0
NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Dec 22 23:07:57 OpenVPN0
TLS: Initial packet from [AF_INET]168.63.78.151:443, sid=75da2256 3936274e
Dec 22 23:07:58 OpenVPN0
VERIFY SCRIPT OK: depth=1, C=UK, ST=UK, L=London, O=m, OU=m, CN=m CA, name=server, emailAddress=m@m.com
Dec 22 23:07:58 OpenVPN0
VERIFY OK: depth=1, C=UK, ST=UK, L=London, O=m, OU=m, CN=m CA, name=server, emailAddress=m@m.com
Dec 22 23:07:58 OpenVPN0
VERIFY KU OK
Dec 22 23:07:58 OpenVPN0
Validating certificate extended key usage
Dec 22 23:07:58 OpenVPN0
++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Dec 22 23:07:58 OpenVPN0
VERIFY EKU OK
Dec 22 23:07:58 OpenVPN0
VERIFY SCRIPT OK: depth=0, C=UK, ST=UK, L=London, O=m, OU=m, CN=m, name=server, emailAddress=m@m.com
Dec 22 23:07:58 OpenVPN0
VERIFY OK: depth=0, C=UK, ST=UK, L=London, O=m, OU=m, CN=m, name=server, emailAddress=m@m.com
Dec 22 23:07:59 OpenVPN0
Control Channel: TLSv1.2, cipher TLSv1.2 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Dec 22 23:07:59 OpenVPN0
[matteraiserver] Peer Connection Initiated with [AF_INET]168.63.78.151:443
Dec 22 23:07:59 ndm
Network::Interface::OpenVpn: "OpenVPN0": connecting via ISP (FastEthernet0/Vlan2).
Dec 22 23:07:59 ndm
Network::Interface::OpenVpn: "OpenVPN0": added host route to remote endpoint 168.63.78.151 via 188.243.88.1.
Dec 22 23:08:00 OpenVPN0
SENT CONTROL [matteraiserver]: 'PUSH_REQUEST' (status=1)
Dec 22 23:08:00 OpenVPN0
PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,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,ifconfig 10.8.0.14 10.8.0.13'
Dec 22 23:08:00 OpenVPN0
OPTIONS IMPORT: timers and/or timeouts modified
Dec 22 23:08:00 OpenVPN0
OPTIONS IMPORT: --ifconfig/up options modified
Dec 22 23:08:00 OpenVPN0
OPTIONS IMPORT: route options modified
Dec 22 23:08:00 OpenVPN0
OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Dec 22 23:08:00 OpenVPN0
Outgoing Data Channel: Cipher 'AES-128-CBC' initialized with 128 bit key
Dec 22 23:08:00 OpenVPN0
Outgoing Data Channel: Using 256 bit message hash 'SHA256' for HMAC authentication
Dec 22 23:08:00 OpenVPN0
Incoming Data Channel: Cipher 'AES-128-CBC' initialized with 128 bit key
Dec 22 23:08:00 OpenVPN0
Incoming Data Channel: Using 256 bit message hash 'SHA256' for HMAC authentication
Dec 22 23:08:00 OpenVPN0
TUN/TAP device tun0 opened
Dec 22 23:08:00 OpenVPN0
TUN/TAP TX queue length set to 100
Dec 22 23:08:00 OpenVPN0
do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Dec 22 23:08:00 ndm
Network::Interface::IP: "OpenVPN0": IP address is 10.8.0.14/32.
Dec 22 23:08:00 ndm
Network::Interface::OpenVpn: "OpenVPN0": TUN peer address is 10.8.0.13.
Dec 22 23:08:00 ndm
Network::Interface::OpenVpn: "OpenVPN0": added host route to peer 10.8.0.13 via 10.8.0.14.
Dec 22 23:08:00 ndm
Network::Interface::OpenVpn: "OpenVPN0": install accepted default route via 10.8.0.14.
Dec 22 23:08:00 ndm
Network::Interface::OpenVpn: "OpenVPN0": install accepted route to 10.8.0.1/255.255.255.255 via 10.8.0.14.
Dec 22 23:08:01 ndm
Network::Interface::OpenVpn: "OpenVPN0": adding nameserver 208.67.222.222.
Dec 22 23:08:01 ndm
Dns::Manager: name server 208.67.222.222 added, domain (default).
Dec 22 23:08:01 ndm
Network::RoutingTable: gateway 10.8.0.13 is unreachable via OpenVPN0.
Dec 22 23:08:01 ndm
Network::Interface::OpenVpn: "OpenVPN0": failed to add a nameserver route.
Dec 22 23:08:01 ndm
Network::Interface::OpenVpn: "OpenVPN0": adding nameserver 208.67.220.220.
Dec 22 23:08:01 ndm
Dns::Manager: name server 208.67.220.220 added, domain (default).
Dec 22 23:08:01 ndm
Network::RoutingTable: gateway 10.8.0.13 is unreachable via OpenVPN0.
Dec 22 23:08:01 ndm
Network::Interface::OpenVpn: "OpenVPN0": failed to add a nameserver route.
Dec 22 23:08:01 OpenVPN0
GID set to nobody
Dec 22 23:08:01 OpenVPN0
UID set to nobody
Dec 22 23:08:01 OpenVPN0
Initialization Sequence Completed

А, и еще. Забавно то, что сервис Whatismyip выдаёт правильный IP, как будто бы я подключен! Но при этом в linkedin не зайти, например. А на телефоне и ноутбуке порядок.

Буду вам очень благодарен за терпение, даже если вопрос был. Я прочитал бОльшую часть темы, и честно говоря не нашел ответа, хотя попробовал разные предлагаемые решения.

Share this post


Link to post
Share on other sites

@matterai обратите внимание на строки лога, где 

options modified

некоторые опции конфига и те, которые идут через push/pull могут игнорироваться. Нужно настраивать такое иначе. Вот мои рабочие конфиги сервера и клиента

port 2195
proto udp
dev tun
sndbuf 0
rcvbuf 0
ca ca.crt
cert server.crt
key server.key
dh dh.pem
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 4.2.2.2"
push "dhcp-option DNS 8.8.8.8"
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3
crl-verify crl.pem

и

client
dev tun
proto udp
sndbuf 0
rcvbuf 0
remote xx.xx.xx.xx 2195
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
comp-lzo
verb 3
<ca>
-----BEGIN CERTIFICATE-----
....

 

Share this post


Link to post
Share on other sites

Клиентские настройки у нас более менее одинаковые, за исключением наличия в ваших следующих строк, касающихся буфера:

sndbuf 0
rcvbuf 0

Из options modified у меня 4 потенциально изменяемых параметра, насколько я могу судить:

Dec 22 23:08:00 OpenVPN0
OPTIONS IMPORT: timers and/or timeouts modified
Dec 22 23:08:00 OpenVPN0
OPTIONS IMPORT: --ifconfig/up options modified
Dec 22 23:08:00 OpenVPN0
OPTIONS IMPORT: route options modified
Dec 22 23:08:00 OpenVPN0
OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified

Черт с ним с timers/timeouts. Но что значит --ifconfig/up options modified? И почему вдруг (и где) изменился route? Про 4-ый параметр вообще молчу, не очень понимаю вообще о чём в нём речь. Возможно, меня не очень вразумил ваш ответ, прошу прощения, не могли бы вы чуть конкретнее разъяснить в чем проблемы изменяющихся опций, или подсказать какой-то мануал/гайд, где бы это как-то было освещено?

Спасибо.

UPD

Надо было на строчку выше взглянуть: из push_reply от сервера импортируются опции и изменяются на клиенте, поэтому и modified. Выглядит весьма логично. В чём подвох?.. Почему я далее по логам получаю:

gateway 10.8.0.13 is unreachable via OpenVPN0.
Edited by matterai
Дополнение к посту.

Share this post


Link to post
Share on other sites
51 минуту назад, matterai сказал:

'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,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,ifconfig 10.8.0.14 10.8.0.13'

Сюда смотрите - Вы пушите опцию, и она, похоже не срабатывает. Это в настройках сервера. Все это мои предположения.

У меня заработало фактически из коробки. Одну строку конфига клиента пришлось выбросить.

Share this post


Link to post
Share on other sites

Я проверял - это все логи, что доступны после отключения и включения VPN.

Пока не вижу проблемы, к сожалению. PUSH_REPLY пришёл, опции изменились, порядок. Меня больше вот эти строки смущают, потому что я пока не очень понимаю что происходит на этом этапе:

Dec 22 23:08:00 ndm
Network::Interface::IP: "OpenVPN0": IP address is 10.8.0.14/32.
Dec 22 23:08:00 ndm
Network::Interface::OpenVpn: "OpenVPN0": TUN peer address is 10.8.0.13.
Dec 22 23:08:00 ndm
Network::Interface::OpenVpn: "OpenVPN0": added host route to peer 10.8.0.13 via 10.8.0.14.

Правильно ли я понимаю, что мне назначен IP: 10.8.0.14? И если да, то что происходит дальше? К слову, если пинговать с сервера, то ни 10.8.0.13, ни 10.8.0.14 недоступны.

Гадость какая-то =( 

Share this post


Link to post
Share on other sites
3 минуты назад, matterai сказал:

Гадость какая-то =( 

Я предпочитаю topology=subnet. Все прозрачно тогда и понятно.

Попробуйте перезагрузить роутер, ну и другие пляски с бубном. В начале темы описано, что пересохранение конфига клиента (без изменений) решило подобную проблему.

Share this post


Link to post
Share on other sites

Хорошо, спасибо больше за уделенное время и то, что подкинули идеи, куда глядеть. Пойду колдовать над этим чудом дальше. Отпишусь попозже, если что-нибудь придумаю.

Share this post


Link to post
Share on other sites

В продолжении своего вопроса.

Достал со стороны сервера openvpn.log, и вот что нашел:

Sat Dec 22 22:05:31 2018 us=992261 home-network/xxx.xxx.xx.xx:50164 SENT CONTROL [home-network]: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,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,ifconfig 10.8.0.14 10.8.0.13' (status=1)
Sat Dec 22 22:05:32 2018 us=837164 home-network/xxx.xxx.xx.xx:50164 MULTI: bad source address from client [xxx.xxx.xx.xx], packet dropped

где xxx.xxx.xx.xx - это IP моего компьютера, очевидно. Согласно этой и этой ссылкам, сделал необходимые изменения в конфигурационном файле на сервере:

client-config-dir ccd
route 192.168.1.0 255.255.255.0

Перезапустил OpenVPN сервер, перезапустил роутер - ничего не изменилось. Разве что строчка 50164 MULTI: bad source address from client [xxx.xxx.xx.xx], packet dropped ушла из логов.

Может ли быть такое, что OpenVPN по указанному IP xxx.xxx.xx.xx найти не может мою машину? Может ему белый IP нужен? Тогда почему телефон и бук напрямую через VPN приложения могут подключиться без проблем?

Edited by matterai

Share this post


Link to post
Share on other sites

Доброго времени!

Я особо не вчитывался и не вникал в логи, просто промелькнула шальная мысль, попробуйте в межсетевом экране, на интерфейсе OVPN разрешить ICMP.

 

Share this post


Link to post
Share on other sites

@matterai 1. Включите verb=5 (через DebugLog - есть в теме) и посмотрите подробный лог со стороны клиента.

или 

2. попробуйте завести openvpn через Entware с тем же конфигом клиента. Почти наверняка заработает. У меня на одном из кинетиков крутится openvpn из Entware. Правда в качестве сервера. Тема по настройке клиента у меня на форуме.

Share this post


Link to post
Share on other sites

А есть ли возможность сделать так, чтобы dns-proxy использовал dhcp dns только до подключения, а после подключения openvpn клиента и получения push dhcp-option dns (ну, или при указании в клиентском openvpn конфиге dhcp-option DNS) кинетик использовал только DNS, полученный от сервера (или явно указанный в конфиге)?
Сейчас удалось добиться более-менее удобного поведения только полностью отключив dhcp-dns на основном интерфейсе. Если этого не сделать, даже не смотря на то, что vpn dns висит выше в списке show ip name-server, dns реквесты всё равно утекают в сервер, полученный по dhcp, видимо потому что он отвечает быстрее.
Однако это приводит к тому, что до подключения vpn dns не работает, и я не могу, например, указать в конфиге openvpn адрес сервера по доменному имени.
Спасибо.

Edited by alxbz
Уточнил случай при указании dhcp-option в клиентском конфиге

Share this post


Link to post
Share on other sites
В 09.03.2019 в 21:11, alxbz сказал:

А есть ли возможность сделать так, чтобы dns-proxy использовал dhcp dns только до подключения, а после подключения openvpn клиента и получения push dhcp-option dns (ну, или при указании в клиентском openvpn конфиге dhcp-option DNS) кинетик использовал только DNS, полученный от сервера (или явно указанный в конфиге)?
Сейчас удалось добиться более-менее удобного поведения только полностью отключив dhcp-dns на основном интерфейсе. Если этого не сделать, даже не смотря на то, что vpn dns висит выше в списке show ip name-server, dns реквесты всё равно утекают в сервер, полученный по dhcp, видимо потому что он отвечает быстрее.
Однако это приводит к тому, что до подключения vpn dns не работает, и я не могу, например, указать в конфиге openvpn адрес сервера по доменному имени.
Спасибо.

Окольным путем это возможно:

- создаете профиль доступа, где есть только openvpn как wan, а остальных нет
- туда добавляете нужные устройства

В профилях доступа используются только dns, полученные от интерфейсов в этом профиле.

  • Thanks 3

Share this post


Link to post
Share on other sites

Добрый день

После обновления с 2.15.C.3.0-(0?) до 2.15.C.3.0-2 - перестал работать openvpn

[I] Apr 14 11:15:23 OpenVPN1: OpenVPN 2.4.6 [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [AEAD]
[I] Apr 14 11:15:23 OpenVPN1: library versions: OpenSSL 1.1.1b  26 Feb 2019, LZO 2.10
[I] Apr 14 11:15:23 OpenVPN1: Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
[I] Apr 14 11:15:23 OpenVPN1: Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
[I] Apr 14 11:15:23 OpenVPN1: Socket Buffers: R=[155648->155648] S=[155648->155648]
[I] Apr 14 11:15:23 OpenVPN1: UDP link local: (not bound)
[I] Apr 14 11:15:23 OpenVPN1: UDP link remote: [AF_INET]X.X.X.X:4911
[I] Apr 14 11:15:23 OpenVPN1: NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
[E] Apr 14 11:15:23 OpenVPN1: write UDP: Network is unreachable (code=128)
[I] Apr 14 11:15:23 OpenVPN1: Network unreachable, restarting
[I] Apr 14 11:15:23 OpenVPN1: SIGTERM[soft,network-unreachable] received, process exiting
[E] Apr 14 11:15:23 ndm: Service: "OpenVPN1": unexpectedly stopped.

При этом другие устройства (и лэптоп, и телефоны) успешно коннектятся как и раньше.

Share this post


Link to post
Share on other sites

В этой теме 

Привел решение для работы antizapret без костылей. У меня заработало на последней актуальной прошивке 2.15.C.3.0-2 

Приведу и тут, так как та тема без регистрации недоступна:

1. Поменял DNS на гугловские в настройках проводного подключения оператора своего. Но системном мониторе в "подробнее о соединении" они все равно светились в разделе DNS после гугловских. Пришлось применить через telnet:

(config)> interface ISP no ip dhcp client name-servers

system configuration save

2. В настройках соединения openvpn убрать галку "Использовать для выхода в Интернет" (получать марщруты... – установить), в конфигураторе прописал первой строкой pull-filter ignore "block-outside-dns"

3. В разделе Домашняя сеть в подразделе DHCP прописал DNS 192.168.104.1

4. В разделе Интернет-фильтр НИЧЕГО ДОБАВЛЯТЬ НЕ НУЖНО.

Edited by Макс Кинчев

Share this post


Link to post
Share on other sites

Ребята, такая ситуация.

Есть проводное интернет соединиение , резерв настрен на usb 4G.

Все прекрасно работает, пропадает основной проводной интернет, мгновенно переключается на 4G.

Суть вопроса, когда основной канал интернет работает, могу поднять openvpn соединение, а вот на резервном 4G нивкакую неподнимается.

 

Думал, может с 4G какая проблема, на компьютере без проблем, через 4G поднимается openvpn.

Что порекомендуете?

Share this post


Link to post
Share on other sites
22 минуты назад, yuoras сказал:

Думал, может с 4G какая проблема, на компьютере без проблем, через 4G поднимается openvpn.

Что порекомендуете?

Здесь посмотрите:

Цитата

1267293626__136.png.08582124abb874cc323aaa4ed972d924.png

 

Share this post


Link to post
Share on other sites

Спасибо.

Подключение стоит из любого канала по умолчанию

Скрытый текст

E] May  5 18:51:27 ndm: Service: "OpenVPN1": unexpectedly stopped.
May  5 18:51:30 OpenVPN1: OpenVPN 2.4.6 [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [AEAD]
May  5 18:51:30 OpenVPN1: library versions: OpenSSL 1.1.1b  26 Feb 2019, LZO 2.10
[W] May  5 18:51:30 OpenVPN1: ******* WARNING *******: '--cipher none' was specified. This means NO encryption will be performed and tunnelled data WILL be transmitted in clear text over the network! PLEASE DO RECONSIDER THIS SETTING!
May  5 18:51:30 OpenVPN1: UDP link local: (not bound)
May  5 18:51:30 OpenVPN1: UDP link remote: [AF_INET6]64:ff9b::505d:b6a1:1194
May  5 18:51:30 OpenVPN1: NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
[E] May  5 18:51:30 OpenVPN1: write UDP: Network is unreachable (code=128)
May  5 18:51:30 OpenVPN1: Network unreachable, restarting
May  5 18:51:30 OpenVPN1: SIGTERM[soft,network-unreachable] received, process exiting
[E] May  5 18:51:30 ndm: Service: "OpenVPN1": unexpectedly stopped.
May  5 18:51:33 OpenVPN1: OpenVPN 2.4.6 [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [AEAD]
May  5 18:51:33 OpenVPN1: library versions: OpenSSL 1.1.1b  26 Feb 2019, LZO 2.10
[W] May  5 18:51:33 OpenVPN1: ******* WARNING *******: '--cipher none' was specified. This means NO encryption will be performed and tunnelled data WILL be transmitted in clear text over the network! PLEASE DO RECONSIDER THIS SETTING!
May  5 18:51:33 OpenVPN1: UDP link local: (not bound)
May  5 18:51:33 OpenVPN1: UDP link remote: [AF_INET6]64:ff9b::505d:b6a1:1194
May  5 18:51:33 OpenVPN1: NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
[E] May  5 18:51:33 OpenVPN1: write UDP: Network is unreachable (code=128)
May  5 18:51:33 OpenVPN1: Network unreachable, restarting
May  5 18:51:33 OpenVPN1: SIGTERM[soft,network-unreachable] received, process exiting
[E] May  5 18:51:33 ndm: Service: "OpenVPN1": unexpectedly stopped.

 

И так в цикле.

Повторюсь , что при проводном соединении ,все отлично

Edited by yuoras
Дополнил

Share this post


Link to post
Share on other sites

Пробую подключиться к рабочему OpenVPN. Клиент windows цепляется нормально. Keenetic при том же файле конфига со встроенными ключами выдает:

Июл 4 09:56:36 OpenVPN0
OpenVPN 2.4.6 [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [AEAD]
Июл 4 09:56:36 OpenVPN0
library versions: OpenSSL 1.1.1c 28 May 2019, LZO 2.10
Июл 4 09:56:36 OpenVPN0
Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Июл 4 09:56:36 OpenVPN0
Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Июл 4 09:56:36 OpenVPN0
LZO compression initializing
Июл 4 09:56:36 OpenVPN0
Control Channel MTU parms [ L:1622 D:1184 EF:66 EB:0 ET:0 EL:3 ]
Июл 4 09:56:36 OpenVPN0
Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ]
Июл 4 09:56:36 OpenVPN0
Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-client'
Июл 4 09:56:36 OpenVPN0
Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 0,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-server'
Июл 4 09:56:36 OpenVPN0
Socket Buffers: R=[155648->155648] S=[155648->155648]
Июл 4 09:56:36 OpenVPN0
UDP link local: (not bound)
Июл 4 09:56:36 OpenVPN0
UDP link remote: [AF_INET]222.135.144.155:1195
Июл 4 09:56:36 OpenVPN0
NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Июл 4 09:57:36 OpenVPN0
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Июл 4 09:57:36 OpenVPN0
TLS Error: TLS handshake failed
Июл 4 09:57:36 OpenVPN0
TCP/UDP: Closing socket
Июл 4 09:57:36 OpenVPN0
SIGTERM[soft,tls-error] received, process exiting
Июл 4 09:57:36 ndm
Service: "OpenVPN0": unexpectedly stopped.

Конфиг

client
dev tun
proto udp
remote 222.135.144.155 1195
resolv-retry infinite
nobind
persist-key
persist-tun
cipher aes-256-cbc
auth sha1
tls-client
remote-cert-tls server
key-direction 1
comp-lzo
verb 5
<ca>
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
</key>
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
-----END OpenVPN Static key V1-----
</tls-auth>

Share this post


Link to post
Share on other sites

Настройки клиента:

client
proto udp
remote 51.75.68.52 1194
dev tun
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
verify-x509-name server_a1RwfzVq89LhNTnI name
auth SHA256
auth-nocache
cipher AES-128-GCM
tls-client
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
verb 3
<ca>
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----
</key>
<tls-crypt>
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
-----END OpenVPN Static key V1-----
</tls-crypt>

Нижнее измерение - клиент на ноутбуке, верхнее - клиент на KN-1910 3.1b1

1388442740_Screenshotfrom2019-07-1922-27-44.thumb.png.7d9cc5184423e12868e14cb9abce93bc.png

Вопрос: Почему такая низкая скорость на download у KN-1910? Это ок?

Share this post


Link to post
Share on other sites

Добрый день! 

Подскажите пожалуйста, провайдер дает доступ в интернет по кабелю, через L2TP соединение (PROV_L2TP - помечен галочкой использовать для выхода в интернет). Настроены два OpenVPN (1VPN и 2VPN  - оба помечены галочкой использовать для выхода в интернет) подключения на разные сервера. В приоритетах подключений, расположены по убыванию 1VPN, 2VPN, PROV_L2TP.

При пропадании доступа в интернет у 1VPN, не переходит автоматически на 2VPN или PROV_L2TP (просто остается подключенным к 1VPN). Ping Check в VPN1 и VPN2, опция недоступна.

Как настроить автоматическое переключение с 1VPN на 2VPN? А в случае недоступности 1VPN и 2VPN, переключаться на PROV_L2TP?


Конфигурация VPN 1 и VPN2

client
proto udp
remote XXX.XXX.XXX.XXX 1194
dev tun
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
verify-x509-name server_gowW2aMP6RyAnNnt name
auth SHA256
auth-nocache
cipher AES-128-CBC
tls-client
tls-version-min 1.2
tls-cipher TLS-DHE-RSA-WITH-AES-128-GCM-SHA256
verb 3

(далее данные ключей)

 

Edited by test tesko

Share this post


Link to post
Share on other sites

Перестал работать OpenVPN на роутере KN-1310. Обновился до последней прошивки.

В логе такая ошибка:


Сен 3 15:18:54 OpenVPN1
Cipher BF-CBC not supported
Сен 3 15:18:54 OpenVPN1
Exiting due to fatal error
Сен 3 15:18:54 ndm
Service: "OpenVPN1": unexpectedly stopped.

Что делать?

 

Edited by Byuri

Share this post


Link to post
Share on other sites
1 час назад, Byuri сказал:

Перестал работать OpenVPN на роутере KN-1310. Обновился до последней прошивки.

В логе такая ошибка:


Сен 3 15:18:54 OpenVPN1
Cipher BF-CBC not supported
Сен 3 15:18:54 OpenVPN1
Exiting due to fatal error
Сен 3 15:18:54 ndm
Service: "OpenVPN1": unexpectedly stopped.

Что делать?

 

Ну вот и настал конец лайтовому протоколу шифрования. :( у меня вся сеть на нём, походу надо готовиться к переходу на новый более ресурсоёмкий шифр. :(

Share this post


Link to post
Share on other sites
6 часов назад, dvg_lab сказал:

Ну вот и настал конец лайтовому протоколу шифрования. :( у меня вся сеть на нём, походу надо готовиться к переходу на новый более ресурсоёмкий шифр. :(

Это очень странно.

Пожалуйста, обратитесь в официальную поддержку.

BF-CBC на 1310 точно должен работать.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...