OpenVPN и роутинг между сетями

Question

[Евгений Елизаров]

Есть 2 сервера, соединённые между собой через OpenVPN. Задача — сделать доступными ресурсы внутренних сетей этих сервером между собой.
Сервер #1 (который так же является сервером OpenVPN):
eth0 — 192.168.0.1
eth1 — external interface
tap0 — 10.8.0.1

Конфиг OpenVPN (лишнее вырезано):
#Порт
port 1194
#Протокол
proto udp
#Тип интерфейса
dev tap0
#Режим работы сервера
mode server
#Серверу назначается первый адрес из первой подсети
ifconfig 10.8.0.1 255.255.255.0
#Клиентам
ifconfig-pool 10.8.0.10 10.8.0.100
#Системе объявляется маршрут на всю OpenVPN-сеть
route 10.8.0.0 255.255.255.0
#Передаётся маршрут на всю OpenVPN-сеть клиентам
push «route 192.168.0.0 255.255.255.0»
#Шлюз длы вышеуказанных маршрутов
push «route-gateway 10.8.0.1»

Сервер #2
eth0 — external interface
eth1 — 192.168.1.1
tap0 — 10.8.0.11

Конфиг OpenVPN (лишнее вырезано):
#Режим работы
client
#Тип интерфейса
dev tap
#Протокол
proto udp
#Адресс сервера и порт
remote ip 1194
#принимать команды push от сервера.то есть позволять переконфигурировать клиента
pull

Сейчас всё подключается и работает и сервера друг друга пингуют (по 192.168.*.1), а вот в сеть дальше уже как то не алло. С сервера 2 пингую машинку
192.168.1.1# ping 192.168.0.254
PING 192.168.0.254 (192.168.0.254) 56(84) bytes of data.
^C
— 192.168.0.254 ping statistics — 5 packets transmitted, 0 received, 100% packet loss, time 4548ms
а сервере 1 запускаю tcpdump:
192.168.0.1# tcpdump -i tap0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:19:42.862971 IP 10.8.0.11 > 192.168.0.254: ICMP echo request, id 20265, seq 1, length 64
12:19:43.862806 IP 10.8.0.11 > 192.168.0.254: ICMP echo request, id 20265, seq 2, length 64
12:19:44.862721 IP 10.8.0.11 > 192.168.0.254: ICMP echo request, id 20265, seq 3, length 64
12:19:45.862667 IP 10.8.0.11 > 192.168.0.254: ICMP echo request, id 20265, seq 4, length 64
12:19:46.862640 IP 10.8.0.11 > 192.168.0.254: ICMP echo request, id 20265, seq 5, length 64

в iptables только одно правило:
iptables -A FORWARD -p ALL -s 192.168.1.0/24 -d 192.168.0.0/24 -j ACCEPT

Вопрос №1: что я не докрутил?
Вопрос №2: что я не докрутил что у при пинге с 1-го сервера машин за вторым сервером tcpdump вообще молчит?

Comments

[shadowalone]

А для клиентских машин, эти сервера являются шлюзами по умолчанию?

Answer 1

[cjey]

возможно я был невнимателен, но мне кажется:
1) не хватает правила iptables -A FORWARD -p ALL -s 192.168.0.0/24 -d 192.168.1.0/24 -j ACCEPT
2) нужно добавить маршруты на серверах
например на 2-м сервере нужно добавить маршрут route add -host 192.168.0.254 gw 10.8.0.1 (синтаксис не проверял, но общая идея такая.). Ну или сразу маршрут для всей подсети 192.168.0.0/24
3) После того как заработает пинг от серверов в дальнюю подсеть возможно нужно будет добавлять маршруты на клиентских машинах.

Comments

[Евгений Елизаров]

1. А чего конкретно не хватает?
2. Маршруты все есть
192.168.0.1# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 217.70.27.145 0.0.0.0 UG 3 0 0 eth1
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0
127.0.0.0 127.0.0.1 255.0.0.0 UG 0 0 0 lo
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.1.1 10.8.0.1 255.255.255.255 UGH 0 0 0 tap0
217.70.27.144 0.0.0.0 255.255.255.240 U 3 0 0 eth1

192.168.1.1# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
10.43.148.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.0.0 10.8.0.1 255.255.255.0 UG 0 0 0 tap0
169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1003 0 0 eth1
0.0.0.0 10.43.148.1 0.0.0.0 UG 0 0 0 eth0

3. Ну не в ручную же все маршруты прописывать то!?

[cjey]

1) не хватает правила для пакетов которые пойдут обратно. т.е. пакет дойдет из 192.168.0.0 в 192.168.1.0, а обратный пакет отбросится фаирволом.

[cjey]

Вобщем правила должны быть такими
iptables -I FORWARD -p ALL -s 192.168.1.0/24 -d 192.168.0.0/24 -j ACCEPT
iptables -I FORWARD -p ALL -s 192.168.0.0/24 -d 192.168.1.0/24 -j ACCEPT

2) 1й сервер ничего не знает про подсеть 192.168.1.0/24. он смотрит на пакет, не знает куда его отправить и отбрасывает.

3) скорее всего этого делать не придется. Если вдруг, после того как 1й сервер увидит дальнюю сеть, с рабочих компьютеров не будут доступны компьютеры из дальней подсети, то копать стоит в эту сторону.

[Евгений Елизаров]

1. Не помогает — 192.168.0.254 с клиента всё так же не пингуется.
2. route add 192.168.1.0 gw 10.8.0.10 не даёт ничего, 192.168.1.1 даже не пингуется, только если в ручную указывать route add 192.168.1.1 gw 10.8.0.10 тогда пинг идёт.

[cjey]

сначала нужно заставить 1й сервер пинговать дальнюю подсеть.
для этого нужно добавить маршрут
на 1м сервере: route add -net 192.168.1.0 -netmask 255.255.255.0 10.8.0.11
на 2м сервере: route add -net 192.168.0.0 -netmask 255.255.255.0 10.8.0.1
после того, как заработает пинг в дальнюю подсеть с 1-го сервера можно уже тестировать доступность с клиентских машин

[Евгений Елизаров]

Он у меня никак не хочет воспринимать netmask, я уже как только не изгалялся. пс если что — на первой машине — gentoo, на второй — centos

[cjey]

так должно работать «route add -net 192.168.11.0 netmask 255.255.255.0 gw 10.8.0.11»

[Евгений Елизаров]

Вот!!! Теперь со стороны сервера пингует всё внутри клиентской сети, вот только добавление роута (хотя он там в общем то есть) не помогло с клиентского сервера пинговать внутрь серверной подсети.

[cjey]

На 2-м сервере нужно выполнить:
«route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.8.0.1»

После того, как будет ходить пинг от обоих серверов в дальние сети, нужно будет разбираться с правилами фаирвола

Answer 2

[Manitou]

Вам нужно почитать документацию на сайте openvpn или man openvpn, по поводу опции --iroute, можно так же прочесть о --client-config-dir. То есть нужно указание и route и iroute, если коротко, то вот:

The reason why two routes are needed is that the --route directive routes the packet from the kernel to OpenVPN. Once in OpenVPN, the --iroute directive routes to the specific client.

Answer 3

[diger_74]

На беглый взгляд не хватает client-to-client в конфиге сервера, чтобы видны были подсети за ними.

А вообще ваш сценарий достаточно подробно описан тут.

Answer 4

[smartlight]

посмотрите сюда habrahabr.ru/qa/20127/#answer_81988

Comments

[smartlight]

и iptables пожалуйста не трогаете, openvpn всё сделает сам, пускай FORWARD будет по умолчанию ACCEPT, всё остальное сделают роуты

[Евгений Елизаров]

Спасибо, видимо всё-таки придётся прибегнуть к вашим советам и нормально настроить OpenVPN и не трогать iptables :)

[smartlight]

в свое время мне помогда вот эта тема forum.ixbt.com/topic.cgi?id=14:40906 и её куратор уважаемый vinni

[Евгений Елизаров]

