Архивировано

Эта тема находится в архиве и закрыта для публикации сообщений.

Tyc00n

FreeBSD 9 и MPD5

Рекомендованные сообщения

а вообще еще один вопрос: маршруты FreeBSD получаются автоматом или вручную прописаны? Если автоматом, то как сие реализовано (ибо из "коробки" FreeBSD в локальной сети Beeline автоматом даже основной маршрут не получает....)

И не получит. Точнее проигнорирует. Если из "коробки".

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сегодня настраивал mpd 5.6 на FreeBSD -HEAD (10.0). После непродолжительной консультации с автором mpd, уважаемым Александром Мотиным, оказалось что можно еще красивее поднимать туннель, не используя скрипты IF up/down вообще. Как известно проблемы с петлевыми маршрутами начинаются из-за того, что IP BRAS'a одинаковы и снаружи и внутри тоннеля, в итоге по дефолту у нас получается петля. В итоге родилось простейшее решение, которое избавляет нас от необходимости костылей по ручному редактированию таблицы маршрутизации через скрипты IF up/down(которые кстати и не работают в HEAD):

set iface addrs 0.0.0.0 !1.2.3.4 - му подменяем IP адрес BRAS'a внутри тоннеля

set iface route 0.0.0.0/1

set iface route 128.0.0.0/1 - а этими двумя маршрутами изящно обходим дефолтроут в локалку, который можно оставлять старым.

Для копипастильщиков рабочий конфиг:

 

default:

load Beeline_L2TP

Beeline_L2TP:

create bundle static L2TP

set bundle disable compression

set bundle disable round-robin

set bundle disable encryption

set bundle disable crypt-reqd

set bundle disable bw-manage

set bundle disable ipv6cp

set bundle enable ipcp

set ipcp no vjcomp

set iface mtu 1460

set iface idle 0

set iface enable tcpmssfix

set iface addrs 0.0.0.0 !1.2.3.4

set iface route 0.0.0.0/1

set iface route 128.0.0.0/1

create link static L2 l2tp

set link action bundle L2TP

set link latency 0

set link max-redial 0

set link redial-delay 60

set link disable incoming acfcomp protocomp magicnum check-magic

set link deny chap-msv2 chap-msv1 pap eap acfcomp protocomp

set link accept chap-md5

set link keep-alive 60 180

set l2tp peer IP АДРЕС BRAS

set auth authname "ЛОГИН"

set auth password "ПАРОЛЬ"

open

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сегодня настраивал mpd 5.6 на FreeBSD -HEAD (10.0). После непродолжительной консультации с автором mpd, уважаемым Александром Мотиным, оказалось что можно еще красивее поднимать туннель, не используя скрипты IF up/down вообще. Как известно проблемы с петлевыми маршрутами начинаются из-за того, что IP BRAS'a одинаковы и снаружи и внутри тоннеля, в итоге по дефолту у нас получается петля.

Проблема (loop detected) в том что что надо иметь два марштрута:

 

-- по внутренней сети до браса чтобы l2tp/pptp пакеты ходили

 

-- по l2tp/pptp линку чтобы полезные пакеты ходили куда надо

 

и оба маршрута указывают на один и тот же ipv4. А default вообще побоку.

 

P.S. Вот бы кто-то умный рассказал/написал как эта проблема в MS windows решается. Или скорее почему её там нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сегодня настраивал mpd 5.6 на FreeBSD -HEAD (10.0). После непродолжительной консультации с автором mpd, уважаемым Александром Мотиным, оказалось что можно еще красивее поднимать туннель, не используя скрипты IF up/down вообще. Как известно проблемы с петлевыми маршрутами начинаются из-за того, что IP BRAS'a одинаковы и снаружи и внутри тоннеля, в итоге по дефолту у нас получается петля. В итоге родилось простейшее решение, которое избавляет нас от необходимости костылей по ручному редактированию таблицы маршрутизации через скрипты IF up/down(которые кстати и не работают в HEAD):

set iface addrs 0.0.0.0 !1.2.3.4 - му подменяем IP адрес BRAS'a внутри тоннеля

set iface route 0.0.0.0/1

set iface route 128.0.0.0/1 - а этими двумя маршрутами изящно обходим дефолтроут в локалку, который можно оставлять старым.

Для копипастильщиков рабочий конфиг:

 

default:

load Beeline_L2TP

Beeline_L2TP:

create bundle static L2TP

set bundle disable compression

set bundle disable round-robin

set bundle disable encryption

set bundle disable crypt-reqd

set bundle disable bw-manage

set bundle disable ipv6cp

set bundle enable ipcp

set ipcp no vjcomp

set iface mtu 1460

set iface idle 0

set iface enable tcpmssfix

set iface addrs 0.0.0.0 !1.2.3.4

set iface route 0.0.0.0/1

set iface route 128.0.0.0/1

create link static L2 l2tp

set link action bundle L2TP

set link latency 0

set link max-redial 0

set link redial-delay 60

set link disable incoming acfcomp protocomp magicnum check-magic

