OpenVPN - неправильный роутинг на клиентах.

Bansher

Всем доброго времени.
Имеем следующие грабли. При подключении OpenVPN, на клиенте отваливается интернет. Смотрим route print клиента, видим две конкурирующие строчки:

Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
          0.0.0.0          0.0.0.0      192.168.1.1     192.168.1.34     10
          0.0.0.0        128.0.0.0         10.8.0.5         10.8.0.6     30

При этом не смотря на метрики, "интернетный" трафик все равно пытается идти через локальный роутер в удаленной сети.
Открываем консоль на клиентском компе и прибиваем неправильный маршрут:

route delete 0.0.0.0 mask 128.0.0.0 10.8.0.5

Появляется интернет, локалка через vpn работает, веселится и ликует весь народ.
Вопрос: Чего подкрутить в настройках OpenVPN сервера (или клиента), чтобы паразитный роутинг на клиентах не поднимался?
Сейчас в Advanced configuration сервера прописаны только:
push "route 10.8.0.0 255.255.255.0";
push "route 192.168.20.0 255.255.255.0";
push "route 192.168.0.0 255.255.255.0";

werter

Схему сети нарисуйте с адресами. У вас клиент получает адрес (и маршруты) внутри своей локалки автоматом? Нет ли явно заданных маршрутов у клиентов?

Вот еще :

http://www.opennet.ru/openforum/vsluhforumID1/90883.html
http://www.linux.org.ru/forum/admin/9444282

P.s. Какой тип подключения исп-ся - Peer to Peer или Remote Access? Не установлено ли в настройках сервера\клиента указание, что OpenVPN является дефолтным шлюз, т.е. весь внешний трафик "гнать" через него ?

P.p.s. Покажите лог клиента при установление сессии . Желательно, чтобы у клиента была в конфиге директива verb 3 (как минимум).

Если все же проблема не решается с помощью настроек Опенвпн - можно создать bat-файл типа :

1-ая строка - установка Опенвпн-cессии (пример - http://www.personalvpn.org/auto_login_openvpn.htm)
2-ая - пауза в 3 сек - ping -n 3 127.0.0.1
3-ая - удаление неправильного маршрута
4-ая - (для верности) вновь пауза в 3 сек - ping -n 3 127.0.0.1

Сам батник разместить в подпапке bin каталога OpenVPN и вывести ярлык на раб. стол.

Bansher

Клиенты с OpenVPN сидят в разных точках города, на разных провайдерах. Через VPN получают доступ в локальную сеть. Явно заданных маршрутов нет. Ситуацию легко моделирую на свободном ноутбуке. Ставлю OpenVPN клиент, в инет подключаюсь через модем. Запускаю VPN соединение. Все. Локальная сеть есть, интернета нет. Убиваю два маршрута: 0.0.0.0 mask 128.0.0.0 и 128.0.0.0 mask 128.0.0.0 - все работает и локальная сеть и интернет.
Лог подключения клиента:

Tue Dec 24 17:06:38 2013 OpenVPN 2.3.2 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [eurephia] [IPv6] built on Aug 22 2013
Enter Management Password:
Tue Dec 24 17:06:48 2013 Control Channel Authentication: using 'vpn-TCP-1194-tls.key' as a OpenVPN static key file
Tue Dec 24 17:06:48 2013 Attempting to establish TCP connection with [AF_INET]46.16.176.179:1194
Tue Dec 24 17:06:48 2013 TCP connection established with [AF_INET]46.16.176.179:1194
Tue Dec 24 17:06:48 2013 TCPv4_CLIENT link local: [undef]
Tue Dec 24 17:06:48 2013 TCPv4_CLIENT link remote: [AF_INET]46.16.XXX.XXX:1194
Tue Dec 24 17:06:48 2013 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Tue Dec 24 17:06:51 2013 [VpnServerCert] Peer Connection Initiated with [AF_INET]46.16.XXX.XXX:1194
Tue Dec 24 17:06:53 2013 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Tue Dec 24 17:06:53 2013 open_tun, tt->ipv6=0
Tue Dec 24 17:06:53 2013 TAP-WIN32 device [Подключение по локальной сети 2] opened: \\.\Global\{AF28CF1F-0BF5-4F04-9D3C-BD1A5D51CF30}.tap
Tue Dec 24 17:06:53 2013 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.34/255.255.255.252 on interface {AF28CF1F-0BF5-4F04-9D3C-BD1A5D51CF30} [DHCP-serv: 10.8.0.33, lease-time: 31536000]
Tue Dec 24 17:06:53 2013 Successful ARP Flush on interface [22] {AF28CF1F-0BF5-4F04-9D3C-BD1A5D51CF30}
Tue Dec 24 17:06:59 2013 ROUTE: route addition failed using CreateIpForwardEntry: Этот объект уже существует.   [status=5010 if_index=22]
Tue Dec 24 17:06:59 2013 env_block: add PATH=C:\Windows\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Tue Dec 24 17:06:59 2013 ROUTE: route addition failed using CreateIpForwardEntry: Этот объект уже существует.   [status=5010 if_index=22]
Tue Dec 24 17:06:59 2013 env_block: add PATH=C:\Windows\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Tue Dec 24 17:06:59 2013 Initialization Sequence Completed

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

dev tun
persist-tun
persist-key
proto tcp-client
cipher BF-CBC
tls-client
client
resolv-retry infinite
remote vpn.address.url 1194
tls-remote VpnServerCert
auth-user-pass
pkcs12 vpn-TCP-1194.p12
tls-auth vpn-TCP-1194-tls.key 1
comp-lzo

Ссылки которые вы прислали описывают мою ситуацию но конкретного решения не имеют. Странно, я думал что проблема банальная и имеет примитивное решение.
Вариант с батником в данный момент привлекательно выглядит :)

