подскажите плз, есть лок.сеть там установлен dfl-100 пытаюсь настроить pptp vpn подключение к лок.сети из дома, проверку пользывателя прохожу все нормально, но не вижу компы лок.сети.
ipconfig показывает маску на vpn подключении 255.255.255.255, а в лок.сети 255.255.255.0 в настройках dfl-100 все впорядке. Как сделать чтобы маска присваивалась как в лок.сети

а как быть, надо чтобы сотрудники из дома подключались к оффисной лок.сети

Если вы дома выходите в интернет через впн, то ВПН в офисную сеть будет соединяться, но сама сеть будет недоступна. Получится 2 конкурентных маршрута с метрикой 1.
Вариант- использовать ethernet модем с функцией ZIPB или NAT, например если выходите через кабельный/дсл модем. ну и т.п. Тоесть надо знать точный способ вашего выхода в интернет. А входящие PPTP DFL-100 еще как поддерживает. Я сам таким образом в сетку одной компании вхожу. Все работает.
А маска такой и должна быть. Интерфейс как бы сам для себя является шлюзом. Для ВПН это нормальное дело.

(лирическое отступление)К сожалению в ДЛинке это не очень понимают и как результат: DFL-100 не может принять такую конфигурацию на WAN интерфейс от DHCP дсл модема в режиме ZIPB, приходится модем делать мостом и соединять впн непосредственно с DFL-100.

Проблемы с маршрутизацией при подключении ВПН через ВПН -- проблемы реализации конкретного IP-стека. По стандарту стеком при принятии решения о маршрутизации пакета сначала просматриваются маршруты с более длинными префиксами, а потом уже с длинными, так что наличие маршрута на конкретную сеть и на интернет (default) друг другу мешать не должны.
А вот про проблемы с DHCP расскажите пожалуйста поподробнее. Можно сразу мне в почту.

_________________
С уважением -- Александр Шебаронин.

Да собственно здесь опишу проблему. В принципе я ее уже описывал даже.
Суть заключается в том, что при подключении впн соединения часто назначаются настройки, где IP, назначенный хосту, является и IP гейта. Выглядит так:

IP-адрес . . . . . . . . . . . . : 81.195.24.223
Маска подсети . . . . . . . . . . : 255.255.255.255
Основной шлюз . . . . . . . . . . : 81.195.24.223

Так вот когда кабельный модем работает в так-называемом ZIPB режиме, то соответственно выдает эти настройки через ethernet подключенному к нему устройству. Если это компьютер, то настройки легко подхватываются и все работает. Если же это WAN выход вашего файрволла, в моем случае DFL-100, то выхода в инет при таких настройках не будет, глядим в статус девайса и видим:

IP-адрес . . . . . . . . . . . . : 81.195.24.223
Маска подсети . . . . . . . . . . : 255.255.255.255
Основной шлюз . . . . . . . . . . : 0.0.0.0

Разбираемся дальше и пытаемся ввести эти же настройки вручную, при в вводе гейта 81.195.24.223 он ругается на недопустимый адрес и изменений в это поле не происходит, тоесть по логике ПО файрволла гейтом может быть любой IP, но только не идентичный полученному адресу.

Вот и получается, что единственный вариант, когда работает схема: линия -- модем -- файрволл -- сетка
это когда модем работает в режиме bridge а VPN с ISP устанавливает непосредственно файрволл.

Хочу заметить еще один недостаток. Когда адрес получает компьютер, то к интерфейсу привязываются как бы 2 адреса а именно 192.168.0.1 и собсно выданный модему провайдером 81.195.24.223. Таким образом мы не теряем возможности обращаться к веб интерфейсу модема и его конфигурить, проверять статус и т.п. У ваших файрволлов такой возможности нет и маршрутизить пакеты в подсеть 192.168.0.X он не будет со всеми вытекающими... ТОесть конфигурить модем мы не сможем, получается неприятная вещь. Хотя эту фичу можно было бы без затруднений реализовать в ПО. Хотябы даже сделать вручную настраиваемую доп. подсеть на WAN интерфейс, чтобы с дхцп клиентом не особо заморачиваться. Ну и соотв-но маршрутизацию в сию подсеть.
Но это все утопия, правда ведь?

Данное устройство не поддерживает несколько адресов на внешнем интерфейсе. А по роутингу -- действительно единственный путь это устанавливать соединение непосредственно с файрволла.

_________________
С уважением -- Александр Шебаронин.

Спрашивали только ради того чтобы подтвердить то, что я и так знаю?
Вот если бы вы по замечаниям вносили поправки в ПО, цены бы вам не было.

а мы и так их вносим - по мере возможности и степени разумности.

_________________
С уважением, Карагезов Владислав

Может тогда внесете в ПО DFL-100 фичу: Reconnect on PPPoE failure. или режим Persistent connection, чтобы железяка постоянно посылала запросы на подключение, если PPPoE не подключен ???
Суть в том, что есть задача держать железяку подключенной постоянно, но проблема в том, что бывают случаи когда ВПН c провайдером рвется и при этом железяка даже и не думает его восстанавливать. Connect on demand будучи включенным почему-то тоже не устанавливает связь по требованию, при попытке обращения к какому-либо сайту например.

Функция мониторинга канала добавлена не будет. Извините...

_________________
С уважением -- Александр Шебаронин.

Извиняю, хотя при чем тут мониторинг. Только скажите плз, неужели Connect on demand не означает то, что железяка должна соединиться с ISP по требованию клиентской машинки? Вроде бы название опции говорит само за себя. И потом выдержка из мануалки: Connect on Demand - allows the PPPoE WAN connection to be active only when a computer on your LAN makes a connection request. This is similar
to the way a dial-up modem initiates a connection.
Я пробовал включать сию опцию. Не соединяется железка с провайдером, если я пытаюсь на любой из машин открыть скажем яндекс или пропинговать его. Железяка не выполняет заявленных функций.
И потом не думаю, что сложно реализовать функцию, которая инициирует коннекшн если состояние PPPoE - Not Connected. Так же не думаю что это так уж нецелесообразно.

у меня рррое подключение - все работает

_________________
Даешь связистов без брака!
AB4790-RIPE

Что работает? Connect on demand? Железяка сама соединяется с провайдером?

да

_________________
Даешь связистов без брака!
AB4790-RIPE

да

_________________
Даешь связистов без брака!
AB4790-RIPE