Вопрос или проблема
У меня есть две сети: 10.8.0.0/24 и 192.168.1.0/24.
У меня есть OpenVPN сервер на Linux с IP 10.8.0.1 и один клиент с IP 10.8.0.2, который имеет интерфейс в сети 192.168.1.0/24. На обеих машинах используется net.ipv4.ip_forward=1.
Интерфейс в сети 10.8.0.0/24 на OpenVPN сервере называется tun0, интерфейс в сети 10.8.0.0/24 на OpenVPN клиенте также называется tun0, а интерфейс в сети 192.168.1.0/24 на OpenVPN клиенте называется ens19.
Когда я добавляю маршрут к 192.168.1.0/24 с командой “ip route add 192.168.1.0/24 via 10.8.0.2” на OpenVPN сервере под управлением Linux, и запускаю “tcpdump -i tun0” на сервере, и пытаюсь сделать пинг 192.168.1.100, который находится в сети 192.168.1.0/24 (с сервера), я вижу следующее в выводе tcpdump: “08:26:50.121070 IP 10.8.0.1 > 192.168.1.100: ICMP echo request, id 27746, seq 1, length 64”, однако, когда я выполняю “tcpdump -i tun0” на стороне клиента, я ничего не вижу.
Если на серверной стороне я вижу, что из tun0 пакеты отправляются туда, почему ничего не видно в выводе tcpdump клиента, указывающего на то, что он что-то получает?
Когда я пингую с сервера клиента, например, делая это: “ping 10.8.0.2”, я вижу это в выводе tcpdump клиента: “08:34:27.681295 IP 10.8.0.1 > 10.8.0.2: ICMP echo request, id 27750, seq 1, length 64”, что означает, что интерфейс действительно работает. Почему же тогда не получаются пакеты, предназначенные для сети 192.168.1.0/24? Где они блокируются и почему?
Кстати, я не хочу делать никакого NAT. Я просто хочу уметь маршрутизировать между двумя сетями, как я могу делать это, когда нет подключения через OpenVPN. Я просто не понимаю, в чем разница.
Здесь также нет правил брандмауэра.
Любая помощь будет очень оценена, это сводит меня с ума.
Вот схема сети:
Вот таблица маршрутизации OpenVPN сервера:
# ip route show
default via 10.1.0.1 dev ens18
10.1.0.0/24 dev ens18 proto kernel scope link src 10.1.0.119
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1
192.168.1.0/24 via 10.8.0.2 dev tun0
Вы можете видеть, что последний маршрут вызывает проблемы. 10.1.0.0/24 – это, очевидно, моя реальная LAN сеть.
Это таблица маршрутизации OpenVPN клиента:
# ip route show
default via 10.1.0.1 dev ens18
10.1.0.0/24 dev ens18 proto kernel scope link src 10.1.0.135
10.1.0.119 via 10.1.0.1 dev ens18
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.2
192.168.1.0/24 dev ens19 proto kernel scope link src 192.168.1.1
И это таблица маршрутизации на ПК в сети 192.168.1.0/24:
# ip route show
default via 192.168.1.1 dev ens18 onlink
192.168.1.0/24 dev ens18 proto kernel scope link src 192.168.1.100
В случае, если кто-то захочет предложить создать маршрут к 10.8.0.0/24 на ПК (вместо машины 10.8.0.1, которая также действует как роутер), это не то, что я хочу (кроме того, что это все равно не сработает), потому что я хочу, чтобы роутер маршрутизировал трафик, а не чтобы конечный ПК знал маршрут сам по себе, что не имело бы особого смысла…
Я уже пробовал установить маршрут как 10.8.0.1, а не 10.8.0.2, но, как и ожидалось, это не работает, потому что тот, кто должен быть непосредственно подключен к 192.168.1.0/24, это 10.8.0.2, а не 10.8.0.1.
Примечания:
10.1.0.0/24 – это моя LAN сеть. Она работает как WAN сеть для OpenVPN сервера, а также для клиента, как вы можете видеть в таблицах маршрутизации.
10.8.0.0/24 – это VPN сеть.
192.168.1.0/24 – это сеть ПК, в которую у меня проблемы попасть с VPN сервера.
Ответ или решение
Конечно, давайте рассмотрим данную ситуацию подробнее.
Теория
Когда мы работаем с маршрутизацией между сетями посредством VPN, в данном случае OpenVPN, крайне важно понимать все компоненты маршрутизации и их взаимодействие. Основополагающий принцип здесь — обеспечить, чтобы пакеты данных могли перемещаться от одной сети к другой через VPN, и наоборот, без нарушения правил сети или ограничений.
Каждое устройство в сети имеет таблицу маршрутизации, которая определяет, каким образом трафик перемещается в сети и за ее пределами. Ваш OpenVPN сервер и клиент находятся в сетях 10.8.0.0/24, а клиент также подключен к сети 192.168.1.0/24. Оба устройства настроены для пересылки IP-пакетов (net.ipv4.ip_forward=1), что является необходимым при маршрутизации за интерфейсом VPN.
Проблема
Вы указали следующую проблему: при попытке маршрутизировать трафик к сети 192.168.1.0/24 через VPN-сервер, вы сталкиваетесь с тем, что пакеты просто не доходят до клиента, несмотря на их видимость в tcpdump на сервере.
Пример
Давайте посмотрим на ваши действия и диаграмму сети более детально:
-
На сервере OpenVPN с IP 10.8.0.1 вы добавили маршрут к сети 192.168.1.0/24 через команду:
ip route add 192.168.1.0/24 via 10.8.0.2Это значит, что всякий раз, когда серверу необходимо отправить пакеты в сеть 192.168.1.0/24, он будет отправлять их через интерфейс tun0 к клиенту 10.8.0.2.
-
Однако, судя по описанию, пакеты не видны на клиентской стороне, несмотря на их отправку из интерфейса tun0 на стороне сервера.
-
Вы используете утилиту
tcpdumpдля захвата пакетов, и на стороне клиента не видите ICMP-запросы к машине с адресом 192.168.1.100, которые должны были бы быть видны, если бы они прошли через VPN-туннель.
Применение
Исходя из вышеизложенного, давайте разберем потенциальные причины этой проблемы и как их можно устранить.
-
Проблемы с маршрутизацией и IP-адресацией: В вашем сценарии маршруты выглядят правильно, однако убедитесь, что конфигурационные файлы OpenVPN позволяют клиенту объявлять маршрут для сети 192.168.1.0/24. В клиентском конфигурационном файле OpenVPN должна быть опция
push "route 192.168.1.0 255.255.255.0". -
Проверка клиентов и сервера на сетевом уровне: Убедитесь, что пакеты от сервера через интерфейс tun0 действительно доходят до клиента. Для этого выполните отладочные команды
tcpdumpна интерфейсе ens19 клиента, чтобы удостовериться, что пакеты по ICMP идут в 192.168.1.0/24 по каналу. -
Проверка сетевых привилегий: Поскольку у вас указано, что файервол отсутствует, важно также проверить, что на всей вашей сетевой инфраструктуре отсутствуют ACL или другие ограничения, которые могли бы блокировать ICMP-запросы или маршрутизацию между subnet’ами.
-
Альтернативные проверки маршрутизации: Попробуйте вместо ICMP использовать другую утилиту или сетевой протокол для тестирования связности, например,
traceroute, чтобы проследить путь пакетов и выявить, где именно они застревают. -
Конфигурация OpenVPN: Пересмотрите конфигурационные файлы OpenVPN на сервере и клиенте. Проверьте директивы: особенно
server,client,client-to-client, которые могут повлиять на маршрутизацию.
Заключение
Проблема, с которой вы сталкиваетесь, связана с тем, что OpenVPN-клиент, по-видимому, не обрабатывает ICMP-запросы, которые пересылаются через туннель. Устранение потенциальных конфликтов в настройках роутинга, конфигурации VPN и сетевых ограничений должно разрешить эту проблему. Важно также помнить, что документация OpenVPN и доступные ресурсы поддержки могут дать дополнительные подсказки и рекомендации для настройки сложных сетевых сценариев.