Не могу понять, почему не работает туннель?

Question

[MaxxDamage]

Доброго времени суток.
Помогите пожалуйста с настройкой туннеля между двумя сетями.
Имеется: Две сети, каждая со своим шлюзом на Debian. У каждого шлюза по 2 интернет интерфейса, и 1 локальный. Сеть сервера - 192.168.0.0, сеть клиента - 192.168.1.0. Не получается между ними настроить туннель. Пинг от клиента идёт только до шлюза сервера (192.168.0.1), пинг от сервера не идёт даже до шлюза клиента (192.168.1.0). Форварды в iptables разрешены. Маршруты вроде как настроены, но возможно что неправильно. Приложу в комментах настройки OpenVPN сервера и клиента

Comments

[MaxxDamage]

Сервер:

spoiler

local 94.181.xx.xx
port 649xx
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.1.0 255.255.255.0 10.8.0.2"
client-config-dir xxx
route 192.168.1.0 255.255.255.0 10.8.0.1
tls-auth ta.key 0

auth SHA512

tls-version-min 1.2
cipher AES-128-CBC
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3

log /var/log/openvpn.log

Клиент

spoiler

client
dev tun

proto udp

remote 94.181.xx.xx 649xx

route 192.168.0.0 255.255.255.0

resolv-retry infinite

nobind

user nobody
group nogroup

persist-key
persist-tun

ca ca.crt
cert kaxxx.crt
key kaxxx.key

ns-cert-type server

tls-auth ta.key 1

auth SHA512

cipher AES-128-CBC

comp-lzo

verb 3

log /var/log/openvpn.log

Ответ ip ro li
сервера:

spoiler

default via 94.181.xxx.xxx dev eth0 onlink
10.8.0.0/24 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
94.0.0.0/8 via 94.181.180.254 dev eth0
94.181.xxx.0/24 dev eth0 proto kernel scope link src 94.181.xxx.xx
94.181.xxx.0/24 dev eth1 proto kernel scope link src 94.181.xxx.xxx
192.168.0.0/24 dev eth2 proto kernel scope link src 192.168.0.1
192.168.1.0/24 via 10.8.0.2 dev tun0

клиента:

spoiler

default via 94.180.zzz.zzz dev eth0
10.8.0.1 via 10.8.0.9 dev tun0
10.8.0.9 dev tun0 proto kernel scope link src 10.8.0.10
94.0.0.0/8 via 94.180.249.254 dev eth0
94.180.zzz.0/24 dev eth0 proto kernel scope link src 94.180.zzz.zzz
94.180.zzz.0/24 dev eth2 proto kernel scope link src 94.180.zzz.zzz
192.168.0.0/24 via 10.8.0.9 dev tun0
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1

Собственно все настройки перенесены с другого сервера, к котором раньше подключался клиент. Но понадобилось перенести всё это на другую машину, с другими наружными IP-адресами. При переключении на старый шлюз всё работает. На новом, с аналогичными настройками (само собой заменены сетевые интерфейсы и IP-адреса в настройках) - не работает. Вывод ip ro li у старого шлюза тоже не отличается.

[res2001]

Что в логах openvpn клиента и сервера?
Если конфиг рабочий, то проблема, видимо, не в openvpn. Пинг не показатель.
Блокировать трафик может фаервол на сервере или клиенте или на любом промежуточном шлюзе.

[MaxxDamage]

res2001, настройки файрвола тоже перенесены со старого шлюза, соответственно с заменой адресов и интерфейсов. Других промежуточных шлюзов нет.
Сервер:

spoiler

-A FORWARD -i tun0 -j ACCEPT
-A FORWARD -o tun0 -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -d 192.168.1.0/24 -j ACCEPT
-A FORWARD -s 192.168.1.0/24 -d 10.8.0.0/24 -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -d 192.168.0.0/24 -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -d 10.8.0.0/24 -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -d 192.168.1.0/24 -j ACCEPT
-A FORWARD -s 192.168.1.0/24 -d 192.168.0.0/24 -j ACCEPT

Клиент:

spoiler

-A FORWARD -s 10.8.0.0/24 -d 192.168.0.0/24 -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -d 10.8.0.0/24 -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -d 192.168.1.0/24 -j ACCEPT
-A FORWARD -s 192.168.1.0/24 -d 192.168.0.0/24 -j ACCEPT

[res2001]

Что в логах openvpn на обеих сторонах?
Пинговать начните от узлов ВПН. Если клиент видит сервер (пингуется), то ВПН работает и проблема в настройках маршрутизации во внутренних сетях.

[MaxxDamage]

