Почему необходимо это правило MASQUERADE?
В настоящее время у меня есть настройка VPN типа «сеть-сеть», в которой сервер Centos7 настроен как клиент VPN для туннеля на удаленном сайте. Туннель установлен нормально, и я пытаюсь получить доступ к ресурсам на удаленном сайте через туннель, но пока я не могу пинговать ничего, кроме самого VPN-клиента, ничего за ним.
VPN-клиент удаленного сайта (сервер centos7) может проверять связь и получать доступ к ресурсам, но клиенты за брандмауэром VPN-клиента - нет.
Настройка:
ГЛАВНЫЙ САЙТ: Маршрутизатор / брандмауэр: 192.168.150.1 (работает брандмауэр openvpn / sophos)
САЙТ КЛИЕНТА: Сервер Centos7 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", где он "de-NATed" и правильно отправляет обратно через туннель.
Попробуйте добавить эти правила на 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, и я думаю, что оно будет работать, как предполагалось. Удачи!
-- редактирование / Sat Jun 22 21:09 UTC 2019 --
В качестве альтернативы вы можете попробовать добавить статический маршрут на GW по умолчанию для 192.168.200.0/24 (так как VPN использует .1, GW может быть .254 :) ). Тогда он может также работать, так как 192.168.200.50 отправит его обратно нормально через GW по умолчанию, но он отправит его обратно в "VPN GW"...
.