set link deny chap-msv2 chap-msv1 pap eap acfcomp protocomp

set link accept chap-md5

set link keep-alive 60 180

set l2tp peer IP АДРЕС BRAS

set auth authname "ЛОГИН"

set auth password "ПАРОЛЬ"

open

Да и скрипты UP/DOWN служат, скорее, не для поднятия линка, а для удобного использования того самого линка: создать NAT на интерфейсе, запустить иные демоны, которые используют интернет. У меня, например, скрипты UP\DOWN включают\выключают transmission и openVPN - этим демонам нужен интернет, а коли его нет, то и работать им не надобно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это у вас, а посмотрите на большинство скриптов IF up/down для mpd на форуме - что они делают ? ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это у вас, а посмотрите на большинство скриптов IF up/down для mpd на форуме - что они делают ? ;)

Пытаются сохранить default на внутренюю сетку, где оно совершенно не нужно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это у вас, а посмотрите на большинство скриптов IF up/down для mpd на форуме - что они делают ? ;)

Наиболее востребованная цель скриптов UP\DOWN - сохранение текущего основного маршрута и присвоение основного маршрута MPD-линку. После разрыва соединение сохраненный основной маршрут (до поднятия линка) "возвращается" на место как было до поднятия линка. А в самом поднятии линка скрипты не участвуют. Для пчелайна очень важно вернуть основной маршрут после разрыва соединения, иначе восстановить соединение не получится...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это у вас, а посмотрите на большинство скриптов IF up/down для mpd на форуме - что они делают ? ;)

Наиболее востребованная цель скриптов UP\DOWN - сохранение текущего основного маршрута и присвоение основного маршрута MPD-линку. После разрыва соединение сохраненный основной маршрут (до поднятия линка) "возвращается" на место как было до поднятия линка. А в самом поднятии линка скрипты не участвуют. Для пчелайна очень важно вернуть основной маршрут после разрыва соединения, иначе восстановить соединение не получится...

Ну так это и решается вот таким образом:

set iface route 0.0.0.0/1

set iface route 128.0.0.0/1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это у вас, а посмотрите на большинство скриптов IF up/down для mpd на форуме - что они делают ? ;)

Наиболее востребованная цель скриптов UP\DOWN - сохранение текущего основного маршрута и присвоение основного маршрута MPD-линку. После разрыва соединение сохраненный основной маршрут (до поднятия линка) "возвращается" на место как было до поднятия линка. А в самом поднятии линка скрипты не участвуют. Для пчелайна очень важно вернуть основной маршрут после разрыва соединения, иначе восстановить соединение не получится...

Ну так это и решается вот таким образом:

set iface route 0.0.0.0/1

set iface route 128.0.0.0/1

Мне кажется Вы забыли упомянуть, что ваш "финт ушами" работает когда VPN-сервер провайдера задан ip-адресом:

 

"set l2tp peer IP АДРЕС BRAS"

 

А если BRAS изменится (у провайдера такое бывает, когда идет модернизация оборудования)? В ТП провайдера звонить будете и требовать дабы он вернул все как было,потому как в Вас так раньше работало? Остальным тоже такое рекомендовать будете?? Такое решение не является универсальным. К тому же:

 

"set iface route 128.0.0.0/1" - может быть у Вас белый ip-адрес постоянный (это отдельная услуга у провайдера), а у большинства он меняется от сессии к сессии, и не всегда он вида 128.xxx.xxx.xxx.

 

И самое интересное, что будет когда линк разорвется: доступ, например к данному форуму будет работать? А к beeline.ru? И не по ip-адресу, а по доменному имени естественно....

 

а если VPN-сервер задан доменным именем:

 

"set l2tp peer tp.internet.beeline.ru"

 

и основной маршрут восстанавливается после разрыва линка, доступ к локальным ресурсам остается + никакие изменения BRAS-ов и модернизации провайдера на работоспособность шлюза не влияют.

 

Сегодня настраивал mpd 5.6 на FreeBSD -HEAD (10.0). После непродолжительной консультации с автором mpd, уважаемым Александром Мотиным, оказалось что можно еще красивее поднимать туннель, не используя скрипты IF up/down вообще. Как известно проблемы с петлевыми маршрутами начинаются из-за того, что IP BRAS'a одинаковы и снаружи и внутри тоннеля, в итоге по дефолту у нас получается петля.

Проблема (loop detected) в том что что надо иметь два марштрута:

 

-- по внутренней сети до браса чтобы l2tp/pptp пакеты ходили

 

-- по l2tp/pptp линку чтобы полезные пакеты ходили куда надо

 

и оба маршрута указывают на один и тот же ipv4. А default вообще побоку.

 

P.S. Вот бы кто-то умный рассказал/написал как эта проблема в MS windows решается. Или скорее почему её там нет.

Полно те господа, тут все уже давно известно...

В Windows этой проблемы нет. И вообще такой проблемы нет. Просто у Unix и Microsoft разные понятия о DHCP option 249, по которой Beeline раздает кипу маршрутов для корректной работы VPN-соединения и ресурсов локальной сети. Что бы мотивировать пользователей других провайдеров перейти на Пчелайн, нужно их чем-то заманить. А заманивались они тем, что цены ниже + для подключения покупать никакие модемы\роутеры не нужно. Т.е. пчелайн бесплатно протягивает тебе витую парту в квартиру, а пользователю остается воткнуть ее в комп и настроить соединение. Ну, а то что на большинстве ПК будет стоять именно Windows никто не сомневается. По этому Пчелайн сделал так, что на Windows все ОК (к стати, в нарушение общих стандартов в пользу "стандартов" Microsoft). Ничего личного - просто бизнесссс... Нужно сделать так, что бы DHCP клиент FreeBSD интерпретировал 249-ю DHCP опцию так как ее интерпретирует DHCP клиент Microsoft. Тогда и на FreeBSD можно в качестве VPN сервера указывать доменное имя (у меня tp.internet.beeline.ru), а все маршруты будут получаться автоматом.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В Windows этой проблемы нет. И вообще такой проблемы нет. Просто у Unix и Microsoft разные понятия о DHCP option 249, по которой Beeline раздает кипу маршрутов для корректной работы VPN-соединения и ресурсов локальной сети. Что бы мотивировать пользователей других провайдеров перейти на Пчелайн, нужно их чем-то заманить. А заманивались они тем, что цены ниже + для подключения покупать никакие модемы\роутеры не нужно. Т.е. пчелайн бесплатно протягивает тебе витую парту в квартиру, а пользователю остается воткнуть ее в комп и настроить соединение. Ну, а то что на большинстве ПК будет стоять именно Windows никто не сомневается. По этому Пчелайн сделал так, что на Windows все ОК (к стати, в нарушение общих стандартов в пользу "стандартов" Microsoft). Ничего личного - просто бизнесссс... Нужно сделать так, что бы DHCP клиент FreeBSD интерпретировал 249-ю DHCP опцию так как ее интерпретирует DHCP клиент Microsoft. Тогда и на FreeBSD можно в качестве VPN сервера указывать доменное имя (у меня tp.internet.beeline.ru), а все маршруты будут получаться автоматом.

Профессор!

У меня есть /etc/dhclient-exit-hooks (+/etc/dhclient.conf) который получает 249 опцию (+статические маршруты) и использует её. Этот же скрипт удаляет default route для MAN (локальной сети пчеловодов 10.0.0.0/8) и принудительно пишет в routing table 85.21.0.0/24 & 78.107.1.0/24 (брасы для деревни Митино). У меня в mpd.conf только доменное имя. Но всё это не спасает от loop detected.

 

Пока проблему отложил на потом с помощью set ipcp ranges 0.0.0.0/0 xxx.xxx.xxx.xxx/24 -- злобный запрос нужного для меня ipv4 для браса.

 

Что я делаю неправильно? ;-) :mellow:

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В Windows этой проблемы нет. И вообще такой проблемы нет. Просто у Unix и Microsoft разные понятия о DHCP option 249, по которой Beeline раздает кипу маршрутов для корректной работы VPN-соединения и ресурсов локальной сети. Что бы мотивировать пользователей других провайдеров перейти на Пчелайн, нужно их чем-то заманить. А заманивались они тем, что цены ниже + для подключения покупать никакие модемы\роутеры не нужно. Т.е. пчелайн бесплатно протягивает тебе витую парту в квартиру, а пользователю остается воткнуть ее в комп и настроить соединение. Ну, а то что на большинстве ПК будет стоять именно Windows никто не сомневается. По этому Пчелайн сделал так, что на Windows все ОК (к стати, в нарушение общих стандартов в пользу "стандартов" Microsoft). Ничего личного - просто бизнесссс... Нужно сделать так, что бы DHCP клиент FreeBSD интерпретировал 249-ю DHCP опцию так как ее интерпретирует DHCP клиент Microsoft. Тогда и на FreeBSD можно в качестве VPN сервера указывать доменное имя (у меня tp.internet.beeline.ru), а все маршруты будут получаться автоматом.

Профессор!

У меня есть /etc/dhclient-exit-hooks (+/etc/dhclient.conf) который получает 249 опцию (+статические маршруты) и использует её. Этот же скрипт удаляет default route для MAN (локальной сети пчеловодов 10.0.0.0/8) и принудительно пишет в routing table 85.21.0.0/24 & 78.107.1.0/24 (брасы для деревни Митино). У меня в mpd.conf только доменное имя. Но всё это не спасает от loop detected.

 

Пока проблему отложил на потом с помощью set ipcp ranges 0.0.0.0/0 xxx.xxx.xxx.xxx/24 -- злобный запрос нужного для меня ipv4 для браса.

 

Что я делаю неправильно? ;-) :mellow:

 

Этот способ знаю я, но он не универсальный. Выше по теме я давал ссылку на свой способ, где не надо указывать никаких IP-все автоматом. Попробуйте его, может быть в вашей деревне сработает (там все подробно описано).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Этот способ знаю я, но он не универсальный. Выше по теме я давал ссылку на свой способ, где не надо указывать никаких IP-все автоматом. Попробуйте его, может быть в вашей деревне сработает (там все подробно описано).

Не нашел описание вашего способа. Пальцем покажите, пожалуйста.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Этот способ знаю я, но он не универсальный. Выше по теме я давал ссылку на свой способ, где не надо указывать никаких IP-все автоматом. Попробуйте его, может быть в вашей деревне сработает (там все подробно описано).

Не нашел описание вашего способа. Пальцем покажите, пожалуйста.

Ответ №16

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

set iface addrs 0.0.0.0 !1.2.3.4 - мы подменяем IP адрес BRAS'a внутри тоннеля

set iface route 0.0.0.0/1 - добавляем маршрут на "первую половину интернетов" через тоннель

set iface route 128.0.0.0/1 - добавляем маршрут на "вторую половину интернетов" через тоннель

 

С чего бы это мой финт работает только при указании IP BRAS'a руками ? Мы меняем внутритоннельный адрес BRAS'a (всё равно какой) на 1.2.3.4.

И роутам тоже наплевать, какой там адрес у пользователя в тоннеле. Мне кажется, Вы не заметили /1 маску, если совсем на пальцах - эти два роута делят весь диапазон IPv4 на две половинки, а поскольку механизм выбора маршрута прислушивается к более мелким роутам в первую очередь, то один жирный и большой дефолт будет меньше, чем две "половинки" дефолта :-)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

set iface addrs 0.0.0.0 !1.2.3.4 - мы подменяем IP адрес BRAS'a внутри тоннеля

set iface route 0.0.0.0/1 - добавляем маршрут на "первую половину интернетов" через тоннель

set iface route 128.0.0.0/1 - добавляем маршрут на "вторую половину интернетов" через тоннель

 

С чего бы это мой финт работает только при указании IP BRAS'a руками ? Мы меняем внутритоннельный адрес BRAS'a (всё равно какой) на 1.2.3.4.

И роутам тоже наплевать, какой там адрес у пользователя в тоннеле. Мне кажется, Вы не заметили /1 маску, если совсем на пальцах - эти два роута делят весь диапазон IPv4 на две половинки, а поскольку механизм выбора маршрута прислушивается к более мелким роутам в первую очередь, то один жирный и большой дефолт будет меньше, чем две "половинки" дефолта :-)

Ну так Вы в конфиге MPD указали:

"set l2tp peer IP АДРЕС BRAS"

по этому у меня такая мысль и возникла. Но стоп! Что-то я не совсем понимаю всю идею. Как я понял механизм работы провайдера такой.: в сетевую карту подключается витая пара от провайдера. При этом от провайдера по DHCP протоколу система получает: ip-адрес, маску подсети, основной маршрут, DNS-сервер + еще несколько маршрутов (нужны для поднятия vpn-линка)

После этого поднимается VPN-Линк. И основной маршрут должен идти через VPN-линк. Я так понимаю, что в системе должен быть только ОДИН основной маршрут, куда идут пакеты, на которые не найдены маршруты среди имеющихся. После "падения" VPN-линка основной маршрут в системе как бы отсутствует (ведь он идет через VPN-линк, а его уже и нет.) Что происходит дальше? Просто Вами была предоставлена "новая хитрая схема решения проблемы", но полного описания нет... Для того, что бы всем было понятно, снабдите описание полной информацией: сетевые параметры до поднятия VPN-линка (ip-адрес, DNS сервера, основной маршрут), а так же каким образом они получены (вручную, али автоматом выданы провайдером). Вот тогда и можно будет обсудить Ваш способ. А пока вопросы прежние: как ведет себя система до поднятия VPN-линка (и после его разрыва): доступны ли локальные ресурсы сети, данный форум, сайт провайдера? Эти вопросы возникают все по той же причине отсутствия вводных данных по вашей системе. Все те, кто предлагал различные решения проблемы "образования петли" все же указывали все параметры и условия, при которых их решение будет работать. Вами такие данные не предоставлены. Вот и получается что Вам задают кучу вопросов, предоставьте данные и мы обсудим Ваш способ, тем более что мне это самому интересно разобраться в столь виртуозной схеме (хотя бы в орбазовательнрых целях). Это что касается Вашего решения.

 