werter

А вас не смущает эта строка ?

ROUTE: route addition failed using CreateIpForwardEntry: Этот объект уже существует. [status=5010 if_index=22]

И зачем вы используете tcp вместо udp ? У вас клиенты через прокси выходят?

Попробуйте добавить след. строки в конфиг клиента :

route-delay 5
route-method exe
ip-win32 netsh
pull
verb 3

И пускай клиент запускает подключение от имени Администратора - т.е. правой кнопкой мыши на Опенвпн - Запустить от имени Администратора.

Плюс, само ПО OpenVPN нужно было тоже устанавливать от имени Администратора - т.е. правой кнопкой мыши на инсталляционном пакете Опенвпн - Запустить от имени Администратора. Июо есть ньюансы.

helper

Наверное в конфиге опенвн сервера стоит такое:

# If enabled, this directive will configure
# all clients to redirect their default
# network gateway through the VPN, causing
# all IP traffic such as web browsing and
# and DNS lookups to go through the VPN
# (The OpenVPN server machine may need to NAT
# or bridge the TUN/TAP interface to the internet
# in order for this to work properly).
push "redirect-gateway def1 bypass-dhcp"

По дефолту оно закомментировано, вы скорее всего раскомментировали.

Эта директива заставляет клиентов прописывать дефолтным маршрутизатором ВПН сервер и весь трафик от клиентов после этого заруливается на туннель. В этом есть необходимость, если вам нужно выходить в интернет через туннель (допустим порты закрыты и вы пробрасываете туннель через определенный порт, например так китайцы обходят свой "великий файрвол"), либо хотите спрятаться за иным айпишником.

helper

@werter:

И зачем вы используете tcp вместо udp ? У вас клиенты через прокси выходят?

Потенциально это без разницы, через UDP может быть быстрее, через TCP надежнее.
На моей практике было такое, что через UDP не всегда шло, например резались стандартные MTU 1500 (когда случается Path MTU Discovery Black Hole) при этом это происходило только с UDP пакетами, конечно в openvpn есть настройки, которые позволяют зарезать значение MTU, но все же хотелось лишний раз это не трогать…

werter

2 helper

На дату гляньте, ага.

helper

@werter:

2 helper

На дату гляньте, ага.

А в чем проблема с датой? Он из будущего? :)))

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

werter

Тогда работы вам здесь - непочатый край.

P.s. Пишите лучше в личку.

defen2204

Здравствуйте, а Вы не могли бы и мне помочь с openvpn? Дело в том, что внутри локалки все коннектится на ура, а вот если стучу с внешки, все тормозится на хэндшейке и соединение обрывается по таймауту….

