Pptp + route or dhcp

k0st1an

Клиенты находятся за пределами сети. Подключаются по PPTP во внутреннюю сеть (192.168.40.0/22) и должны видеть все ресурсы сети. Пользователям не надо выходить в инет через это соединение, это они будут делать через своего провайдера. Это критично.

Можно еще задать вот так:

И чать сети будет видна:

192.168.42.0 255.255.255.0 192.168.42.52 192.168.42.52

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

PS

werter

Но остальная часть видна не будет и это то и есть проблема.

Так не видна или не будет видна ? Уже пробовали ?

P.s. И верните другую адресацию для пптп-клиентов. А то ненароком прийдется правила рисовать в fw или алиас для них добавлять, а то ведь в инет полезут. Да и удобнее-нагляднее с другой адресацией.

k0st1an

Если использовать 42.0 сеть, то будет доступна часть сети, как раз 42.0. Ну а пользователи из сети 40.0 доступны не будут. А все потому что по умолчанию добавляется маршрут на клиенте с мастой /24, моя же сеть с маской /22.

Поменял на другую сеть (server 172.16.0.1, range 172.16.0.2). Когда подключаюсь к сереру мне выдается вот это в роутинг:

Destination Gateway Flags Refs Use Netif Expire
default 172.16.0.1 UGSc 3 1 ppp0
172.16 ppp0 USc 1 0 ppp0
172.16.0.1 172.16.0.2 UH 5 0 ppp0

То есть о сети 192.168.40.0/22 мой копм ничего не знает. Мне то как раз и надо добится чтоб эта сеть стала доступна. Причем без вмешательства пользователей. Для них должно быть все прозрачно. Такое возможно?

update:
Блин, я совсем забыл об маршрутах на конечных станциях. Поправил (в маштабах организации добавленик маршрута можно решить средствами dhcp). Но проблема все же остается: как добавить клиенту маршрут:

route add 192.168.40.0/22 172.16.0.1

И избавить его постоянно добавлять этот маршрут при подключении.

werter

Ну так вы маршруты на pf смотрите. А он является сервером. С чего им там быть ? У меня тоже нет маршрутов при поднятие туннеля клиентом извне. Но это не мешает клиентам (после правил в fw), ходить не только в мою часть сети ,но и за ее пределы (сеть очччень большая и подсетей куча).
Давайте так :

1. На тестовом клиенте - route delete *(звездочка) -> перезагрузка.
2. На pf в правилах fw вкладка PPTP VPN - добавить правило - * PPTP clients * LAN net * * none
3. В правилах fw вкладка LAN - добавить правило - * LAN net * PPTP clients * * none
4. В свойствах pptp-соединения на клиенте - > сеть - > св-ва TCP\IP -> дополнительно -> снять галку "Использовать основной шлюз в удаленной сети" -> Ок -> Ок -> Ок.
5. Установить впн-сессию и проверить доступность локальных хостов.

И еще - у всех ли машин в вашей локальной сети в свойствах TCP\IP стоит маска 255.255.252.0 ? И у всех ли локальных машин шлюзом указан pf ?
Да и какую адресацию имеют ваши клиенты, к-ые подключаются извне к впн-серверу?

k0st1an

1. ok
2. ok
3. ok
4. ok
5. fail

Все компы в сетке имеют маску /22 - 192.168.40.0/22.

Смотрите. На клиентах в сети стоит шлюз по умолчанию pfsense (ранее был другой, долго рассказывать, ща на vlan переходим потому путанница). Таким образом решается вопрос поиска маршрута к сети vpn (172.16.0.0, эта сетка как раз отдана для vpn клиентов). Добавил в правила fw то, что вы указали. И теперь два варианта: либо указать "отправить весь трафик через vpn" или нет. В первом случае начинает все работать, так как в таблице маршрутизации первым стоит роутер 172.16.0.1, а там и маршрут найти не сложно. Но если галку снять, роутер 172.16.0.1 становится вторым (первый мой домашний роутер) и маршрутизация ломается. Во всяком случае так происходит на Mac OS X. Но думаю, что в виндах ситуация похожая. Если добавить маршрут ручками проблема решится.

Будет время попробую на винде проверить, но, кажется, там будет похожая проблема. Раньше стоял windows 2003, vpn клиенты имели адрес локальной сети, потому проблемы с маршрутизацией не было (можно было указать dhcp сервер, который выдавал нужный адрес с нужной маской). Вот и решение вопроса. Теперь, когда сеть стала шире, надо логически ее разделить (vlan). Использование отдельной сетки для vpn клиентов конечно правильно.

Проверю на виндах, отпишусь. Если условия как у меня - почему у вас работает, а у меня нет?! Не думаю что в этом плане такое сильное различие между Mac OS X и Windows )))

werter

В первом случае начинает все работать, так как в таблице маршрутизации первым стоит роутер 172.16.0.1, а там и маршрут найти не сложно.

Не по-этому, а потому что ВЕСЬ трафик начинает бежать в поднятый туннель, т.е. ВООБЩЕ весь.

Теперь, когда сеть стала шире, надо логически ее разделить (vlan)

VLAN работает на 2-ом (канальном) уровне OSI. А это все ще "физика" (физическая адресация) - http://ru.wikipedia.org/wiki/Сетевая_модель_OSI

Во всяком случае так происходит на Mac OS X

Дело не имел, пардон.

Раньше стоял windows 2003, vpn клиенты имели адрес локальной сети

Попробуйте сделать аналогично, если уж совсем не выйдет. Правилами fw определите куда можно и куда нельзя подключающимся vpn-клиентам.

k0st1an

2. ну да, я подразумевал, что подсети в итоге будут разные. Будет l3 коммутатор, который и будет выступать ядром.
4. да собственно так и было. Хотел убрать лишний сервер…

попробовал на виндах. Не заработало. Вот что получается в таблице маршрутизиции:

Активные маршруты:
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
0.0.0.0 0.0.0.0 192.168.44.50 192.168.44.23 10
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
169.254.0.0 255.255.0.0 192.168.44.23 192.168.44.23 20
172.16.0.0 255.255.0.0 172.16.0.2 172.16.0.2 1
172.16.0.2 255.255.255.255 127.0.0.1 127.0.0.1 50
172.16.255.255 255.255.255.255 172.16.0.2 172.16.0.2 50
192.168.44.0 255.255.255.0 192.168.44.23 192.168.44.23 10
192.168.44.23 255.255.255.255 127.0.0.1 127.0.0.1 10
192.168.44.255 255.255.255.255 192.168.44.23 192.168.44.23 10
212.48.34.115 255.255.255.255 192.168.44.50 192.168.44.23 10
224.0.0.0 240.0.0.0 172.16.0.2 172.16.0.2 50
224.0.0.0 240.0.0.0 192.168.44.23 192.168.44.23 10
255.255.255.255 255.255.255.255 172.16.0.2 172.16.0.2 1
255.255.255.255 255.255.255.255 192.168.44.23 192.168.44.23 1
Основной шлюз: 192.168.44.50

После ручного добавления маршрута:

route add 192.168.40.0 mask 255.255.252.0 172.16.0.2

Начинает работать. Выходит что никак нельзя сделать человеческим образом добавление маршрута клиенту без его участия… Возвращаться к старой схеме удаленного подключения пользователей не очень хочется. Выходит, что когда полностью "мигрирую" на vlan мне надо будет как-то узнавать расположение всех остальных подсетей. Теперь вопрос гораздо шире чем настройка vpn....

werter

Попробуйте вот что :

1. Для впн-сервера Server address : 192.168.200.1
2. Remote address range : 192.168.200.2.
3. Поднимаете сесиию на клиенте.
4. Делаете route print. У вас должен (?) появиться маршрут :

Активные маршруты:
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
192.168.0.0 255.255.0.0 192.168.200.2 192.168.200.2 1

k0st1an

Это что-то у вас другое настроено, или ранее настраивали. Не знаю. У меня так:

Активные маршруты:
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
0.0.0.0 0.0.0.0 192.168.44.50 192.168.44.23 10
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
169.254.0.0 255.255.0.0 192.168.44.23 192.168.44.23 20
192.168.44.0 255.255.255.0 192.168.44.23 192.168.44.23 10
192.168.44.23 255.255.255.255 127.0.0.1 127.0.0.1 10
192.168.44.255 255.255.255.255 192.168.44.23 192.168.44.23 10
192.168.200.0 255.255.255.0 192.168.200.2 192.168.200.2 1
192.168.200.2 255.255.255.255 127.0.0.1 127.0.0.1 50
192.168.200.255 255.255.255.255 192.168.200.2 192.168.200.2 50
212.48.34.115 255.255.255.255 192.168.44.50 192.168.44.23 10
224.0.0.0 240.0.0.0 192.168.44.23 192.168.44.23 10
224.0.0.0 240.0.0.0 192.168.200.2 192.168.200.2 50
255.255.255.255 255.255.255.255 192.168.44.23 192.168.44.23 1
255.255.255.255 255.255.255.255 192.168.200.2 192.168.200.2 1
Основной шлюз: 192.168.44.50

Постоянные маршруты:
Отсутствует

werter

Хм…У меня локалка 10.7.0.0\24 , впн-сервер висит на 10.7.50.1, клиентам с 10.7.50.10 адреса назначаются.
После поднятия сессии в таблице маршрутизации у клиента появляется запись :

Активные маршруты:
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
10.0.0.0 255.0.0.0 10.7.50.10 10.7.50.10 1

Т.е. все что идет на 10.0.0.0 \8 пропихивается в туннель по-дефолту. Может потому что у меня класс сети другой ?

k0st1an

Похоже протокол RIP был бы идеальным решением. Был бы.

werter

@k0st1an:

Похоже протокол RIP был бы идеальным решением. Был бы.

Возможно, но тогда нужно у каждого клиента поднимать Слушатель для этого протокола. Cервер с rip должен быть внутри сети, потому как на PPTP нельзя его включить - в pf нет даже выбора вещания на pptp. Вам легче , если есть домен, в глобальную политику скрипт засунуть, чтоб маршрут прописался и остался в таблице у каждого клиента. Или же ручками у каждого добавлять прийдется..

P.s. А шлюзом (192.168.44.50) у вас что служит?

k0st1an

192.168.44.50 - это dir-655. Но как вы понимаете шлюз может быть любой. Это обычные клиенты подключающиеся из дома. Например я, как скрипт будет мне (на Mac OS X) прописывать настройки не понятно.

Кстати, я что-то не увидел возможности выдать адреса через windows dhcp. Те настройки DHCP которые есть, для VPN не подходят. В DHCP можно было бы настроить 121 опцию.

У меня, уже, немного офтопный вопрос. Как тогда вообще строить большую сеть с разными подсетями, если не получается решить вопрос маршрутизации? Не будем обращать внимание, что можно поставить галочку "весь трафик сюда". Зачем мне оплачивать трафик пользователей сидящих дома? И да, конечно, можно заставить пользователей прописывать нужные маршруты. Но это самое последнее, что должно приходить в голову. Опять же можно вернуться к старому варианту VPN подключения (когда все в одной сети). Но это, конечно, не верно. И вопрос остается открытым, когда сетей становится больше одной (галочка, как помним, "весь трафик сюда" снята)…

werter

Стройте сети на А-классе - 10.0.0.0\8. У меня описанных проблем вроде нет. А вот с В-классом не все так гладко, как оказалось :(
Хотя с тем, что это ,конечно же, не выход, согласен.