IP из WAN на клиенте OpenVPN
-
Имеется файрволл на pfsense c тремя интерфейсами, условно:
em0 - 16.247.131.250/24 WAN; gateway,dhcp, 16.247.131.1;
xl0 192.168.0.1/24 - LAN административный ;
em1 - OPT1 для подключения клиентов - пользователей интернет из сети 172.17.0.0/24.
Требуется реализовать, чтобы подключаясь к pfsense, например с помощью включенного на файрволле OpenVPN
клиенты получали IP из сети WAN по DHCP, от GW, либо заранее проставленный статический. (Для раздельного учета трафика провайдером).
В faq есть пример: "Single OpenVPNserver go a long way", он не совсем подходит.В этом примере Адреса клиентам раздаются из заранее установленного установленного не пересекающегося с другими сетями диапазона адресов. Провайдер требует свой диапазон из сети: 16.247.131.0/24.
Прошу подсказать, возможно ли реализовать подобую схему. -
Имеется файрволл на pfsense c тремя интерфейсами, условно:
em0 - 16.247.131.250/24 WAN; gateway,dhcp, 16.247.131.1;
xl0 192.168.0.1/24 - LAN административный ;
em1 - OPT1 для подключения клиентов - пользователей интернет из сети 172.17.0.0/24.
Требуется реализовать, чтобы подключаясь к pfsense, например с помощью включенного на файрволле OpenVPN??? ??? ??? По видимому OPT1 – это небезопасная локальная сеть поверх которой работает VPN.
клиенты получали IP из сети WAN по DHCP, от GW, либо заранее проставленный статический.
Тут ключевое слово "bridge". И OpenVPN можно настроить в режиме этого самого моста, и в настройках DHCP указать диапазон выдаваемых IP адресов…
(Для раздельного учета трафика провайдером).
А может всё проще, опишите полную картину поля боя.
-
Нужно чтобы мост на файрволле работал как "виртуальный коммутатор", для клиентов из внутренних подсетей, подключенных к hot spot. Подробнее, в приложенном текстовом файле, не вмещается.
-
Была приблизительно подобная ситуация провайдер выдавал небольшую белую сеть на 16 IP (статически) с гейтом из этой же сети на WAN.
Чтобы раздавать инет клиентам и они могли использовать белые ip была задействована схема с proxy-arp.
На стороне провайдера — маршрутизатор прикидывался всеми клиентскими IP
На стороне клиентов — прикидывался маршрутизатором провайдера. При этом основная сеть на клиентской сети была серая.
И еще на интерфейсе клиентов был сделан хак, чтоб пакеты доходили до них — был добавлен gateway, адресом которого являлся сам интерфейс и добавлены маршруты до клиентских белых IP с использованием этого gateway.
Из проблем в данной схеме была только один раз — у клиентов оказался cisco маршрутизатор, которому очень не нравилась подмена в пакетах ответного IP, но и это решилось какой-то волшебной строчкой которая отключает эту проверку в cisco.
Сейчас же просто уговорили провайдера перенести белую сеть на наш маршрутизатор, а связь осуществлять через серую сеть.Еще из вариантов, если провайдер разрешает вам использовать статические записи на интерфейсе — попробовать для связи с провайдером уменьшить сеть до /30 на WAN, также там включить proxy-arp для всех клиентских IP.
А на клиентском интерфейсе попробовать раздать уже провайдерскую сеть /24 и не использовать диапазон /30 с WAN интерфейса в ней.
Правда не знаю разрешит ли pfSense назначить пересекающиеся сети на различных интерфейсах. По сетевой логике в этом нету ничего странного, но кто ж его знает как там у pfSense устроено, ведь не умеет же он без хака маршрутизировать /32 на железных интерфейсах.Но лучше всего попытаться договориться с провайдером чтоб перенести белую сеть на вашу сторону.
-
pfsense_qa1.txt
Всё это, конечно, увлекательно, но что даёт Вам основание полагать будто провайдер считает трафик раздельно?
-
Тех.поддержка провайдера так ответила на вопрос о подключении новых пользователей: "Включите их в коммутатор". Поскольку в одно здание их собрать невозможно - появляется техническая проблема. Возможно, что мост с сервером OpenVPN, либо vpn с мостом могли бы ее разрешить. Включать по точке доступа в каждый порт коммутатора как-то нерационально.
-
на вопрос о подключении новых пользователей: "Включите их в коммутатор"
То есть остальное Вы додумали, а проверить страшитесь))