LINUX.ORG.RU
ФорумAdmin

не работает маршрутизация через OpenVPN

 , ,


0

1

Схема:

LAN1: 192.168.21.0/24 LAN2: 10.77.77.0/24

OpenVPN сервер: eth0:10.77.77.11, tun1:10.10.30.1 OpenVPN клиент: eth0:192.168.21.30, tun1:10.10.30.25

VPN сеть: 10.10.30.0/24

Конфиг сервера:

local 10.77.77.11
port 1194
proto udp
dev tun1
tun-mtu 1500
ca /etc/openvpn/.key/ca.crt
cert /etc/openvpn/.key/server.crt
key /etc/openvpn/.key/server.key
dh /etc/openvpn/.key/dh2048.pem
server 10.10.30.0 255.255.255.0
daemon
mode server
tls-server
ifconfig-pool-persist /etc/openvpn/ip.sv
client-to-client
push "route 10.77.77.0 255.255.255.0"
client-config-dir ccd
keepalive 10 120
tls-auth /etc/openvpn/.tls/ta.key 0
cipher AES-256-CBC
auth SHA512
comp-lzo
max-clients 20
user openvpn
group openvpn
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log-append /var/log/openvpn/openvpn.log
verb 8
mute 20

Конфиг клиента:

client
tls-client
dev tun1
proto udp
remote 10.77.77.11 1194
route-delay 2
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
dh dh2048.pem
cert gws_client.crt
key gws_client.key
key-direction 1
tls-auth ta.key
tun-mtu 1500
tun-mtu-extra 32
cipher AES-256-CBC
auth SHA512
comp-lzo
verb 4
mute 20
log-append openvpn_client.log
status status_client.log

Логи клиент при подключении:

