LINUX.ORG.RU
Форум — Admin  

OpenVPN маршрутизация


0

2

С прошедшими и наступающими праздниками! Поднял старую проблему, которую поднимал на нескольких форумах, которую не решил и отложил на свободное время. И оно настало.

Есть несколько сетей, объедененных OpenVPN. В каждой сети местный сервер с OV для компьютеров является шлюзом по умолчанию .Пришло время менять основной сервер. На него накатил Alt 6 Centarius (так сложилось исторически что множество лет пользуюсь везде альтом). На новом сервере все сервисы поднялись и заработали без проблем проблема только с сервером OV. Он упорно не видит сети за клиентскими шлюзами. При этом заметил, что не отрабатывает команда route из конфига сервера. Ниже конфиги и логи (коих много, извините) и комментарии.

server.conf 

port 1194
proto udp
dev-type tap
dev tap01
#dev-type tun

ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key  
dh /etc/openvpn/keys/dh1024.pem

server 10.10.200.0 255.255.255.0

ifconfig-pool-persist /etc/openvpn/ipp.txt
client-config-dir ccd
#client-to-client

route 10.10.200.0 255.255.255.0


route 192.168.1.0 255.255.255.0
route 192.168.2.0 255.255.255.0
route 192.168.11.0 255.255.255.0
route 192.168.10.0 255.255.255.0
route 192.168.12.0 255.255.255.0
route 192.168.14.0 255.255.255.0
route 192.168.15.0 255.255.255.0
route 192.168.16.0 255.255.255.0
route 192.168.17.0 255.255.255.0

push "route 172.21.0.0 255.255.0.0"
push "route 10.10.200.0 255.255.255.0"

#tun-mtu 1500
#tun-mtu-extra 32
keepalive 10 120

#tls-auth /etc/openvpn/keys/ta.key 0
comp-lzo
user openvpn
group openvpn
persist-key
persist-tun
status /etc/openvpn/openvpn-status.log
log /etc/openvpn/openvpn.log
verb 3

client.conf (один из клиентов) 

client
dev openvpn
dev-type tap
proto udp

remote 111.111.111.111 1194
resolv-retry infinite
nobind
user openvpn
group openvpn
persist-key
persist-tun

ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/client1.crt
key /etc/openvpn/keys/client1.key 

#tls-auth /etc/openvpn/keys/ta.key 1
ns-cert-type server
#tun-mtu 1500
#tun-mtu-extra 32
pull
comp-lzo
verb 3
log /etc/openvpn/openvpn.log
status /etc/openvpn/status-log.log

настройки из каталога ./ccd 

iroute 192.168.1.0 255.255.255.0

лог при запуске сервера. В нём меня смущают строки с 7 по 10 

1.	Fri Jan  6 12:34:06 2012 OpenVPN 2.1.4 x86_64-alt-linux-gnu [SSL] [LZO2] [EPOLL] built on Nov 30 2010
2.	Fri Jan  6 12:34:06 2012 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
3.	Fri Jan  6 12:34:06 2012 Diffie-Hellman initialized with 1024 bit key
4.	Fri Jan  6 12:34:06 2012 TLS-Auth MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
5.	Fri Jan  6 12:34:06 2012 Socket Buffers: R=[124928->131072] S=[124928->131072]
6.	Fri Jan  6 12:34:06 2012 ROUTE default_gateway=195.222.153.193
7.	Fri Jan  6 12:34:06 2012 OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
8.	Fri Jan  6 12:34:06 2012 OpenVPN ROUTE: failed to parse/resolve route for host/network: 10.10.200.0
9.	Fri Jan  6 12:34:06 2012 OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
10.	Fri Jan  6 12:34:06 2012 OpenVPN ROUTE: failed to parse/resolve route for host/network: 192.168.1.0
11.	Fri Jan  6 12:34:06 2012 TUN/TAP device tap01 opened
12.	Fri Jan  6 12:34:06 2012 TUN/TAP TX queue length set to 100
13.	Fri Jan  6 12:34:06 2012 /sbin/ip link set dev tap01 up mtu 1500
14.	Fri Jan  6 12:34:06 2012 /sbin/ip addr add dev tap01 10.10.200.1/24 broadcast 10.10.200.255
15.	Fri Jan  6 12:34:06 2012 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
16.	Fri Jan  6 12:34:06 2012 chroot to '/var/lib/openvpn' and cd to '/' succeeded
17.	Fri Jan  6 12:34:06 2012 GID set to openvpn
18.	Fri Jan  6 12:34:06 2012 UID set to openvpn
19.	Fri Jan  6 12:34:06 2012 UDPv4 link local (bound): [undef]:1194
20.	Fri Jan  6 12:34:06 2012 UDPv4 link remote: [undef]
21.	Fri Jan  6 12:34:06 2012 MULTI: multi_init called, r=256 v=256
22.	Fri Jan  6 12:34:06 2012 IFCONFIG POOL: base=10.10.200.2 size=253
23.	Fri Jan  6 12:34:06 2012 IFCONFIG POOL LIST
24.	Fri Jan  6 12:34:06 2012 solikamsk,10.10.200.4
25.	Fri Jan  6 12:34:06 2012 client1,10.10.200.8
26.	Fri Jan  6 12:34:06 2012 chernushka,10.10.200.12
27.	Fri Jan  6 12:34:06 2012 vereshagino,10.10.200.16
28.	Fri Jan  6 12:34:06 2012 Initialization Sequence Completed

конец лога при подключении одного из клиентов. Тут смущает 5 и 6 строки. 

1.	Fri Jan  6 12:50:15 2012 ip addr add dev openvpn 10.10.200.8/24 broadcast 10.10.200.255
2.	Fri Jan  6 12:50:15 2012 ip route add 172.21.0.0/16 via 10.10.200.1
3.	Fri Jan  6 12:50:15 2012 ip route add 10.10.200.0/24 via 10.10.200.1
4.	RTNETLINK answers: File exists
5.	Fri Jan  6 12:50:15 2012 ERROR: Linux route add command failed: shell command exited with error status: 2
6.	Fri Jan  6 12:50:15 2012 chroot to '/var/lib/openvpn' and cd to '/' succeeded
7.	Fri Jan  6 12:50:15 2012 GID set to openvpn
8.	Fri Jan  6 12:50:15 2012 UID set to openvpn
9.	Fri Jan  6 12:50:15 2012 Initialization Sequence Completed

route после запуска сервера. Как видно, новых маршрутов нет. Если маршрут добавить route add -net 192.168.1.0 dev tap01 , то сервер клиентской сети видно, но за ней никого. При этом заметил, если сменить интерфейс на tun, то даже с прописью маршрутов руками, клиентских серверов не видно. Под видно я имею ввиду ping. А вот сети-клиенты замечательно видят все за сетью сервера при любом раскладе.

[root@host01 openvpn]# ip r
1111.111.111.112/28 dev eth1  proto kernel  scope link  src 111.111.111.111  metric 1
10.10.200.0/24 dev tap01  proto kernel  scope link  src 10.10.200.1
192.168.122.0/24 dev virbr0  proto kernel  scope link  src 192.168.122.1
172.21.0.0/16 dev eth0  proto kernel  scope link  src 172.21.0.1
default via 111.111.111.112 dev eth1  proto static

route на одном из клиентов 

222.222.222.223/30 dev eth1  proto kernel  scope link  src 222.222.222.222
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.1
10.10.200.0/24 dev openvpn  proto kernel  scope link  src 10.10.200.8
172.21.0.0/16 via 10.10.200.1 dev openvpn
default via 222.222.222.223 dev eth1

результаты tcpdump и traceroute, если нужно, напишу.


По поводу ругани относительно маршрутов «10.10.200.0 255.255.255.0». Опция «server» подразумевает собой опции route и push «route», об этом написано в man'e, поэтому в вашем конфиге получается дублирование строк «route 10.10.200.0 255.255.255.0».

Маршруты к сетям за клинетами openvpn (192.168.x.0/24) ЕМНИП нужно прописывать с указанием шлюза.

Если вы знаете что такое tcpdump, то лучше самому и локализовывать проблему --- смотреть уходят ли icmp-пакеты в тунели или нет. Тему вы начали с того, что автоматически при поднятии тунеля не прописываются маршруты, а дальше выясняется, что даже если маршруты прописать, легче не становится.