res2001, да, клиент видит и пингует сервер (192.168.0.1), но дальше не видит. А сервер не пингует клиента. Логи щас уже приложить не могу, днём приходится переключать всё на старый шлюз, чтобы хоть как-то работало.
С маршрутизацией и прошу подсказать - вроде маршруты такие же как на старом шлюзе, но не работает.

[res2001]

MaxxDamage, Я так понял вы меняете только ВПН сервер (он же является шлюзом по умолчанию для внутренней сети)?
IP адрес нового ВПН сервера внутри своей сети такой же как у старого?

[MaxxDamage]

res2001, да, шлюз, он же сервер OpenVPN. Клиент OpenVPN остаётся на старом месте, там ничего не меняется. Внутри сети IP адрес тот же, да (192.168.0.1). Поменялся собственно только сетевой интерфейс локальной сети (и в настройках был изменён), и внешний IP-адрес. Хотя возможно было правильнее подключить сети к тем же интерфейсам что и на старом...

Answer 1

[res2001]

MaxxDamage,
Конфиг сервера:
push "route 192.168.1.0 255.255.255.0 10.8.0.2"
Обычно в route не задают третий параметр - он подставляется автоматически - адрес ВПН сервера.
push "route ..." прописывает на клиенте маршрут до сети за сервером. У вас же эта команда прописывает на клиенте маршрут за клиентом. Этот маршрут и так присутствует на клиенте.
Нужно ее привести в такой вариант:
push "route 192.168.0.0 255.255.255.0"
После подключения клиента в его таблице маршрутизации должен появиться соответствующий маршрут.

Директива
route 192.168.1.0 255.255.255.0 10.8.0.1
в таком виде не правильна.
route добавляет маршрут на своей стороне (т.е. на стороне сервера в данном случае). Нужно в третьем параметре указать адрес клиента (10.8.0.1 - наверняка адрес сервера).
Но лучше перенести эту директиву в клиентский конфиг на сервере (это тот который лежит в пути указанном в директиве client-config-dir) в следующем виде:
iroute 192.168.1.0 255.255.255.0
Тогда при подключении клиента маршрут к его сети добавится на сервере, адрес клиента автоматически добавится к директиве, его указывать явно не нужно.

Конфиг клиента:
Директива
route 192.168.0.0 255.255.255.0
тут не нужна. Ее функции выполняет директива push "route ..." в конфиге сервера.
Вообще обычно клиентский конфиг делают максимально простым. Вся маршуртизация прекрасно конфигурируется на стороне сервера.

Вообще можно конфигурацию ВПН полностью отладить на виртуалках в своей виртуальной сети и перенести ее на реальное железо, заменив только слушающий адрес сервера в директиве local.

Comments

[MaxxDamage]

Да это я уже экспериментировал с настройками. Изначально так и было - на сервере route 192.168.1.0 255.255.255.0, в ccd указано iroute 192.168.1.0 255.255.255.0.
Изначально конфиг переносился с уже работающего сервера, на клиенте только заменили ip адрес по которому он обращается к серверу, и всё. Но всё равно не работало. Точнее, работало, но только в одну сторону - со стороны сети сервера сеть клиента пинговалась, со стороны клиента пинговался только сервер. Все настройки iptables тоже были перенесены со старого шлюза, с заменой адресов на пробросах. Вот разве что у нового и старого сервера не совпадают сетевые интерфейсы. Сегодня вечером попробую переподключить их так же как на старом

[res2001]

MaxxDamage, Ну значит у вас было все верно.
Вы сначала добейтесь, чтоб у вас была связь (пинг, ssh и т.п.) между клиентом и сервером в обе стороны через ВПН. Для тестов используйте внутренние ВПН адреса клиента и сервера, а не их адреса в ЛВС.

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

[MaxxDamage]

res2001, причесал настройки OpenVPN. Маршруты есть, судя по выхлопу ip route
Сервер:

spoiler

ip route
default via 94.181.xxx.xxx dev eth2 onlink
10.8.0.0/24 via 10.8.0.2 dev tun0
10.8.0.2 dev tun0 proto kernel scope link src 10.8.0.1
94.181.xxx.x/24 dev eth2 proto kernel scope link src 94.181.xxx.xx
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.1
192.168.1.0/24 via 10.8.0.2 dev tun0

клиент:

spoiler

default via 94.180.zzz.zzz dev eth0
10.8.0.1 via 10.8.0.9 dev tun0
10.8.0.9 dev tun0 proto kernel scope link src 10.8.0.10
94.0.0.0/8 via 94.180.zzz.zzz dev eth0
94.180.zzz.z/24 dev eth0 proto kernel scope link src 94.180.zzz.zzz
94.180.250.0/24 dev eth2 proto kernel scope link src 94.180.250.147
192.168.0.0/24 via 10.8.0.9 dev tun0
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1