Tue Mar  4 21:53:53 2014 us=409683 Current Parameter Settings:
Tue Mar  4 21:53:53 2014 us=409854   config = 'gws_client.ovpn'
Tue Mar  4 21:53:53 2014 us=409893   mode = 0
Tue Mar  4 21:53:53 2014 us=409926   persist_config = DISABLED
Tue Mar  4 21:53:53 2014 us=409973   persist_mode = 1
Tue Mar  4 21:53:53 2014 us=410012   show_ciphers = DISABLED
Tue Mar  4 21:53:53 2014 us=410045   show_digests = DISABLED
Tue Mar  4 21:53:53 2014 us=410077   show_engines = DISABLED
Tue Mar  4 21:53:53 2014 us=410109   genkey = DISABLED
Tue Mar  4 21:53:53 2014 us=410170   key_pass_file = '[UNDEF]'
Tue Mar  4 21:53:53 2014 us=410202   show_tls_ciphers = DISABLED
Tue Mar  4 21:53:53 2014 us=410232 Connection profiles [default]:
Tue Mar  4 21:53:53 2014 us=410261   proto = udp
Tue Mar  4 21:53:53 2014 us=410292   local = '[UNDEF]'
Tue Mar  4 21:53:53 2014 us=410322   local_port = 0
Tue Mar  4 21:53:53 2014 us=410352   remote = '192.168.21.5'
Tue Mar  4 21:53:53 2014 us=410381   remote_port = 1194
Tue Mar  4 21:53:53 2014 us=410411   remote_float = DISABLED
Tue Mar  4 21:53:53 2014 us=410440   bind_defined = DISABLED
Tue Mar  4 21:53:53 2014 us=410471   bind_local = DISABLED
Tue Mar  4 21:53:53 2014 us=410500 NOTE: --mute triggered...
Tue Mar  4 21:53:53 2014 us=410548 255 variation(s) on previous 20 message(s) suppressed by --mute
Tue Mar  4 21:53:53 2014 us=410586 OpenVPN 2.3.2 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Sep 12 2013
Tue Mar  4 21:53:53 2014 us=410741 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Tue Mar  4 21:53:53 2014 us=412265 WARNING: file 'ta.key' is group or others accessible
Tue Mar  4 21:53:53 2014 us=412319 Control Channel Authentication: using 'ta.key' as a OpenVPN static key file
Tue Mar  4 21:53:53 2014 us=412369 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Tue Mar  4 21:53:53 2014 us=412410 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Tue Mar  4 21:53:53 2014 us=412471 LZO compression initialized
Tue Mar  4 21:53:53 2014 us=412653 Control Channel MTU parms [ L:1634 D:210 EF:110 EB:0 ET:0 EL:0 ]
Tue Mar  4 21:53:53 2014 us=412750 Socket Buffers: R=[124928->131072] S=[124928->131072]
Tue Mar  4 21:53:53 2014 us=412880 Data Channel MTU parms [ L:1634 D:1450 EF:102 EB:135 ET:32 EL:0 AF:3/1 ]
Tue Mar  4 21:53:53 2014 us=412945 Local Options String: 'V4,dev-type tun,link-mtu 1634,tun-mtu 1532,proto UDPv4,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA512,keysize 256,tls-auth,key-method 2,tls-client'
Tue Mar  4 21:53:53 2014 us=413021 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1634,tun-mtu 1532,proto UDPv4,comp-lzo,keydir 0,cipher AES-256-CBC,auth SHA512,keysize 256,tls-auth,key-method 2,tls-server'
Tue Mar  4 21:53:53 2014 us=413112 Local Options hash (VER=V4): '6a152ec4'
Tue Mar  4 21:53:53 2014 us=413196 Expected Remote Options hash (VER=V4): 'e1f65e10'
Tue Mar  4 21:53:53 2014 us=413263 UDPv4 link local: [undef]
Tue Mar  4 21:53:53 2014 us=413324 UDPv4 link remote: [AF_INET]192.168.21.5:1194
Tue Mar  4 21:53:53 2014 us=416596 TLS: Initial packet from [AF_INET]192.168.21.5:1194, sid=d5f55581 fd4793fb
Tue Mar  4 21:53:53 2014 us=464101 VERIFY OK: depth=1, C=KG, ST=BI, L=Bishkek, O=7777, OU=changeme, CN=gws.7777.kg, name=changeme, emailAddress=it@7777.kg
Tue Mar  4 21:53:53 2014 us=464694 VERIFY OK: depth=0, C=KG, ST=BI, L=Bishkek, O=7777, OU=changeme, CN=server, name=changeme, emailAddress=it@7777.kg
Tue Mar  4 21:53:53 2014 us=563650 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1634', remote='link-mtu 1602'
Tue Mar  4 21:53:53 2014 us=563728 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1532', remote='tun-mtu 1500'
Tue Mar  4 21:53:53 2014 us=564111 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Tue Mar  4 21:53:53 2014 us=564161 Data Channel Encrypt: Using 512 bit message hash 'SHA512' for HMAC authentication
Tue Mar  4 21:53:53 2014 us=564196 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Tue Mar  4 21:53:53 2014 us=564234 Data Channel Decrypt: Using 512 bit message hash 'SHA512' for HMAC authentication
Tue Mar  4 21:53:53 2014 us=564322 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Tue Mar  4 21:53:53 2014 us=564410 [server] Peer Connection Initiated with [AF_INET]192.168.21.5:1194
Tue Mar  4 21:53:55 2014 us=917096 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Tue Mar  4 21:53:55 2014 us=919811 PUSH: Received control message: 'PUSH_REPLY,route 10.10.30.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.10.30.25 10.10.30.26'
Tue Mar  4 21:53:55 2014 us=919911 OPTIONS IMPORT: timers and/or timeouts modified
Tue Mar  4 21:53:55 2014 us=919941 OPTIONS IMPORT: --ifconfig/up options modified
Tue Mar  4 21:53:55 2014 us=919962 OPTIONS IMPORT: route options modified
Tue Mar  4 21:53:55 2014 us=920285 ROUTE_GATEWAY 192.168.21.3/255.255.255.0 IFACE=eth0 HWADDR=f0:bf:97:1b:a1:ee
Tue Mar  4 21:53:55 2014 us=920650 TUN/TAP device tun1 opened
Tue Mar  4 21:53:55 2014 us=920691 TUN/TAP TX queue length set to 100
Tue Mar  4 21:53:55 2014 us=920722 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Tue Mar  4 21:53:55 2014 us=920760 /sbin/ip link set dev tun1 up mtu 1500
Tue Mar  4 21:53:55 2014 us=923460 /sbin/ip addr add dev tun1 local 10.10.30.25 peer 10.10.30.26
Tue Mar  4 21:53:58 2014 us=103012 /sbin/ip route add 10.10.30.0/24 via 10.10.30.26
Tue Mar  4 21:53:58 2014 us=104524 Initialization Sequence Completed