И как я уже говорил (да и всем остальным это известно), петля "почему-то" не образовывается на системах с Winsows на борту.Выше я изложил свое мнения по этому поводу. И мне постоянные посты о том, как решить проблему петли очень не понятны. Вроде бы все знают, откуда идет проблема во FreeBSD при подключении к провайдеру Beeline (из-за того, что система не получает маршруты, которые без проблем получает система с Windows), но все упорно не хотят ее решать, а предпочитают мостырить костыли и разные хитрые способы, приемы, и т. д. и т. п. (причем все из них имеют ограничения и требования - как то основной маршрут в локалке нужно прописывать вручную и т.д.). Но ни один из предложенных способов не позволял получить тот же сетевой функционал провайдера (интернет и локальные ресурсы) автоматом, как это получается на системах с Windows. Когда я в середине 2011 года решил на FreeBSD подключиться к пчеловодам, я прочел кучу форумов о том как же подключиться, и еще больше тем о том, что у всех постоянные проблемы с соединением: то отваливается, то отваливается, но потом не хочет соединяться, пока не перезагрузишь систему, то у кого-то пол года работал свой "способ" решения проблемы, но вдруг провайдер модернизировал сеть, и теперь старый "способ" уже не работает. Причем на системах с windows никакие изменения и модернизации провайдера не влияли и линк был всегда (я не имею ввиду случаи, когда действительно проблемы были такие, что никто не мог подключиться - но провайдер об этом честно предупреждал). Вот тогда я и призадумался - если на Windows все ОК, то нужно добиваться того, что бы на FreeBSD было так же. Начал я последовательно, просто подключил кабель от провайдера в систему с windows, посмотрел что при этом доступно, записал параметры сети (ip-адрес, маску, шлюз, DNS, список маршрутов). За тем я воткнул кабель провайдера в систему с FreeBSD, и мне сразу стало понятно - основной маршрут не получен, нет дополнительных маршрутов. Вот и все! Была найдена именно причина проблемы! И дальше цель была решить причину проблемы, а не испытывать различные способы борьбы с последствиями. Ведь это очевидно: если у тебя проблема, сравни свои параметры с параметрами того, у кого ее нет. Я сравнил, увидел разницу и решил проблему: после правки исходников DHCP клиента на freebsd таблица маршрутов была идентична таблице маршрутов на Windows. Все! После этого VPN-Линк у меня без проблем поднялся и такой фигни как "loop detected" и "localy generated disconnect" у меня не появлялось. Все стало на автомате, как и в Windows. Я до сих пор не знаю, что такое районный БРАС, мне не известны внутренние адреса туннелей, маршруты до БРАСов и т.д. и т.п, я не пытаюсь узнать адрес районного шлюза, мне пофиг на особенности маршрутизации в сети провайдера. И пользователям WINDOWS на это пофиг, и они этого не знают. Но у них и у меня нет проблем с подключением. Без обид, товарищи, но меня удивляют очередные посты о новом "костыле" по решения проблемы образования петли. Вы пытаетесь лечить последствия, а надо бы просто устранить причину. Я ее устранил, поделился с остальными. Уж не знаю, что можно еще изобретать, сколько еще можно мусолить способы решения последствий... Я, конечно, не имею ввиду случаи, когда провайдеров несколько: один билайн (с не совсем соблюдаемыми стандартами), другой "правильный" - это частный случай, а большинство пользователей - домашние, ибо домашний интернет Билайн позиционируется для домашних пользователей....

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня сложилось впечатление, что Вы не понимаете, как работает маршрутизация во фре(да и собственно почти в любой вменяемой ОС). mpd наплевать, как вы получили маршрут по умолчанию, вписали руками или получили через патченый dhcp клиент. Главное, чтобы в таблице маршрутизации ядра был маршрут к BRAS'у, причем всё равно, указан IP адрес или доменное имя. Итак, разбиваем процесс подключения на стадии:

1. ОС загрузилась, по DHCP мы получили IP адрес, маршруты. Маршрут по умолчанию указывает на местный шлюз:

default 10.195.24.1 UGS 0 10 em1

2. Поднимаем тоннель с BRASом используя описанное мной решение, в таблице маршрутизации появляется два маршрута, которые имеют приоритет выше, чем дефолт:

0.0.0.0/1 1.2.3.4 UGS 0 7574225 ng0

128.0.0.0/1 1.2.3.4 UGS 0 2028548 ng0

Это обеспечивают конфигурационные директивы set iface route 0.0.0.0/1 и set iface route 128.0.0.0/1.

 

1.2.3.4 - это IP адрес BRASа внутри тоннеля:

ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> metric 0 mtu 1460

inet МОЙ.IP.АДРЕС.ВНУТРИ.ТОННЕЛЯ --> 1.2.3.4 netmask 0xffffffff

любой внутритоннельный IP адрес BRAS'a будет заменен на 1.2.3.4 из-за конфигурационной директивы set iface addrs 0.0.0.0 !1.2.3.4

 

Соответственно, если тоннель упадет, оба маршрута /1 будут убраны из таблицы маршрутизации ядра, и дефолт останется как в п.1

 

Если смотреть на Ваше скриптовое решение, то можно с чистой совестью выкинуть вот эти строчки:

# удаляем текущий основной маршрут

route delete default

# добавляем новый основной маршрут

route add default $4

# сохраняем новый основной маршрут

echo $4 > /tmp/mpd_dr

# сохраняем предыдущий основной маршрут

echo $gw > /tmp/mpd_gw

# небольшая передышка

sleep 20

Поскольку мы решили эту проблему силами двух строчек в конфиге mpd.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня сложилось впечатление, что Вы не понимаете, как работает маршрутизация во фре(да и собственно почти в любой вменяемой ОС).