route add -net 192.168.1.0 dev tap01

ip route add 192.168.1.0/24 via 10.10.200.8

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

по поводу опции server с вами полностью согласен. Но это ни как не причина проблемы. По поводу написания шлюза вы были правы. Я проверял это вариант, но что то при tun интерфейсе не заработало, на tap работает. Для моих целей будет хорош и tap. Вопрос остаётся в том, почему маршруты сами не поднимаются.

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

Подсетей много, хочешь добрый совет? Подними динамический роутинг на OSPF (quagga) - там конфигурации на 30 строчек, а все заморочки с роутингом уйдут сами. Я себе в небольшой опенвпн-сетке так сделал - всё красиво работает, а из опенвпна вообще все упоминания о роутинге убрал.

К примеру для твоего случая: 

Сервер ospfd.conf:
hostname server.net
password zebra
enable password zebra

interface tap0
    ip ospf hello-interval 5
    ip ospf dead-interval 15
    ip ospf priority 100

router ospf
    log-adjacency-changes

    ospf router-id 10.10.200.1
    network 10.10.200.0/24 area 0
    network 192.168.1.0/24 area 1
    network 192.168.2.0/24 area 2
    ...
    network 192.168.17.0/24 area 17
    
    area 1 stub
    area 2 stub
    ...
    area 17 stub

log file /var/log/quagga/ospfd.log


клиент ospfd.conf:
hostname client1.net
password zebra
enable password zebra

interface tap0
    ip ospf hello-interval 5
    ip ospf dead-interval 15
    ip ospf priority 100

router ospf
    log-adjacency-changes

    ospf router-id 10.10.200.2
    network 10.10.200.0/24 area 0
    network 192.168.1.0/24 area 1
    
    area 1 stub

log file /var/log/quagga/ospfd.log

Ну и на других клиентах аналогично. stub-зоны это те сети, за которыми других сетей нет.

И в общем-то всё. А то работать с сетями больше 3-4 штук и статическими маршрутами уже неудобно.

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

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

Сервер ospfd.conf:
hostname server.net
password zebra
enable password zebra

interface tap0
    ip ospf hello-interval 5
    ip ospf dead-interval 15
    ip ospf priority 100

router ospf
    log-adjacency-changes

    ospf router-id 10.10.200.1
    network 10.10.200.0/24 area 0
    network 172.21.0.0/16 area 999
    area 999 stub

log file /var/log/quagga/ospfd.log
Кстати, 172.21/16 - это не полность серая подсеть. Там 172.16.0.0/12, смотри http://en.wikipedia.org/wiki/Private_network, а то залезаешь ей в интернет :)

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

Чертовы праздники... пора бросать пить.. про 172.21/16 туплю... пойду спать дальше :)

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

На tap у вас работает через одно место. Если писать на VPN интерфейс маршрут на адреса, которые расположены за шлюзом:

route add -net 192.168.1.0 dev tap01

то это будет не маршрутизация, а работа через arp-запросы. По умолчанию Линукс отвечает на все arp-запросы, поэтому ваш openvpn клиент, получив через tap-интерейс запрос на адрес 192.168.1.1 отвечает на него, хотя этот адрес у него на eth0-интерфесе. Я ведь ранее написал какой должен быть маршрут.

Директивы route в конфиг-файле сервере не срабатывают, так как в них не указан шлюз и нет подходящего шлюза в ip-адресах клиентов (задаваемых через ifconfig/ifconfig-push).

В вашем случае для каждого клиента нужен отдельный файл в «client-config-dir» и там каждому клиенту задаётся фиксированный адрес через «ifconfig-push» и для каждого клиента задаётся свой «route». Или делайте динамическую маршрутизацию.

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

Спасибо за наводку. Посмотрел, в принципе решение неплохое, но «слезать с поезда не буду», в нём нет таких особенностей, которые пригодились бы мне и которых нет в openvpn. Доступ клиентских сетей друг к другу не нужен, только в основную сеть. Канала на всех концах достаточно толстые.Но тестировать буду.

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