Таблица маршрутизации после подключения:

# ip route
10.10.30.26 dev tun1  proto kernel  scope link  src 10.10.30.25
10.10.25.2 dev tun0  proto kernel  scope link  src 10.10.25.1
192.168.21.0/24 via 192.168.21.3 dev eth0
10.10.30.0/24 via 10.10.30.26 dev tun1
10.10.25.0/24 via 10.10.25.2 dev tun0
169.254.0.0/16 dev eth0  scope link  metric 1002
default via 192.168.21.3 dev eth0
как видно в таблице нет сети 10.77.77.0/24

Добавил маршрут вручную:

# ip route add 10.77.77.0/24 via 10.10.30.26

В итоге получилась следующая таблица маршрутов:

# ip route
10.10.30.26 dev tun1  proto kernel  scope link  src 10.10.30.25
10.10.25.2 dev tun0  proto kernel  scope link  src 10.10.25.1
10.77.77.0/24 via 10.10.30.26 dev tun1
192.168.21.0/24 via 192.168.21.3 dev eth0
10.10.30.0/24 via 10.10.30.26 dev tun1
10.10.25.0/24 via 10.10.25.2 dev tun0
169.254.0.0/16 dev eth0  scope link  metric 1002
default via 192.168.21.3 dev eth0

При попытке пинга хостов в сети 10.77.77.0/24 пинги не проходят.

Пример:

# ping 10.77.77.11
PING 10.77.77.11 (10.77.77.11) 56(84) bytes of data.

На сервере OpenVPN я не вижу ICMP пакетов:

# tcpdump -i tun1 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun1, link-type RAW (Raw IP), capture size 65535 bytes

Так же отключал iptables - безрезультатно.

Подскажите куда еще можно посмотреть чтобы решить проблему.

Спасибо!

А 10.77.77.11 знает куда посылать пакеты к 192.168.21.30 10.10.30.25 ? «ip ro» на 10.77.77.11 хорошо бы посмотреть.

Лучше «tcpdump -ni tun1». Нерабочий dns мешает tcpdump-у.

На клиенте «ip ro get 10.77.77.11» скажет куда будут посланы пакеты, если там их не дропнет iptables.

Да и на сервере было бы интересно посмотреть «ip ro get 10.10.30.25» и «ip ro get 192.168.21.30» Заодно проверить iptables...

vel ★★★★★ ()
Ответ на: комментарий от zgen

да забыл написать что на сервере есть папка ccd c именем сертификата.

Содержимое файла /etc/openvpn/ccd/gws_client

ifconfig-push 10.10.30.25 10.10.30.26
iroute 10.77.77.0 255.255.255.0

при подключении клиента - получаю IP: 10.10.30.25

по поводу iroute - не знаю получает ли он этот параметр

Ilianapro ()
Ответ на: комментарий от vel

Инфа c сервера:

# ip ro
10.10.30.2 dev tun1  proto kernel  scope link  src 10.10.30.1
10.77.77.0/24 dev eth0  proto kernel  scope link  src 10.77.77.11
10.10.30.0/24 via 10.10.30.2 dev tun1
10.10.25.0/24 via 10.77.77.11 dev eth0
169.254.0.0/16 dev eth0  scope link  metric 1002
default via 10.77.77.1 dev eth0
# ip ro get 10.10.30.25
10.10.30.25 via 10.10.30.2 dev tun1  src 10.10.30.1
    cache  mtu 1500 advmss 1460 hoplimit 64
# ip ro get 192.168.21.30
192.168.21.30 via 10.77.77.1 dev eth0  src 10.77.77.11
    cache  mtu 1500 advmss 1460 hoplimit 64

пинги с сервера до 10.10.30.25 ходят, а на 192.168.21.30 нет :(

Инфа с клиента:

# ip ro get 10.77.77.11
10.77.77.11 via 10.10.30.26 dev tun1  src 10.10.30.25
    cache  mtu 1500 advmss 1460 hoplimit 64

при попытке пинга с клиента:

# ping 10.77.77.11
PING 10.77.77.11 (10.77.77.11) 56(84) bytes of data.
пинги не идут

tcpdump с сервера во время пинга:

# tcpdump -ni tun1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun1, link-type RAW (Raw IP), capture size 65535 bytes

iptables с сервера:

# iptables -nvL
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
   29  3248 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0
  113 23165 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:1194
  255 19500 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  tun1   eth0    0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 179 packets, 28245 bytes)
 pkts bytes target     prot opt in     out     source               destination



# iptables -nvL -t nat
Chain PREROUTING (policy ACCEPT 2 packets, 317 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 1 packets, 84 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 1 packets, 84 bytes)
 pkts bytes target     prot opt in     out     source               destination

Ilianapro ()
Ответ на: комментарий от vxzvxz

как писать маршруты в конфиге? и в каком конфиге писать маршруты? на сервере или в клиентской конфиге?

Вроде у меня маршрут прописан в конфиге на сервере: /etc/openvpn/server.conf :

push "route 10.77.77.0 255.255.255.0"

достаточно ли этой строки для маршрута?

Ilianapro ()
Ответ на: комментарий от Ilianapro

странно... при подключении клиента к серверу - клиент не получает параметр маршрута:

push "route 10.77.77.0 255.255.255.0"

после подключения к OpenVPN - таблица маршрутов у меня следующая:

# ip ro
10.10.30.26 dev tun1  proto kernel  scope link  src 10.10.30.25
10.10.25.2 dev tun0  proto kernel  scope link  src 10.10.25.1
192.168.21.0/24 via 192.168.21.3 dev eth0
10.10.30.0/24 via 10.10.30.26 dev tun1
10.10.25.0/24 via 10.10.25.2 dev tun0
169.254.0.0/16 dev eth0  scope link  metric 1002
default via 192.168.21.3 dev eth0

При попытке получить маршрут до 10.77.77.11: получаю следующее:

# ip ro get 10.77.77.11
10.77.77.11 via 192.168.21.3 dev eth0  src 192.168.21.30
    cache  mtu 1500 advmss 1460 hoplimit 64
т.е. пакеты уходят шлюзу по умолчанию.

Для временного решения я использовал ранее ручное добавление маршрута:

# ip ro add 10.77.77.0/24 via 10.10.30.26
все равно пинги не шли. но теперь видно что маршрут теперь идет в правильном направлении:
# ip ro get 10.77.77.11
10.77.77.11 via 10.10.30.26 dev tun1  src 10.10.30.25
    cache  mtu 1500 advmss 1460 hoplimit 64

В чем трабла? Почему tcpdump'ом на сервере не видны пакеты от клиента? Почему клиент не полчает параметр push route 10.77.77.0?

Ilianapro ()
Ответ на: комментарий от Ilianapro

