+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Назначение маршрутов для PPTP-клиента?

Назначение маршрутов для PPTP-клиента?, RouterOS

MyThoughts

Guest

23.08.2006 15:39:00

Я добавляю новую систему администрирования/мониторинга в свою сеть. Новый компьютер подключен к Mikrotik роутеру, который в свою очередь подключен к другому Mikrotik роутеру по беспроводной связи, а тот – к основному RouterOS роутеру моей сети. То есть: Компьютер —> Роутер A —> Роутер B —> Master RouterOS —> остальная часть моей сети. Хочу использовать PPTP-соединение с Роутер А к моему основному серверу, и чтобы с него сервер «знал» все необходимые маршруты. Таким образом, новый компьютер, находящийся за Роутером А, сможет получить доступ ко всей моей сети. Все работает отлично, ЕСЛИ я вручную добавляю необходимые маршруты на Роутере А. Но, поскольку у меня сейчас 12 разных подсетей и их количество постоянно растет, постоянно добавлять новые маршруты на Роутер А – это просто мучение. К тому же, возможно, я захочу добавить больше подобных подключений. Мне просто нужно, чтобы PPTP-сервер, работающий на моем Master RouterOS, «толкал»/назначал необходимые маршруты Роутеру А. Таким образом, любое PPTP-подключение будет автоматически получать эти маршруты. Я знаю про параметр `/ppp secret routes`, но он используется для динамического добавления маршрутов на PPTP-сервер, а не на клиент. У кого-нибудь есть какие-нибудь предложения?

andrewluck

Guest

23.08.2006 15:42:00

Настрой динамический протокол маршрутизации, например, OSPF или RIP, на своих роутерах. Они предназначены для обновления таблиц маршрутизации на роутерах при их изменении.

С уважением,
Andrew
#‎networking
#‎routing
#‎ospf
#‎rip

changeip

Guest

23.08.2006 16:12:00

Windows будет использовать DHCP OPTION для принятия маршрутов, которые нужно добавить в клиент — отличная идея, однако MT не использует один и тот же DHCP-сервер для PPP… так что это невозможно. Я просил вернуть эту функцию на mum, но, кажется, Mikrotik не понял, что я спрашивал : ) Похоже, это опция 241 или что-то в этом роде — в общем, ты передаешь маршруты, которые клиент должен добавить в свои таблицы маршрутизации. В противном случае, да, используйте маршрутизирующие протоколы с обеих сторон для обмена маршрутами, однако для роуминговых пользователей (а не роутер-к-роутеру) это не самый лучший вариант. Sam

MyThoughts Guest	#4 0 23.08.2006 16:55:00 Спасибо за информацию, ребята. Я понял, что так, как я хотел, это сделать не получится. Пока использую RIP. Еще раз спасибо.

normis Guest	#5 0 24.08.2006 07:11:00 PPP вообще не использует DHCP. У него свой протокол для назначения адресов. Этот протокол не предназначен для выдачи маршрутов.

Beccara Guest	#6 0 24.08.2006 07:18:00 PPP Routes, секретное меню PPP

MyThoughts Guest	#7 0 24.08.2006 15:02:00 Маршруты PPP в секретном меню вообще ничего не делают для клиента, они просто добавляют маршруты на сервер. Это было отмечено в исходном вопросе.

changeip

Guest

24.08.2006 15:11:00

PPP вообще не использует DHCP. У него свой протокол для назначения адресов. Этот протокол не предназначен для раздачи маршрутов. Вы правы, PPP не использует DHCP в Mikrotik… что, если бы он использовал, открыло бы гораздо больше возможностей. http://www.rfc-archive.org/getrfc.php?rfc=3442 RFC3442 определяет эту опцию безклассовых маршрутов через dhcp options. Передавать NTP-серверы, DNS-серверы, WINS-серверы, безклассовые маршруты и всё остальное возможно только с помощью DHCP, если вы не дублируете сокращённый DHCP-сервер в PPP. Зачем дублировать службу DHCP для PPP? Почему просто не позволить PPP подключиться и использовать существующий DHCP-сервис для назначения атрибутов клиентам? Я вижу, что DNS и WINS находятся в профилях PPP — почему бы не позволить DHCP выполнять эту функцию? Сервис Microsoft RAS работает именно так… Просто укажите профиль PPP на запись DHCP-сервера и позвольте ему делать работу. Вернёмся к вашей первоначальной заметке, вы правы, PPP не имеет ничего общего с DHCP, однако нет причин, почему нельзя использовать DHCP с PPP. Сэм.

normis

Guest

25.08.2006 05:48:00

DHCP работает только на интерфейсах типа Ethernet. Windows PPTP-сервер использует DHCP только для получения IP-адреса. Нет способа отправить маршрут непосредственно через PPP. Все эти DHCP-опции не отправляются по PPP. Посмотрите IPCP RFC1332 и покажите мне опцию, которая даст вам маршрут. Эта информация получена от разработчиков, так что придется ей верить.

joeri91942

Guest

#10

25.08.2006 15:47:00

Слушай, Нормис, если применить название темы (PPTP) к вопросу и посмотреть на реализацию от MS, то оказывается, маршруты назначаются! У нас работает система, где MS RRAS обслуживает клиентов на WinXP, используя PPTP через Интернет. RRAS-сервер имеет внутренний "loopback"-адаптер сети 192.1168.255.x/24 и DHCP-сервер, обслуживающий эту сеть. Все подключающиеся клиенты получают IP-адрес из этой DHCP-сети в диапазоне 192.168.255.100-182.168.255.200 ПОДРОБНО, используя статические маршруты с помощью опции… 121 (?), не могу вспомнить номер сейчас, но думаю, это 121. Нам пришлось использовать это, чтобы дать пользователям возможность достучаться до нескольких внутренних IP-подсетей, продолжая при этом пользоваться локальным подключением. Опция "использовать шлюз по умолчанию в удаленной сети" просто не работает хорошо, если у тебя большая задержка до головного офиса на другом континенте, и ты хочешь иметь возможность пользоваться Интернетом, пока VPN включен! /Jörgen

changeip

Guest

#11

25.08.2006 15:56:00

Я поищу эту информацию и выложу чуть позже. В общем, PPP — это ссылка, но после IPCP можно туда пихать любые данные, насколько я понимаю. Как бы то ни было, дайте мне время разобраться и вернуться с реальными pcaps/logs/примерами. Сэм.

savage

Guest

#12

25.08.2006 16:57:00

Если мне придется копать глубже, то, скорее всего, придется изучать RFC по DHCP. Нельзя назначать статические маршруты через DHCP. Большинство Linux-реализаций DHCP — которые строго следуют RFC — имеют опцию для статического маршрута. Однако, нельзя предоставить маску. Таким образом, можно маршрутизировать a.b.c.d в c.d.e.f, но нельзя маршрутизировать a.b.c.d/24 в c.d.e.f. Если Microsoft может это сделать через свои DHCP-серверы, то они делают что-то проприетарное, что не соответствует стандартам RFC, и, скорее всего, будет работать только с Windows-клиентами… Более того, даже с Radius, PPP не взаимодействует с DHCP, ни клиент PPP, запрашивающий IP-адрес. DHCP может назначать динамические IP-адреса PPP-клиентам, но это опять же обрабатывается сторонними решениями. Например, можно получить динамический IP-адрес от DHCP через Radius, и позволить Radius назначить этот IP-адрес для PPP-линка через Framed-IP-Address. Сам PPP — это Point-to-Point соединение, это процесс с одной стороны линка, разговаривающий с процессом с другой стороны линка. Дальше — они ни с чем не взаимодействуют…

savage

Guest

#13

25.08.2006 17:17:00

Давайте просто логически рассмотрим, почему DHCP никогда не сможет работать поверх PPP. PPP = Point to Point Protocol. PPTP, L2TP, PPPoE – всё это работает поверх PPP. В PPP у клиента IP-адрес a.b.c.d, у сервера – w.x.y.z, маска подсети: 255.255.255.255. DHCP работает так, что клиент отправляет широковещание, а сервер его видит. Факт в том, что клиент и сервер находятся в двух совершенно разных IP-сетях. Маска подсети ОБЕСПЕЧИВАЕТ (именно поэтому PPP использует маску 255.255.255.255), что от сервера или клиента НЕ передаются широковещательные пакеты. Когда нельзя передавать широковещания по PPP, как вы предлагаете, чтобы клиент смог отправить запрос DHCP? Просто вопрос... Любая реализация PPP, которая работает через DHCP, использует внутренние проприетарные системы для получения IP-адреса из DHCP вручную, а затем использует этот IP-адрес как удаленный IP для DHCP-соединения… Это нечто совершенно иное, и это можно сделать через Radius (опять же) с большим количеством усилий. Вы всё равно не сможете получить маршруты на стороне клиента…

changeip

Guest

#14

25.08.2006 20:34:00

Я найду это… потому что видел сам. Посмотрю, смогу ли я подключить MT к Windoz ppp серверу и получить логи отладки от MT, которые могут показать больше деталей. Сложно сделать pcap внутри туннеля, потому что он зашифрован. Однако, могу сказать, что Windows pptp сервер выдаёт DNS, WINS, безклассовые маршруты (если установлены dhcp опции 121/254) и другие настройки. Прежде чем спорить, возможно ли это, я найду пример/захват и будем двигаться дальше. Сэм

joeri91942

Guest

#15

26.08.2006 10:03:00

Привет, Savage! Чтобы тебе не пришлось гуглить "класслес статические маршруты", просто скажу, что RFC3442 определяет, как распространять статические маршруты клиенту. Когда ты говоришь, что "невозможно предоставить маску", ты думаешь о старых класфул статических маршрутах (раздел 3.2 в RFC791). Практически никто (по крайней мере, я не видел этого в использовании с… 1997 или 98, кажется) больше этого не использует, так как это предполагает маску подсети из IP-адреса... то есть, 83.x.x.x получает маску /8, а 131.x.x.x — /16 и т.д. (сети класса A, B и C). Однако опция 121, как описано в RFC3442, дает нам возможность выдавать НЕСКОЛЬКО статических маршрутов в одном конфигурационном блоке, делая это путем отправки конфигурации с одним или несколькими наборами байтов, где первый задает длину значимой части подсети, за которым следуют значимые номера подсетей и затем маршрут для использования для этой подсети... например! Чтобы отправить маршрут для сети 192.168.100.0 с маской 255.255.255.0, используя шлюз 10.11.1.1, ты бы настроил строку: 24.192.168.100.10.11.1.1 (24 бита подсети, 192.168.100 — это подсеть и использующий шлюз 10.11.1.1). Для маршрута сети класса B это было бы примерно так: 16.10.10.10.11.1.1 (16 бит подсети, 10.10 — это подсеть и использующий шлюз 10.11.1.1). Конкретный путь к одному серверу выглядел бы примерно так: 32.10.9.8.7.10.11.1.255 (32 бита подсети, 10.9.8.7 — это “подсеть/хост” и использующий шлюз 10.11.1.255). И, конечно, ты можешь объединить несколько таких описателей, чтобы предоставить клиенту несколько разных маршрутов. Это поддерживается реализацией PPTP от MS, на самом деле они сначала выдают PPP IP-адрес для установления связи, а затем клиент запрашивает пакет опций DHCP от удаленной стороны. Самый простой способ увидеть это — выполнить несколько ipconfig / "route print" при подключении к PPTP, ты увидишь соединение и IP-адрес, а затем через некоторое время появятся DNS-серверы, маршруты и т.д.

С наилучшими пожеланиями,
/Jörgen

savage

Guest

#16

26.08.2006 12:54:00

Хм, очень интересно. Я по-прежнему считаю, что запрос DHCP или клиентские маршруты (на CPE) не обрабатываются «в полосе» внутри PPP. Просто нет LCP-расширений, чтобы сервер и клиент могли договориться и согласовать это. Я спросил у нескольких человек, которые знают чуть больше, чем я (всегда найдется кто-то повыше в иерархии), и он тоже подтвердил, что это НЕ обрабатывается «в полосе» в рамках переговоров PPP. ТЕМ НЕ МЕНЕЕ… OpenVPN, по-видимому, тоже может это делать… Точно как это делается, предстоит увидеть. Возможно, реализация PPP от Microsoft имеет своего рода «дополнительную функциональность» (или можно назвать это не RFC-совместимым, если хотите), которая позволяет ей договариваться об этих вещах, например, о клиентских маршрутах. Но на мой взгляд, это определенно не стандарт. OpenVPN мог бы использовать это для получения функциональности. Какие шансы, что это попадет в MT?? Думаю, очень маленькие. Последний раз, когда я проверял, я не думаю, что MT использует OpenVPN, и внедрение его может принести больше хлопот, чем пользы, из-за IPSec-Tools, работающих в MT… Для справки, еще одна вещь, о которой я никогда не знал… Правильный термин для этого называется «раздельное туннелирование»… Cisco to Cisco делает это ОЧЕНЬ хорошо.

EDIT http://www.microsoft.com/technet/community/columns/cableguy/cg1003.mspx

Кажется, правильный способ сделать это с MT - это аутентифицировать PPTP-соединение через Radius, чтобы Radius выделял IP-адреса через DHCP и предоставлял клиенту безклассовый статический маршрут через DHCP (Да, кажется, я все-таки признаю, что был неправ). URL выше показывает различные способы достижения этого в реализации PPTP-клиента от Microsoft… Кажется, теперь нужно искать решение для *Nix.

joeri91942

Guest

#17

26.08.2006 17:58:00

Привет еще раз. Ты абсолютно прав, в PPP нет способа это решить в рамках протокола. Я не хотел сказать, что ты не прав... просто MS использует какой-то особый трюк, чтобы передавать информацию DHCP на PPTP-соединении. Пытаюсь найти, где в ***** я видел описание того, как MS отправляет "пакет получения информации DHCP", если найду - кину ссылку. /Jörgen

savage

Guest

#18

26.08.2006 18:38:00

Да. Что я выяснил (копался сегодня довольно основательно), так это то, что никакого фактического RFC по поводу раздельных туннелей не существует. Все устройства, которые поддерживают это (Nortel, Cisco, Microsoft и т.д.), используют проприетарное клиентское ПО для этого. В случае Cisco вам обязательно нужен Cisco VPN Client, иначе вы вообще не сможете подключиться к VPN, не говоря уже о раздельных туннелях. Для меня становится вполне очевидно, что эти компании используют свои собственные методы получения маршрутов на клиенте. Это не что-то общее, что обрабатывается сервером, это, безусловно, индивидуальное программное решение (как на стороне клиента, так и на стороне сервера) для заполнения маршрутов на клиенте.

joeri91942

Guest

#19

27.08.2006 14:03:00

Ох, если бы MT хотя бы поддерживал реализацию от MS… тогда бы мы могли заставить Windows-клиенты и Linux-клиенты с OpenVPN работать! Ненавижу, что приходится использовать MS VPN-концентратор, чтобы подключить своих клиентов! /Jörgen

BrianHiggins Guest	#20 0 29.08.2006 04:17:00 Я тоже за это, и я тоже просил об этом на MUM.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры