![]() |
Не могу настроить VPN
Есть одна большая компания с внутренней адресацией 10.0.0.0
Мы являемся ее производственной единицей и отличаемся от остальных единиц тем, что сеть у нас своя. Наши объекты раскиданы по городу и потребовалось подключить их к нашей сети. Связывает нас внутренняя сеть хозяев (10.0.0.0). Выход нашли в VPN. У нас и на одном из объектов установлены VPN роутеры DI-804HV, которые WAN интерфейсом контачат с 10.0.0.0 (тем самым способны видеть друг друга). Со стороны объекта компьютеры подключены к роутеру в LAN интерфейс и имеют адресацию 192.168.214.0 с маской 255.255.255.0 С нашей стороны все сложнее. Сеть у нас 192.168.0.0 с маской 255.255.128.0. В настройках LAN интерфейса роутера нельзя установить маску, отличную от 255.255.255.х, поэтому роутер был подключен к нашему сердцу (серверу AD, DNS, DHCH) на отдельный интерфейс 192.168.201.1 с маской 255.255.255.0 То есть для работы сети нужно 2 туннеля: 1. 192.168.201.0 255.255.255.0 <-10.0.0.0-> 192.168.214.0 255.255.255.0 2. 192.168.0.0 255.255.128.0 <-10.0.0.0-> 192.168.214.0 255.255.255.0 Первый туннель поднялся. То есть на объекте компьютеры имеют доступ к AD. А вот второй туннель не поднимается, а значит к остальным компьютерам сети они доступ не имеют. Соответственно что из нашей сети к ним тоже не достучаться (только напрямую с сервера). Вот с этим я и хочу попросить помощи. Может, я делаю что-то принципиально неправильно. Помогите разобраться. В идеале хотелось бы иметь сквозной доступ, то есть, чтобы на объекте клиенты получали адреса с нашего DHCP, а не с DHCP роутера. Но, что-то мне подсказывает, что это совсем недостижимо. |
Цитата:
Там поля для ввода масок открыты и в настройках локсети и в настройках VPN. А адреса для подсети должны быть свои локальные. Или можно их статическими сделать или поставить другую железку(помимо 804) раздающую DHCP в подсеть. |
Цитата:
Цитата:
Цитата:
|
Цитата:
Цитата:
А на странице настроек VPN должны фигурировать обе разные подсети, которые Remote и Local там называются. Настройки Remote и Local не одинаковые. |
Цитата:
VPN соединяет 2 локальные подсети, соответствующие LAN подсетям роутеров. То есть если на роутере 1 подсеть 192.168.201.0 а на другом 192.168.214.0, то эти 2 подсети и будут соединяться туннелем. Если на одной стороне маршрутизацией к роутеру подвести еще одну подсеть, например 192.168.203.1, то можно будет поднять еще один туннель для этой подсети тоже. Я это уже делал. Но сейчас все поменялось, пришлось переделывать. И я не могу повторить это снова. |
Цитата:
По тому, как Вы описали и по Вашему факту предыдущей работы можно заключить, что а)настройки vpn у Вас в роутере нормальные, если Вы их не трогали. б)дело только в настройке маршрутизации второй подсети на этот роутер. А какими средствами Вы раньше эту маршрутизацию настраивали? Я не знал, что на DI-804HV могут сосуществовать 2 локальные подсети. На другом конце канала что за роутер используется? |
Трогал настройки. Структуру сети я кратко описал в первом сообщении.
Раньше было так: Сервер AD, DNS, DHCP имел 3 интерфейса: 1. 200.200.201.1 (к этому интерфейсу был подключен DI-804HV и имел адрес 200.200.201.3) 2. 200.200.202.1 (это основная подсеть организации. В этой подсети все клиентские компы, принтеры, другие серверы и тд) 3. 200.200.203.1 (этот интерфейс напрямую соединен с прокси сервером (на нем же файрвол и NAT)) На другом конце ВПН роутер имел адрес 200.200.214.1. Так вот DI-804HV держали 3 тоннеля: 200.200.114.0 <--> 200.200.201.0 200.200.114.0 <--> 200.200.202.0 200.200.114.0 <--> 200.200.203.0 с нашей стороны на роутере была маршрутизация 200.200.202.0 --> 200.200.201.1 200.200.203.0 --> 200.200.201.1 На сервере была маршрутизация: 200.200.114.0 --> 200.200.201.1 (то есть на интерфейс с маршрутизатором ВПН) Все работало гладко. Структура сети была сделана задолго до меня, ВПН я поднял лично. Но как думаете, что мне не понравилось в этой структуре? Правильно, адресация! Ну не должна внутренняя сеть иметь адреса из белого диапазона, как-то это не правильно :) И вот я решил все переделать на 192.168.0.0 255.255.128.0 расширив за одно диапазон. Теперь картина такая. Сервер имеет уже 4 интерфейса: 192.168.1.1 255.255.128.0 (основной интерфейс для всех клиентских компов, устройств и тд) 192.168.203.1 255.255.255.0 (связь с проксиком. Собственно как прокси он уже не работает, но выход во внешку и сеть корпорации до сих пор через него) 192.168.201.1 255.255.255.0 (сюда подключен роутер ВПНа) 200.200.202.1 255.255.255.0 (все еще в работе, тк реорганизация не закончена и часть клиентов и серверов до сих пор в этой подсети) Соответственно в ВПНах я удалил 2 туннеля, а третий переписал из 200.200.114.0 <--> 200.200.201.0 в 192.168.214.0 <--> 192.168.201.0 Туннель поднялся, на той стороне виден сервер AD, но этого мало. Надо еще иметь связь с подсетью 192.168.0.0 255.255.128.0 Поэтому я создал туннель 192.168.214.0 255.255.255.0 <--> 192.168.0.0 255.255.128.0 на сервере прописал маршрут 192.168.214.0 --> 192.168.201.1 (то есть отправил на роутер) на роутере с нашей стороны прописал маршрут 192.168.0.0 255.255.128.0 --> 192.168.201.1 (то есть связал роутер с подсетью 192.168.0.0) С роутера отлично идет пинг до 192.168.1.1 Но туннель не поднимается. Я решил, что возможно происходит путаница с подсетями, ведь 192.168.214.0 так же подошла бы к маске 255.255.128.0. По старой памяти попробовать связать 192.168.214.0 и 192.168.203.0 (см интерфейсы сервера) Но даже этот туннель не поднимается. Причем настройки туннелей идентичны с настройками работающего туннеля (за исключением адресации, конечно). короче я запутался уже. |
Неужели никто не поможет?
|
Может дело в шифровании? У меня тоже туннель не поднимался, потом увидел что на стороне клиента и сервера стоят разные шифрования. Тоже как и в вашем случае у меня пинг проходил нормально, но тунель не поднимался. Проверьте еще раз настройки детально, может где то пропустили. Тут особо никаких настроек и нету.
|
На 50 раз уже все перепроверил.
Настройки IPSec porposal и IKE porposal берутся из таблицы, и, учитывая, что один туннель поднимается, настройки идентичны. Preshare key тоже проверял. |
Время: 20:16. |
Время: 20:16.
© OSzone.net 2001-