VPN-соединение pfSense Site-to-Site с OpenVPN подключается, но не маршрутизирует трафик
Используя два маршрутизатора pfSense, я создал VPN с общим ключом для двух сайтов. Оба маршрутизатора являются pfSense 1.2.2. Поле pfSense на сайте клиента является маршрутизатором шлюза для этого сайта, но на сайте сервера pfSense НЕ является шлюзом для этой локальной сети. Сайт клиента подключается к сайту сервера, и я получаю сообщение журнала "Инициализация последовательности завершена", указывающее на успешное подключение.
С клиентского сайта я могу затем использовать любой компьютер в клиентской локальной сети для проверки связи с pfSense на серверном сайте по его локальному адресу (и даже настроить его через веб-интерфейс, чтобы VPN работал по крайней мере для этого адреса). Я также могу пропинговать оба адреса в диапазоне IP-адресов "Интерфейс IP" (конфигурация клиента)/"Пул адресов" (конфигурация сервера), которые являются одной и той же частной подсетью и НЕ находятся ни в диапазонах локальной сети ни клиента, ни сервера.
Проблема в том, что я не могу получить доступ к другим IP-адресам в локальной сети сайта сервера. Мне не нужно иметь доступ к компьютерам в локальной сети клиентского сайта с сайта сервера, но мне нужно иметь возможность получать доступ не только к серверу с клиентского сайта. В настоящее время любой пользователь в локальной сети клиента может пропинговать интерфейс локальной сети сервера, а любой пользователь в локальной сети клиента может пропинговать сам сервер pfSense, но не доступ к локальной сети сервера. Я добавил любое <> любое правило в правила брандмауэра интерфейса LAN на сервере.
Если я собираю трафик на интерфейсе локальной сети сервера, я вижу пакеты, переданные с клиентского сайта локальной сети, но если я перехватываю сообщения, я не вижу, как эти пакеты попадают в локальную сеть сервера. Как я уже сказал, я добавил правило для интерфейса локальной сети, чтобы разрешить любое к любому, как показано ниже, так что еще мне нужно сделать, чтобы разрешить трафик из туннеля в локальную сеть и наоборот?
Обновление: я добавил push-маршрут для локальной сети сервера на клиенте pfSense и наоборот. Я также попытался обновить RC контроллера pfSense 1.2.3 и добавить интерфейс Opt1, настроенный на tun0, а затем добавить правила разрешения между opt1 и LAN. Все еще не повезло.
Обновление 2: необходимо было настроить правильную маршрутизацию в локальной сети сервера, как описано в принятом ответе, но я не упомянул, что сервер pfSense/OpenVPN работал в качестве гостевой ОС под KVM, а другая половина проблемы заключалась в том, что переадресация IP необходимо включить в /etc/ufw/before.rules хост-системы. Вот что я получаю за то, что не объясняю настройку более подробно.
2 ответа
Вот что может быть проблемой. Представьте, что у вас есть следующая сеть:
address pool: 10.1.1.0/255.255.255.0
router: 10.1.1.1
internal interface on internal vpn server: 10.1.1.2
some external machine that VPNs to network: 10.2.2.2
some internal client machine: 10.1.1.90
Когда вы пытаетесь получить доступ к SIC из внешнего блока VPN, маршрут трафика выглядит следующим образом:
- 10.2.2.2
- vpn (интернет)
- 10.1.1.2
- 10.1.1.90
- Хорошо
Кажется, нормально, ОДНАКО для того, чтобы трафик передавался, машина 10.1.1.90 должна иметь возможность отвечать, а это означает, что пакеты от нее должны быть также маршрутизируемыми до 10.2.2.2. Внутренний клиент имеет явно ip: 10.1.1.90, маску: 255.255.255.0 и маршрутизатор: 10.1.1.90. Следовательно, пакеты будут маршрутизироваться следующим образом:
- 10.1.1.90
- 10.1.1.1 (так как это маршрутизатор, а 10.2.2.2 не адресуется напрямую)
- интернет
- НЕ НАЙДЕНО
По сути, ответные пакеты не доходят даже до VPN. Что ты можешь сделать? Очевидно, что будет работать добавление маршрута к внутреннему клиенту для маршрутизации всех пакетов на 10.2.2.2, а не на VPN-блок вместо маршрутизатора, такого как (Windows-бокс):
route add 10.2.2.0 mask 255.255.255.0 10.1.1.2
это решит проблему на уровне одного компьютера. Ответные пакеты будут отправлены:
- 10.1.1.90
- 10.1.1.2 (явный маршрут)
- vpn (интернет)
- 10.2.2.2
Чтобы решить проблему на сетевом уровне, необходимо изменить маршрутизатор в том же ключе, чтобы перенаправить весь трафик с 10.2.2.0 на 10.1.1.2. Таким образом ответный пакет будет идти:
- 10.1.1.90
- 10.1.1.1
- 10.1.1.2
- vpn (интернет)
- 10.2.2.2
Другое решение: сделайте ваш VPN-блок для NAT на интерфейсе 10.1.1.2. Таким образом, для внутренних машин это будет выглядеть так, как если бы весь трафик исходил из 10.1.1.2, а ответы перейдут к 10.1.1.2. Я бы посоветовал пройти через маршрутизацию, так как NAT потребует дополнительных ресурсов на коробке VPN для трекера соединения
Вы создали правила брандмауэра, чтобы трафик проходил туда, куда вы хотите?