В настоящее время у меня есть настройка VPN типа "сеть-сеть", в которой сервер Centos7 настроен как VPN-клиент для туннеля на удаленном сайте. Туннель установлен нормально, и я пытаюсь получить доступ к ресурсам на удаленном сайте через туннель, но пока я не могу пинговать ничего, кроме самого VPN-клиента, ничего за ним.
VPN-клиент удаленного сайта (сервер centos7) может проверять связь и получать доступ к ресурсам, но клиенты за брандмауэром VPN-клиента - нет.
Настроить:
ГЛАВНЫЙ САЙТ: Маршрутизатор / Брандмауэр: 192.168.150.1 (работает брандмауэр openvpn / sophos)
САЙТ КЛИЕНТА: Centos7 Server 192.168.200.1 (адрес eth0) / 192.168.201.1 (адрес tun0)
Клиент на основном сайте (например, 192.168.150.2) может пинговать 192.168.200.1 и 192.168.201.2. а не 192.168.200.50 (ресурс на сайте клиента).
На клиентском сайте у меня есть следующие прямые правила в firewalld:
ipv4 filter FORWARD 0 -i tun0 -o eth0 -p icmp -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
ipv4 filter FORWARD 0 -i eth0 -o tun0 -p icmp -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
В ядре включена пересылка ipv4. Каждый интерфейс находится в своей зоне в firewalld.
Добавление ЭТОГО ПРАВИЛА устраняет проблему, и соединение устанавливается. Но почему? Я не хочу ничего с NAT.
ipv4 nat POSTROUTING 0 -o eth0 -j MASQUERADE
Из полного описания я могу догадаться, что на "основном сайте" все идет хорошо и все необходимые средства маршрутизации настроены правильно. «Проблема», которую я бы увидел на хосте с IP 192.168.200.50 (иначе одного правила MASQUERADE было бы недостаточно).
Такое поведение означает, что как только вы попытаетесь связаться с основным сайтом с 192.168.200.50, он будет правильно маршрутизировать через VPN-туннель на 192.168.201.1, а затем на 192.168.200.50 (вы можете попытаться поймать трафик на 192.168.200.50 и наиболее вероятно вы увидите входящие данные). Проблема с ответом. Узел 192.168.200.50 не знает, как взаимодействовать с 192.168.201.0/x или 192.168.150.0/y. В результате ответ направляется на шлюз по умолчанию и не достигает места назначения ...
С правилом NAT кажется, что трафик исходит из 192.168.200.1, поэтому 192.168.200.50 правильно направляет его обратно в «VPN GW», где он «де-NAT» и правильно отправляет обратно через туннель.
Попробуйте добавить эти правила на 192.168.200.50 (допустим, обе маски / 24):
ip route add 192.168.201.0/24 via 192.168.200.1
ip route add 192.168.150.0/24 via 192.168.200.1
Затем повторите попытку связи без правила MASQUERADE на 192.168.200.1, и я думаю, что это будет работать, как предполагалось. Удачи !
- edit / Сб, 22 июня, 21:09 UTC, 2019 -
В качестве альтернативы вы можете попробовать добавить статический маршрут на GW по умолчанию для 192.168.200.0/24 (поскольку VPN использует .1, GW может быть .254 :)). Тогда он также может работать, поскольку 192.168.200.50 отправит его обратно через стандартный GW, но он отправит его обратно в "VPN GW" ...