iptables на сервере:

spoiler

-A FORWARD -i tun0 -j ACCEPT
-A FORWARD -o tun0 -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -d 192.168.1.0/24 -j ACCEPT
-A FORWARD -s 192.168.1.0/24 -d 10.8.0.0/24 -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -d 192.168.0.0/24 -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -d 10.8.0.0/24 -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -d 192.168.1.0/24 -j ACCEPT
-A FORWARD -s 192.168.1.0/24 -d 192.168.0.0/24 -j ACCEPT

И всё равно не работает - с клиента пингуется только сервер, сеть за сервером не пингуется. С сервера не пингуется даже клиент.

[res2001]

MaxxDamage,
Судя по таблицам маршрутизции ВПН соединение устанавливается.
В логах ВПН есть ошибки?
Если в логах ВПН ошибок нет, надо смотреть в сторону фаервола. Попробуйте для начала открыть все на tun0 и проверьте связь обе стороны между клиентом и сервером. Затем можно приводить правила фаервола к тому виду, который вам нужен.

[MaxxDamage]

res2001, так открыто всё на tun0, настройки iptables тоже приложил выше. Ошибок судя по всему в логах нет, но на всяки случай скину тоже их.
лог сервера:

spoiler

Wed Sep 11 18:43:54 2019 Initialization Sequence Completed
Wed Sep 11 18:44:03 2019 94.180.zzz.zzz:33663 TLS: Initial packet from [AF_INET]94.180.zzz.zzz:33663, sid=cc6a93d7 f34b17f2
Wed Sep 11 18:44:03 2019 94.180.zzz.zzz:33663 VERIFY OK: depth=1, C=RU, ST=PNZ, L=Penza, O=MLS IT Systems, OU=IT dept, CN=key.mlsit.ru, name=EasyRSA, emailAddress=[e-mail]
Wed Sep 11 18:44:03 2019 94.180.zzz.zzz:33663 VERIFY OK: depth=0, C=RU, ST=PNZ, L=Penza, O=MLS IT Systems, OU=IT dept, CN=kazan, name=EasyRSA, emailAddress=[e-mail]
Wed Sep 11 18:44:03 2019 94.180.zzz.zzz:33663 peer info: IV_VER=2.3.4
Wed Sep 11 18:44:03 2019 94.180.zzz.zzz:33663 peer info: IV_PLAT=linux
Wed Sep 11 18:44:03 2019 94.180.zzz.zzz:33663 Outgoing Data Channel: Cipher 'AES-128-CBC' initialized with 128 bit key
Wed Sep 11 18:44:03 2019 94.180.zzz.zzz:33663 Outgoing Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication
Wed Sep 11 18:44:03 2019 94.180.zzz.zzz:33663 Incoming Data Channel: Cipher 'AES-128-CBC' initialized with 128 bit key
Wed Sep 11 18:44:03 2019 94.180.zzz.zzz:33663 Incoming Data Channel: Using 512 bit message hash 'SHA512' for HMAC authentication
Wed Sep 11 18:44:03 2019 94.180.zzz.zzz:33663 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Wed Sep 11 18:44:03 2019 94.180.zzz.zzz:33663 [kazan] Peer Connection Initiated with [AF_INET]94.180.zzz.zzz:33663
Wed Sep 11 18:44:03 2019 kazan/94.180.zzz.zzz:33663 OPTIONS IMPORT: reading client specific options from: /etc/openvpn/xxx//kazan
Wed Sep 11 18:44:03 2019 kazan/94.180.zzz.zzz:33663 MULTI_sva: pool returned IPv4=10.8.0.10, IPv6=(Not enabled)
Wed Sep 11 18:44:03 2019 kazan/94.180.zzz.zzz:33663 MULTI: Learn: 10.8.0.10 -> kazan/94.180.zzz.zzz:33663
Wed Sep 11 18:44:03 2019 kazan/94.180.zzz.zzz:33663 MULTI: primary virtual IP for kazan/94.180.zzz.zzz:33663: 10.8.0.10
Wed Sep 11 18:44:03 2019 kazan/94.180.249.180:33663 MULTI: internal route 192.168.1.0/24 -> kazan/94.180.zzz.zzz:33663
Wed Sep 11 18:44:03 2019 kazan/94.180.zzz.zzz:33663 MULTI: Learn: 192.168.1.0/24 -> kazan/94.180.zzz.zzz:33663
Wed Sep 11 18:44:05 2019 kazan/94.180.zzz.zzz:33663 PUSH: Received control message: 'PUSH_REQUEST'
Wed Sep 11 18:44:05 2019 kazan/94.180.zzz.zzz:33663 SENT CONTROL [kazan]: 'PUSH_REPLY,route 192.168.0.0 255.255.255.0,route 10.8.0.1,topology net30,ping 5,ping-restart 30,ifconfig 10.8.0.10 10.8.0.9' (status=1)
Wed Sep 11 18:44:22 2019 MULTI: Learn: 192.168.1.0 -> kazan/94.180.zzz.zzz:33663
Wed Sep 11 18:49:55 2019 MULTI: Learn: 192.168.1.0 -> kazan/94.180.zzz.zzz:33663

[res2001]

MaxxDamage, В клиентском фаерволе не хватает

-A FORWARD -i tun0 -j ACCEPT
-A FORWARD -o tun0 -j ACCEPT

Кстати, добавьте в серверный конфиг openvpn директиву:
topology subnet
Я всегда использую этот режим.
Опция меняет внутреннюю топологию сети ВПН. Используемая по умолчанию топология (net30) сейчас не рекомендуется для использования. Об этом в коментариях к тестовому конфигу написано.
Про разные топологии есть статья на сайте openvpn, там все разжевано.

[MaxxDamage]

res2001,

UPD. Пакеты из сети сервера в сеть клиента идут, всё в порядке. Осталось понять почему не идут пакеты от клиента в сеть сервера.

[res2001]

MaxxDamage, А между клиентом и сервером и обратно пинги идут по внутренним адресам (10.8.0.х)?

[MaxxDamage]

res2001, да, ходят.

[res2001]

MaxxDamage,

Пакеты из сети сервера в сеть клиента идут, всё в порядке. Осталось понять почему не идут пакеты от клиента в сеть сервера.

Включите tcpdump -i tun0 на сервере и пингуйте из сети клиента.
Смотрите в tcpdump доходят ли пакеты до сервера. Если не доходят - переносите tcpdum на клиента.
Так определите где блокируются пакеты.

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

[MaxxDamage]

res2001, шлюз по умолчанию у всех точно нужный, этот параметр остался без изменений.

Вот что показал tcpdump:

spoiler

19:53:56.559212 IP 10.8.0.8.53020 > 192.168.0.127.33504: UDP, length 32
19:53:56.559256 IP 10.8.0.8.51725 > 192.168.0.127.33505: UDP, length 32
19:53:56.559300 IP 10.8.0.8.57276 > 192.168.0.127.33506: UDP, length 32
19:53:56.559343 IP 10.8.0.8.46134 > 192.168.0.127.33507: UDP, length 32
19:53:56.559391 IP 10.8.0.8.41974 > 192.168.0.127.33508: UDP, length 32
19:53:56.559434 IP 10.8.0.8.55115 > 192.168.0.127.33509: UDP, length 32
19:53:56.559481 IP 10.8.0.8.48952 > 192.168.0.127.33510: UDP, length 32
19:53:56.559524 IP 10.8.0.8.47927 > 192.168.0.127.33511: UDP, length 32
19:53:56.559567 IP 10.8.0.8.35681 > 192.168.0.127.33512: UDP, length 32
19:53:56.559612 IP 10.8.0.8.34133 > 192.168.0.127.33513: UDP, length 32

При этом изнутри сети, с сервера, данный адрес пингуется свободно.

[res2001]

MaxxDamage, Вы пингуете или что?
С какого адреса пингуете, какой адрес пингуете?
Если пингуете, то пинги не доходят, должны быть пакеты ICMP echo request, а у вас тут UDP.
Вы добавили правила в клиентский фаер?

-A FORWARD -i tun0 -j ACCEPT
-A FORWARD -o tun0 -j ACCEPT

[MaxxDamage]

res2001,
Пингую, с клиента адрес в сети сервера. UDP потому что я проглядел, и сделал трассировку вместо пинга. Вот пинг:

spoiler

20:09:47.769642 IP 10.8.0.8 > 192.168.0.127: ICMP echo request, id 26874, seq 9, length 64
20:09:48.777724 IP 10.8.0.8 > 192.168.0.127: ICMP echo request, id 26874, seq 10, length 64
20:09:53.817863 IP 10.8.0.8 > 192.168.0.127: ICMP echo request, id 26874, seq 15, length 64
20:10:01.882252 IP 10.8.0.8 > 192.168.0.127: ICMP echo request, id 26874, seq 23, length 64
20:10:02.890207 IP 10.8.0.8 > 192.168.0.127: ICMP echo request, id 26874, seq 24, length 64
20:10:03.898252 IP 10.8.0.8 > 192.168.0.127: ICMP echo request, id 26874, seq 25, length 64

Правила добавил

[res2001]

MaxxDamage,

очему UDP не знаю, мб потому что OpenVPN настроен на использование UDP.

Нет не по этому.
1.OpenVPN использует только один UDP порт, который заранее известен - прописывается в конфиге сервера.
А тут у вас какой-то перебор портов. Видимо они все закрыты, поэтому ответов нет.
Адрес 10.8.0.8 это, видимо, впн клиент, с него что-то пытается просканировать порты сервера.
2.UDP порт открывается на внешнем интерфейсе с внешним адресом, а вы tcpdumpите tun0. В tun0 попадают уже пакеты прошедшие внешний канал и проброшенные openvpn дальше.

В общем рекомендую вам потом найти что у вас на клиенте сканирует порты сервера.

Значит пинги не проходят. Переносите tcpdump на клиент и повторите.

[MaxxDamage]

res2001, дополнил ответ про UDP.

tcpdump, пинг с сервера адреса за клиентом:

spoiler

20:05:00.953404 IP 10.8.0.1 > 192.168.1.105: ICMP echo request, id 2663, seq 4, length 64
20:05:00.953835 IP 192.168.1.105 > 10.8.0.1: ICMP echo reply, id 2663, seq 4, length 64
20:05:01.955323 IP 10.8.0.1 > 192.168.1.105: ICMP echo request, id 2663, seq 5, length 64
20:05:01.955783 IP 192.168.1.105 > 10.8.0.1: ICMP echo reply, id 2663, seq 5, length 64
20:05:02.957156 IP 10.8.0.1 > 192.168.1.105: ICMP echo request, id 2663, seq 6, length 64
20:05:02.957612 IP 192.168.1.105 > 10.8.0.1: ICMP echo reply, id 2663, seq 6, length 64

[res2001]

Пингуйте изнутри сети клиента сеть сервера.

[res2001]

А вы старый впн сервер выключили?

[MaxxDamage]

res2001, а что, нужно на каждом компе сети прописывать маршрут? Но в старой конфигурации такого не было. Были указаны шлюзы по умолчанию и всё.
192.168.0.127 - это комп в сети сервера. Я его и пинговал с клиента. Результат выше.
Пинг изнутри сети клиента компьютера внутри сети сервера:

spoiler

20:26:11.696101 IP 192.168.1.105 > 192.168.0.127: ICMP echo request, id 1, seq 19, length 40
20:26:16.688104 IP 192.168.1.105 > 192.168.0.127: ICMP echo request, id 1, seq 20, length40
20:26:21.695406 IP 192.168.1.105 > 192.168.0.127: ICMP echo request, id 1, seq 21, length 40

[MaxxDamage]

res2001, нет. Но у него другой внешний IP, поэтому клиент к нему не обращается. Новый сервер находится в другой сети.

[res2001]

MaxxDamage, Значит на компах внутри сети сервера шлюзом по умолчанию старый впн сервер?
Поэтому вы ответа и не видите - комп внутри сети сервера получает echo request, а ответ он отправляет на шлюз по умолчанию (на старый впн сервер), потому что он не знает другого маршрута до сети клиента. И там это пакет просто теряется.
Тут возможны варианты:
1.менять шлюз по умолчанию в сети
2.присвоить новому впн серверу внутренний адрес старого впн сервера, тогда он автоматически станет шлюзом по умолчанию для компов сети
3.прописывать маршрут до сети клиента (и сети 10.8.0.0/24) на кождом компе в сети сервера. Это можно сделать через опции DHCP сервера.

[MaxxDamage]

res2001, у старого и у нового шлюза адреса остались те же самые - 192.168.0.1 у серверного и 192.168.1.1 у клиентского. Шлюз и VPN сервер это одна и та же машина. Так же как VPN клиент является ещё и шлюзом в своей сети. Так как у нового шлюза ip адрес внутри своей сети такой же как у старого, менять у машин шлюз по умолчанию не требуется.

По сути сейчас вся загвоздка в том, что почему-то из сети клиента недоступна сеть сервера. Сам шлюз/сервер (192.168.0.1) доступен, а сеть за ним - нет, несмотря на вышеприведённые настройки iptables и вроде бы правильные маршруты.

[res2001]

Проведите еще эксперимент:
tcpdump на клиенте и на сервере, пинг с компа за сервером на комп за клиентом.