Я считаю, что такие выводы делать, по крайней мере не культурно. На чем сей вывод основан? Вроде мы тут обсуждаем FreeBSD, а не остальные ОС. И я, вроде не писал, что я спец в маршрутизации по всем "вменяемым" ОС. И вроде бы не считал Вас неграмотным в этом вопросе. Попрошу не делать таких заявлений, ибо мы все на этом форуме ищем помощи. Не стыдно что-то не знать, а мне не стыдно спросить.

Я сообщил Вам, что заинтересован в вашем решении, но мне не хватает некоторых данных для его понимания. Вы же прекрасно знаете, что установить mpd и закинуть туда Ваш конфиг - этого не достаточно для успешного соединения, хотя бы потому, что "из коробки" FreeBSD не получит маршрутов. Вы (да и я тоже) прекрасно об этом осведомлены, но тот, кто читает ваш пост в первый раз - возможно нет. Я использовал свой путь подключения, у Вас - другой. Никто не спорит, что он рабочий, но Вы можете прокомментировать свое решение? Именно по той причине, что я не разобрался в Вашем способе, я и задаю наводящие вопросы. Ведь в самом деле, легче спросить того, у кого это работает, тем более что он публично предложил решение. Если бы Вами был предоставлен полный (в рамках сетевых настроек) конфиг системы (например, параметры сетевых адаптеров в rc.conf) - я бы не стал задавать вопросы. Но этих параметров в описании вашего решения нет. Соответственно, у меня появились вопросы, которые я и адресовал автору решения, то есть Вам. Вами представлено решение - я хочу понять его функционал (не просто так, многие задолго до Вас уже предлагали решение проблемы. А другие спрашивали, то что их интересовало: одним нужна локальная сеть, и они спрашивали о том, будет ли она работать, другим подавай IPTV как в железных роутерах - и они спрашивали у автора, будет ли IPTV работать?). Представьте что я обычный пользователь, у которого есть железный роутер, например DIR-320. Который работает, но жутко тормозит на торрентах, локальной сети и т.д. (что не мудрено). И ту кто-то мне предлагает настроить программный шлюз на FReeBSD, потому как этот программный шлюз будет быстрее работать. Ого, подумал я, это мне нравиться, скорость мне нужна!!! Но задаю вопрос: у меня на моем DIR-320 локальная сеть работает, а на Вашем программном шлюзе работать будет? Или: у меня когда я забуду оплатить интернет, доступ к локалке есть, и к личному кабинету тоже - я могу зайти, активировать функцию "обещанный платеж", после чего интернет врубят и я могу через "онлайн банкинг" кинуть деньги на счет. А с вашим программным шлюзом такое будет работать? В зависимости от ответов пользователь будет решать - подходит ли ему такое решение или нет. А вы мне отвечает в духе: "у меня все работает, а вы не разбираетесь". Вот как тот самый пользователь, я и задаю вопросы: 1. Локальная сеть работает (до поднятия линка или без оного)? 2. Если соединение будет разорвано, автоматом восстановится? 3. Без поднятия линка данный форум (а так же личный кабинет пользователя) доступен? Если все три ответа будут утвердительными - то да, мне будет очень интересно узнать об этом решении! И я попрошу у Вас дополнительные сведения и т.д. и т.п. А если один из ответов будет нет, то зачем мне разбираться, если у меня все три пункта работают? Получится что мое решение не хуже Вашего, тогда и разговаривать не о чем будет. Уверен, что не одному мне интересно ваше решение, но легче всего сравнить простым способом: зачем проводить анализ маршрутов - это обычному пользователю не особо интересно, а вот что работает из услуг провайдера (локалка, доступ к личному кабинету при нулевом балансе) - это для простого пользователя более понятный критерий. Согласитесь, что так легче.

Если чем - то обидел, прошу извинить - у меня не было такого намерения.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Минуточку, так я не предлагал полного решения! Соответственно и вопросы, которые вы мне задаете, более подошли бы автору полноценного решения. Я лишь намекнул и показал, как можно решить некоторые из граблей, любезно расставленных полосатыми. А после Ваших наводящих вопросов даже дважды объяснил как работают эти несчастные три строчки конфига. Кстати, внимательно прочитал Ваш мануал по настройке роутера на базе FreeBSD, некоторые вещи улыбнули. Особенно вот это: "Можно порадоваться - у нас появился основной маршрут, плюс дополнительный маршрут до сети 233.33.210.0 (именно этот маршрут и обеспечивает доступ к VPN серверам провайдера)." Сильно сомневаюсь, что BRASы для Краснодара действительно находятся в этой подсети :)

 

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

Судя по всему в Краснодаре нет Московской проблемы с одинаковым IPом BRASа внутри тоннеля и снаружи. Цитирую логи Вашего mpd и ifconfig:

L2TP: Initiating control connection 0x28806108 0.0.0.0 0 <-> 10.255.255.244

10.255.255.244 - это судя по всему IP вашего BRAS'a, а на ng0 у вас endpoint 37.147.32.1