Попробовал переписать конфиг:
# cat /etc/openvpn/openvpn.conf
#Серверу назначается первый адрес из первой подсети
ifconfig 10.8.0.1 255.255.255.0

#Клиентам
ifconfig-pool 10.8.0.10 10.8.0.100

#Системе объявляется маршрут на всю OpenVPN-сеть
route 10.8.0.0 255.255.255.0
route 192.168.0.0 255.255.255.0
route 192.168.1.0 255.255.255.0

#Передаётся маршрут на всю OpenVPN-сеть клиентам
push «route 192.168.0.0 255.255.255.0»
push «route 192.168.1.0 255.255.255.0»

#Шлюз длы вышеуказанных маршрутов
push «route-gateway 10.8.0.1»

client-config-dir /etc/openvpn/ccd

client-to-client

# cat /etc/openvpn/ccd/korpserver2
ifconfig-push 10.8.0.10 10.8.0.11
iroute 192.168.1.0 255.255.255.0

со второго сервака 192.168.0.1 пингуется, остальное — нет, с первого сервака 192.168.1.1 не пингуется, пока руками не добавил route add 192.168.1.1 gw 10.8.0.10, но сеть за сервером тоже не пингуется. Все правила в iptables убрал. Ну а дальше всё как в топике:
192.168.1.1# ping 192.168.0.254
PING 192.168.0.254 (192.168.0.254) 56(84) bytes of data.
^C
— 192.168.0.254 ping statistics — 5 packets transmitted, 0 received, 100% packet loss, time 4548ms
а сервере 1 запускаю tcpdump:
192.168.0.1# tcpdump -i tap0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:19:42.862971 IP 10.8.0.11 > 192.168.0.254: ICMP echo request, id 20265, seq 1, length 64
12:19:43.862806 IP 10.8.0.11 > 192.168.0.254: ICMP echo request, id 20265, seq 2, length 64
12:19:44.862721 IP 10.8.0.11 > 192.168.0.254: ICMP echo request, id 20265, seq 3, length 64
12:19:45.862667 IP 10.8.0.11 > 192.168.0.254: ICMP echo request, id 20265, seq 4, length 64
12:19:46.862640 IP 10.8.0.11 > 192.168.0.254: ICMP echo request, id 20265, seq 5, length 64

а в обратную сторону — вообще тишина.

Answer 5

[g00dtlt]

Если не хотите заморачиваться c линуксом, поставьте routeros

Comments

[Евгений Елизаров]

А я хочу :)

Answer 6

[Евгений Елизаров]

1. А чего конкретно не хватает?
2. Маршруты все есть
192.168.0.1# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 217.70.27.145 0.0.0.0 UG 3 0 0 eth1
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0
127.0.0.0 127.0.0.1 255.0.0.0 UG 0 0 0 lo
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.1.1 10.8.0.1 255.255.255.255 UGH 0 0 0 tap0
217.70.27.144 0.0.0.0 255.255.255.240 U 3 0 0 eth1

192.168.1.1# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.8.0.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
10.43.148.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.0.0 10.8.0.1 255.255.255.0 UG 0 0 0 tap0
169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1003 0 0 eth1
0.0.0.0 10.43.148.1 0.0.0.0 UG 0 0 0 eth0

3. Ну не в ручную же все маршруты прописывать то!?

Comments

[shadowalone]

нет маршрута на сервере 192.168.0.1 в сеть 192.168.1.0/24

[shadowalone]

Вот вам готовый вариант — goo.gl/yUsKu
Зачем Вам сервер-клиент, если всего одно соединение.

Answer 7

[AlekseyPolyakov]

Вам нужно задействовать функцию ccd на сервере, который выступает OpenVPN сервером. Создать конфигурационный файл (имя ключа без расширения) на клиенский ключ второго сервера.В файле сделать push «route z.z.z.z» той подсети, с которой должен общаться клиет.

route в конфигурационном файле сервера означает, что клиент будет знать куда направить пакет, а по ccd конфигурационному файду клиента, сервер будет знать куда отдать ответ.