Страница 1 из 1

poptop проблема с маской сети

Добавлено: 2007-12-14 8:47:15
klimov
Добрый всем день, решил поднять отдельную тему. Возникла проблема по настройке доступа в корпоративную сеть через vpn. Все настроено как в статье у лисяры и работает нормально, но есть одно но. В локальной сети маска 255.255.255.0, а vpn выдает при подключении к серверу 255.255.255.255. Если кто то знает как побороть эти грабли напишите плиз. В файле /etc/ppp/ppp.conf

Код: Выделить всё

pptp:
enable proxy                  
set dns 192.168.0.208        
set ifaddr 192.168.0.225 192.168.0.225 255.255.255.0     
set timeout 300               
enable MSChapV2
Помогите кто сталкивался, плиз.

Re: poptop проблема с маской сети

Добавлено: 2007-12-14 9:01:45
Alex Keda
кнопачку коде юзать не учили папа с мамой ? :)
=========
это точка-точка... правильная маска

Re: poptop проблема с маской сети

Добавлено: 2007-12-14 9:31:04
klimov
lissyara писал(а):кнопачку коде юзать не учили папа с мамой ? :)
=========
это точка-точка... правильная маска
Тоесть другую маску я не смогу использовать?

Re: poptop проблема с маской сети

Добавлено: 2007-12-14 11:15:46
Alex Keda
ты так и не объяснил зачем

Re: poptop проблема с маской сети

Добавлено: 2007-12-14 11:44:53
klimov
lissyara писал(а):ты так и не объяснил зачем
Объясняю, на freebsd поднял vpn для доступа из инета в локальную сеть( сетевые папки, citrix). Vpn поднялся нормально, адреса при подключении к серваку клиенту выдаются нормально, но на клиенте поднимается подключение с маской отличной от моей локалки куда мне нужен доступ, соответственно ip адреса машин в локалке даже не пингуются-(((((. Может маска тут и не причем, тогда направь куда копать?

Re: poptop проблема с маской сети

Добавлено: 2007-12-14 13:16:38
Alex Keda
маска тут нипричём

Re: poptop проблема с маской сети

Добавлено: 2007-12-14 13:49:05
klimov
lissyara писал(а):маска тут нипричём
Подскажи куда копать тогда?

Re: poptop проблема с маской сети

Добавлено: 2007-12-14 21:43:47
schizoid
маршруты скорее всего.
тспдампом смотри

Re: poptop проблема с маской сети

Добавлено: 2007-12-15 10:26:46
yakuzzza
Как правильно настроить сеть для ВПН раз и навсегда.

Примем условия задачи.
Есть ВПН-сервер с двумя интерфейсами, первый смотрит в мир, второй в сеть предприятия.
На внешнем интерфейсе работает pptpd.
Внутренняя сеть 10.0.0.0/24. В ней размещены серверы. Для каждого сервера шлюз по умолчанию - это внутренний интерфейс шлюза - 10.0.0.1/24.
ВПН-сеть 192.168.200.0/24. На шлюзе поднимаем интерфейс lo1 с ип-адресом 192.168.200.1/24. Почему так, а не повесить алиас на имеющиеся физ. интерфейсы или lo0 - дело вкуса, но так в системе порядок и удобство при жестком фильтровании пакетов. А lo0 он должен заниматься именно своим делом.
Клиентам при подключении выдаются ип-адреса из диапазона 192.168.200.2-100 например. Не обращаем внимания на маску при выдаче ВПН-сервером (помним, что это точка-точка и /32 это нормально).
При подключении через ВПН клиент получает шлюз по умолчанию 192.168.200.1.

Все.
Теперь все должно работать.

Проверка, что и как не работает.

Опускаем настройку включения форвардинга пакетов, настройки интерфейсов, настройки ВПН-сервера, благо здесь все разжевано неодноркатно. Lissyara - респект!

С клиента.
Пингуем реальный ип-адрес шлюза. Должны быть ответы и правильно настроенный маршрутизатор ОБЯЗАН отвечать на ICMP.
Подключаемся к ВПН-серверу. Смотрим ipconfig/all на Windows или ifconfig на Unix.
Должен был выдаться адрес из диапазона 192.168.200.2-100. По netstat -rn Windows и Unix должны показать таблицу маршрутизации и шлюз по умолчанию 192.168.100.1 должен быть. Если нет - проверяем галочку в Windows в свойствах впн-соединения, чтобы стояла напротив Использовать основной шлюз в удаленной сети в свойствах TCP/IP. В Unix крутим ppp/pppd файлы на предмет изменения шлюза по умолчанию при поключении.

Пингуем 192.168.200.1 - наш новый шлюз по умолчанию. Ответы должны идти. Если нет - проверяем на сервере пинги на 192.168.200.1. Если нет - смотрим файрволл (очень распространенная ошибка - забываем добавить разрешения), проверяем конфигурацию lo1.

Пингуем внутренний интерфейс маршрутизатора - это как раз ип-адрес шлюза по умолчанию для серверов 10.0.0.1. Ответы должны идти. Если нет - проверяем включен ли роутинг, разрешено ли файрволлом хождение трафика.

Пингуем нужный сервер. Допустим 10.0.0.2. Ответы должны идти. Если нет - смотрим шлюз по умолчанию на этом сервере (должен быть 10.0.0.1), смотрим файрволл на сервере (разрешение для ВПН-сети), проверяем работу интерфейса на сервере (смотрим настройки TCP/IP, есть ли физ. подключение к сети).

Ну вот, собственно, если кратко, то основные проблемы и причины неработы ВПН и с чем мы можем столкнуться.

Что еще сказать - выделение отдельной подсети проводим аккуратно и стараемся поставить такой диапазон, который не совпадает с внутренней сетью, сетями к которым имеются подключения итд. Например не рекомендую настраивать 192.168.0/24, 192.168.1/24 - они часто используются оборудованием по умолчанию и могут доставить много проблем (свичи, модемы, роутеры), ставим что-то нейтральное, например как в примере.

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

Спасибо за снимание. Если возникли вопросы - обсудим. Это хороший форум и пока (надеюсь и в будущем) красноглазых и падонков нет.

Re: poptop проблема с маской сети

Добавлено: 2007-12-15 21:18:51
Гость
yakuzzza писал(а):Как правильно настроить сеть для ВПН раз и навсегда.

Примем условия задачи.
Есть ВПН-сервер с двумя интерфейсами, первый смотрит в мир, второй в сеть предприятия.
На внешнем интерфейсе работает pptpd.
Внутренняя сеть 10.0.0.0/24. В ней размещены серверы. Для каждого сервера шлюз по умолчанию - это внутренний интерфейс шлюза - 10.0.0.1/24.
ВПН-сеть 192.168.200.0/24. На шлюзе поднимаем интерфейс lo1 с ип-адресом 192.168.200.1/24. Почему так, а не повесить алиас на имеющиеся физ. интерфейсы или lo0 - дело вкуса, но так в системе порядок и удобство при жестком фильтровании пакетов. А lo0 он должен заниматься именно своим делом.
Клиентам при подключении выдаются ип-адреса из диапазона 192.168.200.2-100 например. Не обращаем внимания на маску при выдаче ВПН-сервером (помним, что это точка-точка и /32 это нормально).
При подключении через ВПН клиент получает шлюз по умолчанию 192.168.200.1.

Все.
Теперь все должно работать.

Проверка, что и как не работает.

Опускаем настройку включения форвардинга пакетов, настройки интерфейсов, настройки ВПН-сервера, благо здесь все разжевано неодноркатно. Lissyara - респект!

С клиента.
Пингуем реальный ип-адрес шлюза. Должны быть ответы и правильно настроенный маршрутизатор ОБЯЗАН отвечать на ICMP.
Подключаемся к ВПН-серверу. Смотрим ipconfig/all на Windows или ifconfig на Unix.
Должен был выдаться адрес из диапазона 192.168.200.2-100. По netstat -rn Windows и Unix должны показать таблицу маршрутизации и шлюз по умолчанию 192.168.100.1 должен быть. Если нет - проверяем галочку в Windows в свойствах впн-соединения, чтобы стояла напротив Использовать основной шлюз в удаленной сети в свойствах TCP/IP. В Unix крутим ppp/pppd файлы на предмет изменения шлюза по умолчанию при поключении.

Пингуем 192.168.200.1 - наш новый шлюз по умолчанию. Ответы должны идти. Если нет - проверяем на сервере пинги на 192.168.200.1. Если нет - смотрим файрволл (очень распространенная ошибка - забываем добавить разрешения), проверяем конфигурацию lo1.

Пингуем внутренний интерфейс маршрутизатора - это как раз ип-адрес шлюза по умолчанию для серверов 10.0.0.1. Ответы должны идти. Если нет - проверяем включен ли роутинг, разрешено ли файрволлом хождение трафика.

Пингуем нужный сервер. Допустим 10.0.0.2. Ответы должны идти. Если нет - смотрим шлюз по умолчанию на этом сервере (должен быть 10.0.0.1), смотрим файрволл на сервере (разрешение для ВПН-сети), проверяем работу интерфейса на сервере (смотрим настройки TCP/IP, есть ли физ. подключение к сети).

Ну вот, собственно, если кратко, то основные проблемы и причины неработы ВПН и с чем мы можем столкнуться.

Что еще сказать - выделение отдельной подсети проводим аккуратно и стараемся поставить такой диапазон, который не совпадает с внутренней сетью, сетями к которым имеются подключения итд. Например не рекомендую настраивать 192.168.0/24, 192.168.1/24 - они часто используются оборудованием по умолчанию и могут доставить много проблем (свичи, модемы, роутеры), ставим что-то нейтральное, например как в примере.

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

Спасибо за снимание. Если возникли вопросы - обсудим. Это хороший форум и пока (надеюсь и в будущем) красноглазых и падонков нет.
Огромное тебе спасибо!!!! Тогда возникает вопрос, при создании новой подсети, моя существующая сетьи и ее ресурсы не попадут в нее, так как все ip адреса будут из другого диапазона. В принципе я пробовал выдавать адрес для vpn клиента и из существующей сети, но при подключении пинги на шлюз не идут. В фаере все открыто по статье лиса. В общем уже голову сломал-(((, думаю что что то с маршрутизацией, буду ковырять дальше. Роутинг разрешен.