А в Москве у меня IPы BRASа снаружи тоннеля и внутри одинаковые.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Минуточку, так я не предлагал полного решения! Соответственно и вопросы, которые вы мне задаете, более подошли бы автору полноценного решения. Я лишь намекнул и показал, как можно решить некоторые из граблей, любезно расставленных полосатыми. А после Ваших наводящих вопросов даже дважды объяснил как работают эти несчастные три строчки конфига. Кстати, внимательно прочитал Ваш мануал по настройке роутера на базе FreeBSD, некоторые вещи улыбнули. Особенно вот это: "Можно порадоваться - у нас появился основной маршрут, плюс дополнительный маршрут до сети 233.33.210.0 (именно этот маршрут и обеспечивает доступ к VPN серверам провайдера)." Сильно сомневаюсь, что BRASы для Краснодара действительно находятся в этой подсети :)

Брасы может быть и не находятся, но без этого маршрута нормального коннекта не было - он появился только после правки исходников DHCP клиента Freebsd. А раз без него нормального коннекта нет, я и написал в свободной форме, что он таки обеспечивает коннект, а как,для чего и каким образом - это уже третий вопрос. Раз провайдер его выдал, то значит нужен, поди пойми как у него там маршрутизация настроена. Но раз уж есть такое замечание, я учту его, и поправлю мануал, дабы фраза не была неверно истолкована.

Может быть полного решения и не предлагали, но вы же не просто так для теории создавали конфиг? Значит пользуетесь (или будете пользоваться), коннект есть - вот и возникают вопросы, что да как... Просто интернет кишит разными мануалами по созданию VPN для Билайна, но большинство не выходит за рамки конфига MPD. Но в таком виде данные инструкции мало кому помогают - в них не оговариваются остальные условия для работы. Многие пишут что все на ура работает, но не оговаривают, что нужно до сей инструкции что-то сделать, причем не всегда очевидное. Даже если Вами предложен только способ решения - он будет полезен только в случае практической реализации. Мы ведь на форуме не теоретикой занимаемся - вот и хотим знать, при каких условиях сей конфиг работает.

И все же я останусь при своем мнении - что скрипты up/down не являются "костылями" - они целенаправленно созданы для дальнейшего использования уже созданного линка по усмотрению пользователя. Просто Вами предложен вариант, когда эти скрипты не требуются для правки маршрутов (что в принципе у всех не плохо работает и вариант сей многих устраивает). А мне сперва интересна практическая реализация.

 

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

Судя по всему в Краснодаре нет Московской проблемы с одинаковым IPом BRASа внутри тоннеля и снаружи. Цитирую логи Вашего mpd и ifconfig:

L2TP: Initiating control connection 0x28806108 0.0.0.0 0 <-> 10.255.255.244

10.255.255.244 - это судя по всему IP вашего BRAS'a, а на ng0 у вас endpoint 37.147.32.1

А в Москве у меня IPы BRASа снаружи тоннеля и внутри одинаковые.

Подкованная у Вас супруга, и внимательная тоже - я то сам сей лог не рассматривал, просто для примера привел "признаки рабочего линка" - типа если у вас не фурычит - поглядите на лог работающего в реальной жизни MPD (у меня же заработало, и смысла копаться в нем не было...). Но все же: даже если в Московской области и есть проблема с одинаковыми IP браса внутри тоннеля и снаружи, на работу с Windows это никак не влияет. Т.е. каким-то чудодейственным образом с этим жить можно и без костылей. Т.е. для windows "как бы" проблемы и не существует - вот этот вопрос мне более всего интересен...

Сам я нигде, кроме Краснодара проверить работу моего способа не могу (по сему в статье моей есть оговорка - для Краснодара). Но можно сообща провести эксперимент!

Для начала, в данном топике есть keishu, который использовал мой способ (по крайней мере, отписался об этом - ответ №17). Можно поинтересоваться о его дислокации (а вдруг в Московской области) и попросить лог работающего MPD - тогда можно будет выяснить - существует ли проблема с одинаковыми IP, или нет. Может быть кто-то другой из участников из Московской области сможет предоставить лог.

Ну или же Вы, RussianE39, можете опробовать предложенный мною способ коннекта, но уже не в Краснодаре, а в Москве. Просто мне никто из Московской области не писал о том, что у него не получилось, или не говорил об этом. А еще лучше, если кто предоставит лог VPN-коннекта на Windows в Московской области. Тогда можно будет детально сравнить и решить в чем косяк. Быть может конфиг мой на Московских просторах не заработает, тогда еще интереснее будет - есть простор для мысли, во имя универсального решения. Остается ждать, кто попробует, да отпишется)))

Ну и, в качестве дополнения, меня интересует более не "как обойти грабли", а как сделать так, что бы они не появлялись вообще.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

chirva_a_s, а как Вы обходите обновление порта mpd? Ведь все правки исходника слетят.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

chirva_a_s, а как Вы обходите обновление порта mpd? Ведь все правки исходника слетят.

В части серверов я придерживаюсь правил: работает нормально - не хрен трогать. А обновляю я систему только 1 раз - сразу после установки. И все, после этого никаких обновлений, коли все работает))) Я как-то пробовал обновить что-то после (кажись перед самой установкой php для apache), но в результате поехал perl, а в месте с ним и кое что еще. Ну его, работает - не трогай (видимо еще со времен Windows закрепилось)!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

