Используя два маршрутизатора pfSense, я создал VPN с общим ключом между двумя сайтами. Оба роутера - pfSense 1.2.2. Блок pfSense на сайте клиента является маршрутизатором шлюза для этого сайта, но на сайте сервера pfSense НЕ является шлюзом для этой локальной сети. Клиентский сайт подключается к серверному сайту ОК, и я получаю сообщение журнала «Initialization Sequence Completed», указывающее, что соединение установлено успешно.
Затем с клиентского сайта я могу использовать любой компьютер в клиентской локальной сети, чтобы проверить связь с ящиком pfSense на сервере по его адресу локальной сети (и даже настроить его через веб-интерфейс, чтобы VPN работал по крайней мере для этого адреса). Я также могу пинговать оба адреса в диапазоне IP-адресов «IP-интерфейс» (конфигурация клиента) / «Пул адресов» (конфигурация сервера), которые являются одной и той же частной подсетью и НЕ находятся в диапазонах LAN клиента или сервера.
Проблема в том, что я не могу получить доступ к другим IP-адресам в локальной сети серверного сайта. Мне не нужно иметь доступ к машинам в локальной сети клиентского сайта с сервера, но мне нужно иметь возможность получить доступ к большему, чем просто серверу, с клиентского сайта. В настоящее время любой пользователь в клиентской LAN может пинговать до интерфейса LAN сервера, и любой пользователь в клиентской LAN может получать эхо-запрос с самого сервера pfSense, но не с сервера LAN. Я добавил правило any <> any в правила брандмауэра интерфейса LAN на сервере.
Если я захватываю трафик на интерфейсе локальной сети сервера, я вижу пакеты, передаваемые с сайта локальной сети клиента, но если я нюхаю, я не вижу, чтобы эти пакеты попадали в локальную сеть сервера. Как я уже сказал, я добавил правило для интерфейса LAN, чтобы разрешить любой-к-любому, как показано ниже, так что еще мне нужно сделать, чтобы разрешить трафик из туннеля в LAN и наоборот?
Обновить : Я добавил push-маршрут для локальной сети сервера на клиентском pfSense и наоборот. Я также пробовал обновиться до RC pfSense 1.2.3 и добавить интерфейс Opt1, установленный на tun0, а затем добавить разрешающие правила между opt1 и LAN. По-прежнему не повезло.
Обновление 2: Требовалось установить правильную маршрутизацию в локальной сети сервера, как описано в принятом ответе, но я не упомянул, что сервер pfSense / OpenVPN работал как гостевая ОС под KVM, а другая половина проблемы заключалась в том, что переадресация IP-адресов должна была быть включен в /etc/ufw/before.rules операционной системы хоста. Это то, что я получил, если не объяснил установку более подробно.
Вот в чем может быть проблема. Представьте, что у вас есть следующая сеть:
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.1.1.90 должна иметь возможность отвечать, а это означает, что пакеты от нее также должны маршрутизироваться на 10.2.2.2. Внутренний клиент явно имеет ip: 10.1.1.90, маску: 255.255.255.0 и маршрутизатор: 10.1.1.90. Следовательно, пакеты будут маршрутизироваться следующим образом:
Обычно ответные пакеты даже не доходят до VPN. Что ты можешь сделать? Очевидно, что будет работать, это добавить маршрут к внутреннему клиенту для маршрутизации всех пакетов в 10.2.2.2, а не в ящик VPN вместо маршрутизатора, например (ящик Windows):
route add 10.2.2.0 mask 255.255.255.0 10.1.1.2
это решит проблему на уровне одной машины. Ответные пакеты пойдут:
Чтобы решить проблему на уровне сети, вы должны изменить маршрутизатор таким же образом, чтобы перенаправить весь трафик, идущий с 10.2.2.0 на 10.1.1.2. Таким образом пойдет ответный пакет:
Другое решение: сделайте свой VPN-сервер для NAT на интерфейсе 10.1.1.2. Таким образом, для внутренних машин все будет выглядеть так, как будто весь трафик исходит от 10.1.1.2, а ответы будут отправляться на 10.1.1.2. Я бы посоветовал пройти маршрутизацию, так как NAT потребует дополнительных ресурсов на VPN-боксе для отслеживания соединений.
Ты создать правила брандмауэра разрешить трафику течь туда, куда вы хотите?