пинги с сервера до 10.10.30.25 ходят, а на 192.168.21.30 нет :(

192.168.21.30 это адрес клиента в его локалке ? До него они не должны ходить через туннель, иначе туннель сломается.

Сервер не знает, что 192.168.21.0/24 доступен через тунель.

vel ★★★★★ ()
Ответ на: комментарий от Ilianapro

Спасибо zgen ваш коммент помог решить проблему.

В своем конфиге я указывал неправильные параметры:

iroute 10.77.77.0 255.255.255.0

а надо было использовать:

iroute 192.168.21.0 255.255.255.0

как быть с теми клиентами, для которых нет конфига в папке ccd ? надо ли им iroute ?

в чем принципиальная разница между iroute и route ?

где можно использовать iroute и route ?

Ilianapro ()

Недавно разбирали: OSPF в Quagga на несколько сетей
Там про Кваггу, но поверх OpenVPN как раз.

Вот тут упоминается ключевой момент - внутренний мультиплексор, которой системе не известен.

AS ★★★★★ ()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от vel

vel тебе спасибо. в твоих комментах я нашел новые команды, которые помогают отлаживать проблемы с маршрутами.

vel моя проблема решилась с использованием iroute в папке ccd на сервере.

===================== 192.168.21.30 это адрес клиента в его локалке ? До него они не должны ходить через туннель, иначе туннель сломается. =====================

у меня туннель не сломался :) какого рода поломки ты имел ввиду?

Ilianapro ()
Ответ на: комментарий от Ilianapro

на счет openvpn - ничего не могу подсказать - никогда с ним не работал. На клиенте смущает

192.168.21.0/24 via 192.168.21.3 dev eth0
default via 192.168.21.3 dev eth0
ты сам для себя шлюз по-умолчанию? Это работает в некоторых конфигурациях, но обычно это признак кривой конфигурации сети. или это опечатка ? м.б 192.168.21.5 как в логах ?

Когда создается туннель, есть только одна скрытая проблема - маршрут пакетов самого туннеля не должен меняться после его установки. т.е. если адреса туннеля 10.77.77.11 - 192.168.21.5 и с обоих сторон маршруты в эти адреса не должны попасть в сам туннель.

Правильные vpn обычно добавляют в таблицы машрутизации соответствующие записи ( на сервере должна быть строка «192.168.21.5 via 10.77.77.1 dev eth0» а на клиенте «10.77.77.11 via 192.168.21.3 dev eth0»). Без этих маршрутов добавление машрута на клиенте «10.77.77.0/24 dev tun1» через некоторое время убъет сам туннель, как и добавление маршрута «192.168.21.0/24 dev tun0» на сервере срубит сам туннель.

vel ★★★★★ ()
Ответ на: комментарий от vel

ты сам для себя шлюз по-умолчанию? Это работает в некоторых конфигурациях, но обычно это признак кривой конфигурации сети. или это опечатка ? м.б 192.168.21.5 как в логах ?

ранее я описывал какую-то часть сети. для того чтобы было ясно опишу более детальную схему сети.

в офисе имеется некоторое оборудование, которое планируется переместить в другое место. Для эмулирования подобной схемы я использовал Cisco switch и разделил порты на два VLAN

в одной VLAN у меня находится оборудования которое планируется перенести а в другой VLAN у меня офисное оборудование. Эти две сети объединяют Cisco Router с двумя интерфейсами:

FastEthernet0/0: 10.77.77.1 (LAN) FastEthernet0/1: 192.168.21.5 (WAN)

Как только оборудование переместится в другое место IP 192.168.21.5 (WAN) будет сменен на белый.

Все хосты из сети 10.77.77.0/24 используют шлюз по умолчанию 10.77.77.1

На Cisco роутере я пробросил udp порт 1194 WAN->LAN(10.77.77.11) для поднятия OpenVPN туннеля, для того чтобы из офиса иметь доступ к компьютерам сети 10.77.77.0/24

В офисной сети имеется хост 192.168.21.30 который является клиентом и сервером.

Ilianapro ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.