Pptp + route or dhcp
-
Ну так вы маршруты на 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 ?
Да и какую адресацию имеют ваши клиенты, к-ые подключаются извне к впн-серверу? -
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 )))
-
В первом случае начинает все работать, так как в таблице маршрутизации первым стоит роутер 172.16.0.1, а там и маршрут найти не сложно.
Не по-этому, а потому что ВЕСЬ трафик начинает бежать в поднятый туннель, т.е. ВООБЩЕ весь.
Теперь, когда сеть стала шире, надо логически ее разделить (vlan)
VLAN работает на 2-ом (канальном) уровне OSI. А это все ще "физика" (физическая адресация) - http://ru.wikipedia.org/wiki/Сетевая_модель_OSI
Во всяком случае так происходит на Mac OS X
Дело не имел, пардон.
Раньше стоял windows 2003, vpn клиенты имели адрес локальной сети
Попробуйте сделать аналогично, если уж совсем не выйдет. Правилами fw определите куда можно и куда нельзя подключающимся vpn-клиентам.
-
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....
-
Попробуйте вот что :
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 -
Это что-то у вас другое настроено, или ранее настраивали. Не знаю. У меня так:
Активные маршруты:
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
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Постоянные маршруты:
Отсутствует -
Хм…У меня локалка 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 пропихивается в туннель по-дефолту. Может потому что у меня класс сети другой ?
-
Похоже протокол RIP был бы идеальным решением. Был бы.
-
Похоже протокол RIP был бы идеальным решением. Был бы.
Возможно, но тогда нужно у каждого клиента поднимать Слушатель для этого протокола. Cервер с rip должен быть внутри сети, потому как на PPTP нельзя его включить - в pf нет даже выбора вещания на pptp. Вам легче , если есть домен, в глобальную политику скрипт засунуть, чтоб маршрут прописался и остался в таблице у каждого клиента. Или же ручками у каждого добавлять прийдется..
P.s. А шлюзом (192.168.44.50) у вас что служит?
-
192.168.44.50 - это dir-655. Но как вы понимаете шлюз может быть любой. Это обычные клиенты подключающиеся из дома. Например я, как скрипт будет мне (на Mac OS X) прописывать настройки не понятно.
Кстати, я что-то не увидел возможности выдать адреса через windows dhcp. Те настройки DHCP которые есть, для VPN не подходят. В DHCP можно было бы настроить 121 опцию.
У меня, уже, немного офтопный вопрос. Как тогда вообще строить большую сеть с разными подсетями, если не получается решить вопрос маршрутизации? Не будем обращать внимание, что можно поставить галочку "весь трафик сюда". Зачем мне оплачивать трафик пользователей сидящих дома? И да, конечно, можно заставить пользователей прописывать нужные маршруты. Но это самое последнее, что должно приходить в голову. Опять же можно вернуться к старому варианту VPN подключения (когда все в одной сети). Но это, конечно, не верно. И вопрос остается открытым, когда сетей становится больше одной (галочка, как помним, "весь трафик сюда" снята)…
-
Стройте сети на А-классе - 10.0.0.0\8. У меня описанных проблем вроде нет. А вот с В-классом не все так гладко, как оказалось :(
Хотя с тем, что это ,конечно же, не выход, согласен.
