Доброго времени суток, уважаемые специалисты по связи )))

Ворпос стоит срочно и остро. Вот моя проблема

Поднял PPTP сервер на WinServer2008, настроил роутер (dir100) в качестве клиента. К LAN роутера подсоединил контроллер ПЛК304. Все друг друга видят (пинг), кроме сервер контроллера. На роутере настроил переброс портов из WAN в LAN на IP контроллера, диапазон портов 1-65535, и ТСР и UDP. В итоге получается зайти на web-интерфейс контроллера с сервера, но из кодесиса(v3.4) не получается ничего. Сканирование сети не дает результата. GateWay в той же подсети, что и VPNклиенты. Как мне достучаться до контроллера?

Для справки: плк304 - промышленный контроллер(есть ethernet) общается по UDP:1740, кодесис - среда разработки приложений для него, GateWay - сервер для контроллера. SP Win - приложение, эмулятор контроллера.

Сервер свободно виден из интернета.
PPTP сервер имеет адрес 192.168.84.1
На домашнем ПК две сетевухи net1(Подключена к локальной сети провайдера, интернет через рррое; на рррое соединении открыт доступ в инет для net2) и net2(когда расшарил рррое, для net2 был назначен 192.168.137.1 и она(сетевуха) без проблем раздает IP всем кто подключается к ней)

Схема1:
К net2 подсоединяю ноутбук. Создаю PPTP подключение к серверу средсвами виндовс, подключаюсь. Ноутбуку назначается адрес 192.168.84.2. На сервере создаю GateWay 192.168.84.1 и пытаюсь подключиться к SP Win на ноутбуке (указываю адрес кодесис: 2). Все проходит нормально. В снифере видно как они обмениваются по UDP.

Схема2:
Ставлю между ноутбуком и 2ой сетевухой роутер. Роутер подсоединяется к серверу. ВАНу роутера назначается адрес 192.168.84.2, ВПН есть. У ЛАНа 192.168.0.1, ноутбуку назначается адрес 192.168.0.2 и шлюз 192.168.0.1. Теперь пытаюсь подключиться к SP Win как и в первом случае. Ничего не получается.

В роутере настроен переброс всех портов и DMZ - 192.168.0.2. ВАНу клонирован мак адрес ноутбука, пробовал не клонировать.



мак f0:7d:68:4f:10:c0 - походу ЛАН порт роутера.
00:22:15:8d:21:56 - ноутбук

В снифере видно примерно так:
№1 UDP 192.168.84.1:1740 (f0:7d:68:4f:10:c0) -> 192.168.0.2 :1740 (00:22:15:8d:21:56) данные 32 байта
№2 UDP 192.168.0.2 :1740 (00:22:15:8d:21:56) -> 192.168.0.1 :1740 (f0:7d:68:4f:10:c0) данные 36 байт
№3 ICMP 192.168.0.1 -> 192.168.0.2 Destination unreachable (Port unreachable)

Так повторяется несколько раз. До сервера ответы не доходят.

Прошу обратить внимание, что одиночные датаграммы проходят в обоих направлениях и обратить внимание на мак адреса

Возможно мне следует использовать другое оборудование и какой VPN поднимать?

Какая прошивка используется на роутере?

_________________
Форум не подразумевает под собой быстрый ответ, хотите быстрый и квалифицированный ответ - звоните в техподдержку компании D-Link 8-800-700-5465

v2.03 с фтп

Что-то такое подозрение, что ваш "Эмулятор контроллера" пытается по МАКу определить IP. Во втором случае, естественно, обламывается, так как хосты находятся в разных сетях. Нельзя ему этот IP где-то в настройках явно задать?

Видимо так и есть. У эмулятора контроллера вообще нет никаких настроек, для него, скорей всего, настройками служат настройки сетевой карты, через которую он общается. На реальном контроллере настраивается DHCP[да/нет] - у меня нет. ip - 192.168.0.101/24 шлюз - 192.168.0.1 и днс. Я попробовал предыдущую версию среды разработки(2.3), там общение между сервером контроллера и самим контроллером идет по tcp - без проблем. Но эта версия подходит для другой линейки контроллеров. У меня осталось 2 вопроса, это вообще правильно, что что эмулятор, что реальный контроллер пытаются определить IP по МАКу? И другой вопрос подойдет ли мне какое-то другое оборудование dlink, способное преодолеть эту задачу, без использования vpn сеть-сеть?

Попробуйте на компьютере, где запускаете эмулятор, перед его запуском из командной строки сделать команду
arp -s 192.168.84.1 F0-7D-68-4F-10-C0
Это называется статический ARP. Возможно, проканает. Если в arp кэше уже будет статическая запись об этом МАКе, может, эмулятор ей и удовлетворится

Сделал, как Вы сказали. Посмотрел через -а у меня теперь две записи статическая как сказали, и динамическая на IP LANa роутера. Результата нет. В любом случае реальный контроллер врядли имеет такие продвинутые настройки без изменений в прошивке, а он конечная цель. А как с моими вопросами?

Даже не знаю, возможно ли вообще с любым сетевым оборудованием решить эту проблему. Это недостаток контроллера и эмулятора.

Мне кажется, стоит копать в сторону статического arp. Сделайте сначала
arp -d *
Проверьте, что все удалилось, командой
arp -a
потом
arp -s 192.168.84.1 F0-7D-68-4F-10-C0
Тогда эта запись гарантированно будет первой.

Перед добавлением записи я отсоединил сетевой провод и подождал, выполнил -а, записей не было. добавил, как Вы посоветовали, но все равно трафик направляется не туда.

Очень жаль. Посмотрим, может, еще кто-то что-то посоветует.

Похоже дело в прошивке. Сам мучаюсь с dir-100.
Как вариант попробуй последнюю прошивку tripple play, в этом случае контроллер подключай к портам nat (3 и 4). В параметрах выставляй dmz и vpn path through (pptp).
Кстати так и не нашел в прошивке роутера опцию vpn path through, хотя в прошивке трипл плэй она есть. Вообще эта опция есть в прошивке роутера? И если есть, то как ее можно включить?

Дело не в прошивке, а нестандартной реализации TCP/IP контроллера и эмулятора.
В чем заключается ваша проблема с прошивкой?
VPN Path-throught на прошивке router включен по умолчанию.

_________________
Форум не подразумевает под собой быстрый ответ, хотите быстрый и квалифицированный ответ - звоните в техподдержку компании D-Link 8-800-700-5465

1) Внимание: сетвая 2 на компе, прописан ли там основной шлюз? Просто при обратном маршруте по VPN он может ответить не туда, я думаю, что дело возможно в таблице маршрутов DIR, но очень маловероятно. 2) Существует ли сеть 192.160.0.х в локальной сети 2008 сервера? Попробуйте изменить локальную подсеть на DIR, скажем на 192.168.10.х или 10.0.0.х к примеру..

Считаю, что дело далеко не в прошивке роутера, ибо с GRE у них всегда все нормально было (за исключением большой нагрузки на роутер - более 5 туннелей сквозь него). Да и настрройки верные. Тут уже важна может быть сама таблица маршрутов 2008 сервака. Потому что увидев 192.168.0.х у клиента (распаковав NAT IP пакет), он может не правильно отреагировать в некоторых случаях, скажем, выплюнуть ответ на локальный интерфейс, если там содержится сеть 192.168.0.х, то есть в его таблце маршрутов может быть другая информация о данной сети с наименьшей метрикой...

З.Ы. arp тут тоже не при чем =) все должно быть просто.

_________________
DGS-1224T, 2 x DES-3226S, DES-3828, DAS-3216, 2 x DAS-3224B, 2 x DAS-3224/E/C, DFL-210, DMC-920R+T

aepot, вы не поняли суть задачи. Человеку не нужен VPN Pass-through. Наоборот, он хочет, чтобы по VPN подключался сам роутер, а дальше работает проброс всех портов на нужный компьютер, так как его адрес в DMZ. В результате VPN сервер не видит подсеть 192.168.0.0, а видит только адрес 192.168.84.2 (это WAN интерфейс роутера). Все, что за ним, скрывает NAT.

Проблема в том, что контроллер (или его эмулятор), видя, что исходный пакет приходит с адреса 192.168.84.1, тем не менее отправляет ответный на адрес 192.168.0.1. Почему? Потому что он пытается ip адрес, с которым будет обмениваться данными, определить по MAC адресу отправителя, а тот, естественно, равен MAC адресу LAN интерфейса роутера. То есть контроллер и эмулятор построены таким образом, что могут работать только в пределах одной ip подсети без маршрутизации.

Теперь вопрос в том, можно ли обойти это ограничение средствами сетевого оборудования, и если да, то как.

То есть, используется какой-то хитрый, не обычный впн?

_________________
DGS-1224T, 2 x DES-3226S, DES-3828, DAS-3216, 2 x DAS-3224B, 2 x DAS-3224/E/C, DFL-210, DMC-920R+T