настройка сервера:

local 192.168.88.10
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist
client-config-dir ccd
push "route 192.168.88.10 255.255.255.0
push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"
client-to-client
keepalive 10 120
tls-server
auth SHA512
tls-auth ta.key 0
cipher BF-CBC
comp-lzo adaptive
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3
mute

Клиента:

client
dev tun
proto udp
remote ххх.ххх.ххх.ххх 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca caR.crt
cert clientR.crt
key clientR.key
tls-auth taR.key 1
auth SHA512
cipher BF-CBC
comp-lzo adaptive
log openvpn.log
status openvpn-status.log
verb 3
mute 20
route 10.8.0.0 255.255.0.0

defen2204

Сервер работает на "малинеке" на микротике порты проброшены….

defen2204

вот как-то так

werter

Доброе.

Сервер.

push "route 192.168.88.10 255.255.255.0

Только один адрес ? Может должно быть так - 192.168.88.0 255.255.255.0?

push "redirect-gateway def1"

Зачем весь трафик заворачиваете в впн ? Откл. это.

Клиент.

route 10.8.0.0 255.255.0.0

Удалите эту строчку вообще

defen2204

к сожалению ситуация та же(((

defen2204

Логи клиента:
2016-02-09 13:12:49 VERIFY OK: depth=0
cert. version : 3
serial number : 01
issuer name : C=US, ST=CA, L=SanFrancisco, O=Fort-Funston, OU=changeme, CN=changeme, ??=changeme, emailAddress=mail@host.domain
subject name : C=US, ST=CA, L=SanFrancisco, O=Fort-Funston, OU=changeme, CN=server, ??=changeme, emailAddress=mail@host.domain
issued on : 2016-01-22 01:42:02
expires on : 2026-01-19 01:42:02
signed using : RSA with SHA1
RSA key size : 1024 bits
basic constraints : CA=false
cert. type : SSL Server
key usage : Digital Signature, Key Encipherment
ext key usage : TLS Web Server Authentication

2016-02-09 13:13:01 EVENT: CONNECTION_TIMEOUT [ERR]
2016-02-09 13:13:01 EVENT: DISCONNECTED
2016-02-09 13:13:01 Raw stats on disconnect:
BYTES_IN : 11056
BYTES_OUT : 48218
PACKETS_IN : 64
PACKETS_OUT : 93
KEEPALIVE_TIMEOUT : 1
CONNECTION_TIMEOUT : 1
N_RECONNECT : 1
PKTID_UDP_REPLAY_WINDOW_BACKTRACK : 1
2016-02-09 13:13:01 Performance stats on disconnect:
CPU usage (microseconds): 140954
Network bytes per CPU second: 420520
Tunnel bytes per CPU second: 0
2016-02-09 13:13:01 EVENT: DISCONNECT_PENDING
2016-02-09 13:13:01 –--- OpenVPN Stop -----

werter

2 defen2204

Четкое ТЗ. И схему.

helper

@defen2204:

Здравствуйте, а Вы не могли бы и мне помочь с openvpn? Дело в том, что внутри локалки все коннектится на ура, а вот если стучу с внешки, все тормозится на хэндшейке и соединение обрывается по таймауту….

настройка сервера:

local 192.168.88.10
…
ca ca.crt
…

Клиента:

ca caR.crt
…

Что смущает, вы задали слушать локальный адрес, на компе есть еще интерфейсы, на которых надо слушать? если да, то закомментируйте эту директиву local.
Второе, что смущает, разные названия сертификатов, это вы переименовали? Если нет, то похоже, что вы генерили сертификаты клиента и сервера через разные корневые сертификаты.

defen2204

1. Не совсем понял что Вы имеете ввиду говоря о ТЗ и схеме, поэтому расскажу что вообще настроено у меня в сети. Малинка, на которой поднята самба, видеонаблюдение, принтсервер и впн подключена к роутеру микротик. Необходимо, чтобы она через впн пропускала весь трафик от клиента к серверу, включая интернет. На другом стационарном компе в сети крутится фтп (под виндой). На роутере проброшены порты для фтп, ssh, rdp (для малинки) и проброс для DC клиентов на 2х компах. Вроде ни чего не забыл…
2. Имена сертификатов менял сам, т.к. Создавал несколько клиентов для разных серверов

defen2204

Вот что наконец выплюнул сервак:
Wed Feb 10 00:46:44 2016 MULTI: multi_create_instance called
Wed Feb 10 00:46:44 2016 192.168.88.1:26695 Re-using SSL/TLS context
Wed Feb 10 00:46:44 2016 192.168.88.1:26695 LZO compression initialized
Wed Feb 10 00:46:44 2016 192.168.88.1:26695 Control Channel MTU parms[ L:1586 D:210 EF:110 EB:0 ET:0 EL:0 ]
Wed Feb 10 00:46:44 2016 192.168.88.1:26695 Data Channel MTU parms [
L:1586 D:1450 EF:86 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Feb 10 00:46:44 2016 192.168.88.1:26695 Local Options hash
(VER=V4): '5134803b'
Wed Feb 10 00:46:44 2016 192.168.88.1:26695 Expected Remote Options
hash (VER=V4): 'e66044bc'
Wed Feb 10 00:46:44 2016 192.168.88.1:26695 TLS: Initial packet from
[AF_INET]192.168.88.1:26695, sid=7a40b1ff 3b92eccb
Wed Feb 10 00:46:44 2016 192.168.88.1:26695 Replay-window backtrack occurred [1]
Wed Feb 10 00:47:31 2016 MULTI: multi_create_instance called
Wed Feb 10 00:47:31 2016 192.168.88.1:9564 Re-using SSL/TLS context
Wed Feb 10 00:47:31 2016 192.168.88.1:9564 LZO compression initialized
Wed Feb 10 00:47:31 2016 192.168.88.1:9564 Control Channel MTU parms [
L:1586 D:210 EF:110 EB:0 ET:0 EL:0 ]
Wed Feb 10 00:47:31 2016 192.168.88.1:9564 Data Channel MTU parms [
L:1586 D:1450 EF:86 EB:135 ET:0 EL:0 AF:3/1 ]
Wed Feb 10 00:47:31 2016 192.168.88.1:9564 Local Options hash
(VER=V4): '5134803b'
Wed Feb 10 00:47:31 2016 192.168.88.1:9564 Expected Remote Options
hash (VER=V4): 'e66044bc'
Wed Feb 10 00:47:31 2016 192.168.88.1:9564 TLS: Initial packet from
[AF_INET]192.168.88.1:9564, sid=8e73bebb 8b3794d1
Wed Feb 10 00:47:44 2016 192.168.88.1:26695 TLS Error: TLS key
negotiation failed to occur within 60 seconds (check your network
connectivity)
Wed Feb 10 00:47:44 2016 192.168.88.1:26695 TLS Error: TLS handshake failed
Wed Feb 10 00:47:44 2016 192.168.88.1:26695 SIGUSR1[soft,tls-error] received, client-instance restarting
Wed Feb 10 00:48:31 2016 192.168.88.1:9564 TLS Error: TLS key
negotiation failed to occur within 60 seconds (check your network
connectivity)
Wed Feb 10 00:48:31 2016 192.168.88.1:9564 TLS Error: TLS handshake failed
Wed Feb 10 00:48:31 2016 192.168.88.1:9564 SIGUSR1[soft,tls-error]
received, client-instance restarting

OpenVPN CLIENT LIST
Updated,Wed Feb 10 00:57:02 2016
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
GLOBAL STATS
Max bcast/mcast queue length,0
END

werter

2 defen2204

1. Не совсем понял что Вы имеете ввиду говоря о ТЗ и схеме, поэтому расскажу что вообще настроено у меня в сети. Малинка, на которой поднята самба, видеонаблюдение, принтсервер и впн подключена к роутеру микротик. Необходимо, чтобы она через впн пропускала весь трафик от клиента к серверу, включая интернет. На другом стационарном компе в сети крутится фтп (под виндой). На роутере проброшены порты для фтп, ssh, rdp (для малинки) и проброс для DC клиентов на 2х компах. Вроде ни чего не забыл…

Мил человек, я не увидел в этой схеме pfsense.