chirva_a_s, а как Вы обходите обновление порта mpd? Ведь все правки исходника слетят.

Так он вроде и не правит ничего в mpd, только в /usr/src. Кстати у меня точно так же, я тоже патчу дхцп клиента.

 

Моя практическая реализация мало кому нужна, поскольку у меня не только одна корбина воткнута в эту машину, однако же если вы так настаиваете, могу показать как оно у меня работает. Учтите - никакого закопипастил и само работает в моем решении нет. Всё ручками :)

Итак:

Выдержки из rc.conf:

synchronous_dhclient="YES"

ifconfig_em1="DHCP"

defaultrouter="10.195.24.1"

static_routes="corbinabras1 corbinabras2"

route_brassubnets1="78.107.1.0/24 10.195.24.1"

route_brassubnets2="85.25.0.0/24 10.195.24.1"

mpd_enable="YES"

 

mpd.conf вы уже видели. Без скриптовых костылей всё подымается сразу после перезагрузки системы, никакие sleepы нигде не требуются (ну кроме тормозов с получением ответа от полосатого DHCP сервера.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

chirva_a_s, а как Вы обходите обновление порта mpd? Ведь все правки исходника слетят.

Так он вроде и не правит ничего в mpd, только в /usr/src. Кстати у меня точно так же, я тоже патчу дхцп клиента.

 

Моя практическая реализация мало кому нужна, поскольку у меня не только одна корбина воткнута в эту машину, однако же если вы так настаиваете, могу показать как оно у меня работает. Учтите - никакого закопипастил и само работает в моем решении нет. Всё ручками :)

Итак:

Выдержки из rc.conf:

synchronous_dhclient="YES"

ifconfig_em1="DHCP"

defaultrouter="10.195.24.1"

static_routes="corbinabras1 corbinabras2"

route_brassubnets1="78.107.1.0/24 10.195.24.1"

route_brassubnets2="85.25.0.0/24 10.195.24.1"

mpd_enable="YES"

 

mpd.conf вы уже видели. Без скриптовых костылей всё подымается сразу после перезагрузки системы, никакие sleepы нигде не требуются (ну кроме тормозов с получением ответа от полосатого DHCP сервера.

Ну Вы, конечно индивид,... у самого два провайдера, а предлагаете решения для простых смертных домашних юзверей с одним кабельком))))) Это Вам все понятно, а те кто только хотят узнать как к пчеловодам законнектиться до таких забот расти и расти....

Таки да, у Вас особенный случай и обычному пользователю (читай выше) это не подойдет, а в Вашем случае советов быть не может - такое только знающий человек себе может сделать.

У меня все проще:

Вот мой состав rc.conf в части касаемой внешнего сетевого адаптера (vr0) и самого MPD:

ifconfig_vr0="DHCP"

ifconfig_vr0="SYNCDHCP"

mpd_enable="YES"

mpd_flags="-b"

Конфиг MPD и скриптов up/down - как и в моей статье. Ну и правка исходников DHCP-клиента (ну да и у Вас так же)

Этого достаточно для стабильного коннекта. Вот если бы Кто смог попробовать такой вариант в Москве, да отписаться - было бы интересно...

А sleep, кстати, тоже "костылем" не назовешь - просто стоит обождать, пока система "почувствует", что маршруты поменялись и все остальное корректно будет работать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

set iface addrs 0.0.0.0 !1.2.3.4 - му подменяем IP адрес BRAS'a внутри тоннеля

set iface route 0.0.0.0/1

set iface route 128.0.0.0/1 - а этими двумя маршрутами изящно обходим дефолтроут в локалку, который можно оставлять старым.

Проверил на FreeBSD 8.3, работает это все у вас потому, что маршруты до BRAS-ов прописаны статикой.

static_routes="corbinabras1 corbinabras2"

route_brassubnets1="78.107.1.0/24 10.195.24.1"

route_brassubnets2="85.25.0.0/24 10.195.24.1"

Здесь кстати муть какая-то. Должно быть:

static_routes="brassubnets1 brassubnets2"

route_brassubnets1="78.107.1.0/24 10.195.24.1"

route_brassubnets2="85.25.0.0/24 10.195.24.1"

Тогда да метрики назначаются правильно и VPN имеет больший приоритет.

 

Но стоит настроить получение маршрутов по DHCP, без статики, то пропадает маршрут до BRASS-а через 10.195.24.1 (на вашем примере) и все перестаёт работать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я конечно извеняюсь, но неужели никто документацию не читает?

Опция

set iface default route

для кого придумана?

несколько лет уже мусолят эти костыли вокруг роутов кошмар какой-то...

на ppp тоже

add! default HISADDR

тоже так и не нашли...

маршруты решаются правкой dhclient.conf/dhclient-script

ну и напоследок: есть такая команда "route change" ....

 

Читайте и доки и исходники, хоть иногда, удачи Всем

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах