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.
      Прошу подсказать, возможно ли реализовать подобую схему.



  • @Dm.K:

    Имеется файрволл на 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.

    @Dm.K:

    клиенты получали IP из  сети  WAN по DHCP, от    GW,  либо  заранее проставленный статический.

    Тут ключевое слово "bridge". И OpenVPN можно настроить в режиме этого самого моста, и в настройках DHCP указать диапазон  выдаваемых IP адресов…

    @Dm.K:

    (Для раздельного учета трафика провайдером).

    А может всё проще, опишите полную картину поля боя.



  • Нужно чтобы  мост на файрволле работал как "виртуальный коммутатор", для клиентов из внутренних подсетей, подключенных к    hot spot. Подробнее, в приложенном текстовом файле, не вмещается.

    pfsense_qa1.txt



  • Была приблизительно подобная ситуация провайдер выдавал небольшую белую сеть на 16 IP (статически) с гейтом из этой же сети на WAN.
    Чтобы раздавать инет клиентам и они могли использовать белые ip была задействована схема с proxy-arp.
    На стороне провайдера — маршрутизатор прикидывался всеми клиентскими IP
    На стороне клиентов — прикидывался маршрутизатором провайдера. При этом основная сеть на клиентской сети была серая.
    И еще на интерфейсе клиентов был сделан хак, чтоб пакеты доходили до них — был добавлен gateway, адресом которого являлся сам интерфейс и добавлены маршруты до клиентских белых IP с использованием этого gateway.
    Из проблем в данной схеме была только один раз — у клиентов оказался cisco маршрутизатор, которому очень не нравилась подмена в пакетах ответного IP, но и это решилось какой-то волшебной строчкой которая отключает эту проверку в cisco.
    Сейчас же просто уговорили провайдера перенести белую сеть на наш маршрутизатор, а связь осуществлять через серую сеть.

    Еще из вариантов, если провайдер разрешает вам использовать статические записи на интерфейсе — попробовать для связи с провайдером уменьшить сеть до /30 на WAN, также там включить proxy-arp для всех клиентских IP.
    А на клиентском интерфейсе попробовать раздать уже провайдерскую сеть /24 и не использовать диапазон /30 с WAN интерфейса в ней.
    Правда не знаю разрешит ли pfSense назначить пересекающиеся сети на различных интерфейсах. По сетевой логике в этом нету ничего странного, но кто ж его знает как там у pfSense устроено, ведь не умеет же он без хака маршрутизировать /32 на железных интерфейсах.

    Но лучше всего попытаться договориться с провайдером чтоб перенести белую сеть на вашу сторону.



  • @Dm.K:

    pfsense_qa1.txt

    Всё это, конечно, увлекательно, но что даёт Вам основание полагать будто провайдер считает трафик раздельно?



  • Тех.поддержка провайдера так ответила на вопрос о подключении новых пользователей: "Включите их в коммутатор".  Поскольку в одно здание их собрать невозможно - появляется техническая проблема.  Возможно,  что мост с  сервером OpenVPN,  либо  vpn с мостом  могли бы ее разрешить. Включать по точке доступа в каждый порт коммутатора как-то нерационально.



  • @Dm.K:

    на вопрос о подключении новых пользователей: "Включите их в коммутатор"

    То есть остальное Вы додумали, а проверить страшитесь))


Log in to reply