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

OpenVPN соединение подразделений

 


0

3

Добрый вечер. Столкнулся с такой проблемой (прошу не кидаться помидорами).
Есть 2 сервера, находятся удаленно.
Сеть №1: 192.168.20.0/24
Сеть №2: 192.168.21.0/24
VPN-сеть: 10.8.0.0/24
10.8.0.1 - сервер №1
10.8.0.2 - сервер №2

Соединение устанавливается, сервер №1 пингует 10.8.0.2
На сервере №1 видна сеть №2.
Сервер №1 не пингует хосты в подсети 2, причем при пинге 192.168.21.3 tcpdump -i tun0 говорит что пакет отправляется. А на другом конце tcpdump ничего не говорит, вообще пакетов нет. правила iptables ставил в ACCEPT.

На сервере №2 в таб.маршрутизации не видна подсеть №1.
Такое ощущение что проблема в маршрутизации.
Конфиг сервера:

mode server
local 192.168.20.2
port 1922
proto udp
dev tun0
ca /etc/openvpn/ca.crt
cert /etc/openvpn/srv.crt
key /etc/openvpn/srv.key
dh /etc/openvpn/dh1024.pem
topology subnet
ifconfig 10.8.0.1 255.255.255.0
ifconfig-pool 10.8.0.2 10.8.0.20
push "route 192.168.20.0 255.255.255.0"
route 192.168.21.0 255.255.255.0 10.8.0.2
client-config-dir ccd
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
tls-server
tls-auth /etc/openvpn/ta.key 0
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3
keepalive 15 30 
;mute 20

[ccd] 
ifconfig-push 10.8.0.2 255.255.255.0
iroute 192.168.21.0 255.255.255.0

Конфиг клиента
[client] 
tls-client
remote 192.168.20.209 1922
client
dev tun1
comp-lzo
proto udp
tls-auth /etc/openvpn/ta.key 1
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
key /etc/openvpn/client.key
verb 3
pull


Ответ на: комментарий от alexnorton

Если 192.168.21.3 то звездочки. не доходит. Если конец тунеля то всё ОК.

BoDRbI
() автор топика

На сервере №1 видна сеть №2.
Сервер №1 не пингует хосты в подсети 2

Что, я не понял?

на другом конце tcpdump ничего не говорит, вообще пакетов нет

Под другим концом что подразумевается?

Вообще сложилось ощущение, что серверы не форвардят пакеты.

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

если на сервере 1 в таблице маршрутизации появляется маршрут в подсеть .192.168.21.0 Если на нем запустить ping 192.168.21.3 (хост в той подсети)

Другой конец - это сервер №2, запускаю tcpdump -i tun1

Ну я тоже подумывал, но тогда бы пакеты всё равно бы ловились tcpdump'ом на втором сервере. + правила в forward прописал.

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

Можно таблицу маршрутизации с первого сервера посмотреть? А так же строки tcpdump'а с первого сервера при пинге второго сервера и машины, находящейся за ней. Кажется какая-то мелочь упущена, но я пока не представляю куда копать.

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

Эх. могу только завтра с утра показать, не на работе.

Нуу... tcpdump показывается только рекуесты 10.8.0.1 > 192.168.21.3

Я вот думаю не виновато ли topology subnet ?

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

Таблица маршрутизации первого сервера: 

Destination  Gateway   Genmask       Flags Metric Ref Use Iface

192.168.21.0 10.8.0.2  255.255.255.0 UG     0     0   0   tun0 
10.8.0.0     0.0.0.0   255.255.255.0 U      0     0   0   tun0 
192.168.20.0 0.0.0.0   255.255.255.0 U      0     0   0   eth0 
0.0.0.0    192.168.20.1 0.0.0.0      UG     0     0   0   eth0
А вот пинг хоста в подсети№2 c сервера№1: 
tcpdump -i tun0

08:01:28.877285 IP 10.8.0.1 > 192.168.21.3: ICMP echo request, id 5342, seq 1, length 64

08:01:29.886197 IP 10.8.0.1 > 192.168.21.3: ICMP echo request, id 5342, seq 2, length 64

08:01:30.894173 IP 10.8.0.1 > 192.168.21.3: ICMP echo request, id 5342, seq 3, length 64

08:01:31.902168 IP 10.8.0.1 > 192.168.21.3: ICMP echo request, id 5342, seq 4, length 64

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

c обоих сторон покажи ip a ip r iptables-save

Сервер №1: 

ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:0c:29:32:a5:42 brd ff:ff:ff:ff:ff:ff
    inet 192.168.20.2/24 brd 192.168.20.255 scope global eth0
    inet6 fe80::20c:29ff:fe32:a542/64 scope link
       valid_lft forever preferred_lft forever
26: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none
    inet 10.8.0.1/24 brd 10.8.0.255 scope global tun0


ip r

192.168.21.0/24 via 10.8.0.2 dev tun0
10.8.0.0/24 dev tun0  proto kernel  scope link  src 10.8.0.1
192.168.20.0/24 dev eth0  proto kernel  scope link  src 192.168.20.2
default via 192.168.20.1 dev eth0

iptables-save

*filter
:INPUT ACCEPT [107884:15467368]
:FORWARD ACCEPT [64:10804]
:OUTPUT ACCEPT [15861:1951684]
COMMIT

Сервер №2:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth_local: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:25:22:0b:d2:5f brd ff:ff:ff:ff:ff:ff
    inet 192.168.21.10/24 brd 192.168.21.255 scope global eth_local
    inet6 fe80::225:22ff:fe0b:d25f/64 scope link
       valid_lft forever preferred_lft forever
3: eth_inet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:21:91:12:55:ac brd ff:ff:ff:ff:ff:ff
    inet 192.168.250.2/24 brd 192.168.250.255 scope global eth_inet1
    inet6 fe80::221:91ff:fe12:55ac/64 scope link
       valid_lft forever preferred_lft forever
4: eth_inet2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:26:18:eb:ce:6b brd ff:ff:ff:ff:ff:ff
    inet 91.85.145.181/22 brd 91.85.148.255 scope global eth_inet2
    inet6 fe80::226:18ff:feeb:ce6b/64 scope link
       valid_lft forever preferred_lft forever
18: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/none
    inet 10.8.0.2/24 brd 10.8.0.255 scope global tun0


10.8.0.0/24 dev tun0  proto kernel  scope link  src 10.8.0.2

192.168.21.0/24 dev eth_local  proto kernel  scope link  src 192.168.21.10

192.168.250.0/24 dev eth_inet1  proto kernel  scope link  src 192.168.250.2

891.85.145.0/22 dev eth_inet2  proto kernel  scope link  src 91.85.145.181

default via 192.168.250.1 dev eth_inet1
BoDRbI
() автор топика
Ответ на: комментарий от BoDRbI 
10.8.0.0/24 dev tun0  proto kernel  scope link  src 10.8.0.2

192.168.21.0/24 dev eth_local  proto kernel  scope link  src 192.168.21.10

192.168.250.0/24 dev eth_inet1  proto kernel  scope link  src 192.168.250.2

891.85.145.0/22 dev eth_inet2  proto kernel  scope link  src 91.85.145.181

default via 192.168.250.1 dev eth_inet1

Покажите, из какого правила тут сервер узнает, что ответ на пакет из подсети 192.168.20.0/24 нужно отправить в tun0? Должно быть еще что-то вроде 

192.168.20.0/24 блаблабла dev tun0

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

ip_forward включен?

Вообще как-то странно. Давайте еще раз:

Пингуем с адреса 10.8.0.1 -> 10.8.0.2 - все пингуется, пакеты доходят, tcpdump пакеты ловит, все счастливы.

Пингуем с адреса 10.8.0.1 -> 192.168.21.10 (сам второй сервак) или 192.168.21.Х (любой другой хост в подсети) - ничего не пингуется, tcpdump ничего не видит, все в печали.

Верно?

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

ip_forward включен.

Всё верно. Обнаружил еще такую штуку.

Прописал на втором конце маршрут руками route add -net 192.168.20.0/24 gw 10.8.0.1

и о чудо, пинг до ip-адреса впн сервера №1 пошел!

Но если пробую пинг до 192.168.21.10 (сам второй сервак) не идет!

И если пингую любой другой хост в подсети №1 пинг не идет.

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

Сделайте на втором серваке (10.8.0.2)

ip ro del default via 192.168.250.1 dev eth_inet1
ip ro add default dev tun0

Посмотрите, изменится ли что-нибудь.

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

А, пардон, по привычке как у меня сделано посоветовал. :)

У меня обычно для опенвпн клиентов явно прописаны маршруты внешний_интерфейс_сервера <-> внешний_интерфейс_клиента, а остальное по дефолту заруливается в туннель. Но у меня не topology subnet, а обычные /30 подсети, с ними имхо проще.

strangeman ★★★★
()
Последнее исправление: strangeman (всего исправлений: 2)
Ответ на: комментарий от winlook38

Да я вот на него грешу. На первом сервере прописал 

iptables -t nat -A POSTROUTING -s 10.8.0.0/255.255.255.0 -o eth0 -j MASQUERADE
и с сервера №2 моя подсеть №1 пингуется. А вот с сервера №1 не могу не один хост в подсети №2 пинговать

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

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

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

Ну ты исчерпал все мои догадки, осталась только фантазия.

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

+ Я пробывал на винде поднимать, такая же ситация. я не могу пинговать локальные адреса удаленно, а с винды меня можно.

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

Посмотри еще заголовки исходящих пакетов на первом сервере при пинге второго сервера и при пинге хоста за ним.

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

Вот выхлоп, когда с Сервака №1 пингую хост во второй подсети: 

11:12:16.906184 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.8.0.1 > 192.168.21.10: ICMP echo request, id 6001, seq 23, length 64
11:12:17.914179 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.8.0.1 > 192.168.21.10: ICMP echo request, id 6001, seq 24, length 64

А вот выхлоп в обратную сторону: 

11:14:13.916229 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.8.0.2 > 192.168.20.15: ICMP echo request, id 24689, seq 1, length 64
11:14:14.183028 IP (tos 0x0, ttl 127, id 20702, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.20.15 > 10.8.0.2: ICMP echo reply, id 24689, seq 1, length 64
11:14:14.916857 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.8.0.2 > 192.168.20.15: ICMP echo request, id 24689, seq 2, length 64
11:14:15.203242 IP (tos 0x0, ttl 127, id 20707, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.20.15 > 10.8.0.2: ICMP echo reply, id 24689, seq 2, length 64
11:14:15.917027 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)

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

Выяснил, что по какой-то магической причине, траффик не уходит за пределы VPN сервера №1, на шлюзи ничего нет

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

Вообщем-то опция не для этого, на всякий случай проверил - не работает

BoDRbI
() автор топика

В конфиге сервера в строке «route 192.168.21.0 255.255.255.0 10.8.0.2» 10.8.0.2 - лишнее.

Если вы хотите просто связать два подразделения, для чего это?

push «redirect-gateway def1 bypass-dhcp»
push «dhcp-option DNS 8.8.8.8»
push «dhcp-option DNS 8.8.4.4»

В конфиге клиента, если указано «client», то «tls-client» и «pull» не нужно указывать.

«remote 192.168.20.209 1922» - это вы здесь такой адрес написали? Как оно реально соединяется?

Ещё желательно бы посмотреть на логи соединения со стороны клиента и сервера.

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

Вообщем день мучений привел к следующим результатам: (для наглядности картинка) http://postimg.org/image/4pgxjhg5v/

VPN сервер имеет ip: 

10.8.0.1
192.168.20.2

VPN клиент имеет: 

10.8.0.2
192.168.21.10

Мой компьютер: 

192.168.20.15

Очистил на сервере все правила фаервола, всё в ACCEPT. На своем компьютере добавил маршрутики, чтобы в 10.8.0.0 и 192.168.21.0 шел трафик через 192.168.20.2

VPN соединение устанавливается. если на клиенте набрать: 

ping -I 10.8.0.2 192.168.20.15
то пинг идет! но если 

ping -I 192.168.21.10 192.168.20.15

то пинг не идет, отправляются только реквесты. причем анализ tcpdump'ом показал, что с клиента они уходят, vpn udp трафик проходит на шлюз сети 1. и всё.

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

ping -I 192.168.21.10 10.8.0.2
то пинг идет, возможно потому что directly connected.

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

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

Вопрос решил. Перелопатил конфиг сервера, в принципе по сути изменений не сделал, строчки местами поменял, и 

client-config-dir ccd
заменил на: 
client-config-dir /etc/openvpn/ccd

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

Хм. Должно и с относительными путями работать. Хотя в рассылках иногда встречаются такие случаи, что с относительными не работало, а с абсолютными ВНЕЗАПНО заработало.

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

У меня с ключами такая беда была, тоже относительные пути были прописаны - не подхватывались, после прописывания абсолютного пути все работало, и как-то не обращал внимания на client-config-dir

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