Суть вопроса - однозначный ответ по моей "затее", а именно:исторически сложилось так, что интернет раздается в сети через ВПН, горя с ним много повидали (маршрутизация, авторизация, вычислительные мощности итд), по сему была проведена работа по защите несанкционированного доступа в сеть (привязка мак+ип), площадка для ухода от ВПН подготовлена, сказать всем мол завтра ВПН более не нужно подключать не выход, всегда найдется тот кто новости не читает, либо просто ничего не понимает и делать естественно не хочет, по этому нужно как-то сделать так, чтоб все было гладко, тихо и спокойно для конечного потребителя услуг. 5 минут назад меня посетила мысль,
1. а что если впн не останавливать а просто авторизовать всех на прежних условиях с некоторыми послаблениями в авторизации - пускать всех с любыми комбинациями логин-пароль;
2. не поднимать дефолтный шлюз на абонентской машине;собственно кто может сказать однозначно, реализуемо ли это на MPD 5.3 во FreeBSD, чтоб коннект поднимался, а локальную виндовую таблицу маршрутизации это не затрагивало..?
второй подвопросик, как поведут себя домашние роутеры типа длинк дир-XXX, поймут ли они такое извращение?
Не плодил бы тему, если б на работе сидел, все проверить получится только в понедельник, а любопытство раздирает :) 2 недели планы вынашивали как более мягко все это провернуть, а тут осенило..
> была проведена работа по защите несанкционированного доступа в сеть (привязка мак+ип),Вы идиоты?
Вы в курсе что комбинацию мак+ип можно изменить в любой ОС произвольным образом?
Именно по этой причине в домашних сетях используют PPTP-PPPoE, или выносят периметр безопасности ближе к пользователю(авторизуя его на порту подключения).
Если "привязка мак+ип" в вашем понимании для тех кто не относится к таким кто "просто ничего не понимает и делать естественно не хочет", то удачи!
эм, я не так выразился, IP+MAC port binding + DHCP Snooping на порту юзера. вопрос не в этом. корче если на порту свича мак отличный от мака юзера, то траф не ходит.повторю вопрос, возможно ли средствами МПД дать возможность поднимать коннект анониму, и не менять его таблицу маршрутизации "новыми" дефолтными шлюзами, потенциально интересует клиент ms windows и сохороутерты.
> эм, я не так выразился, IP+MAC port binding + DHCP Snooping на
> порту юзера. вопрос не в этом. корче если на порту свича
> мак отличный от мака юзера, то траф не ходит.
> повторю вопрос, возможно ли средствами МПД дать возможность поднимать коннект анониму,
> и не менять его таблицу маршрутизации "новыми" дефолтными шлюзами, потенциально интересует
> клиент ms windows и сохороутерты.IMHO, маршрут устанавливается клиентской стороной и никак с серверной стороны не контролируется
> IMHO, маршрут устанавливается клиентской стороной и никак с серверной стороны не контролируетсяда, но шлюз берется с сервера, не помню на вскидку параметр и лезть уже лениво, пиво+ночь делает свое дело :)
а по поводу "прозрачной" авторизации?
>> IMHO, маршрут устанавливается клиентской стороной и никак с серверной стороны не контролируется
> да, но шлюз берется с сервера, не помню на вскидку параметр и
> лезть уже лениво, пиво+ночь делает свое дело :)
> а по поводу "прозрачной" авторизации?Если свичи поддерживают портсекюрити, то авторизация вообще не нужна.
> Если свичи поддерживают портсекюрити, то авторизация вообще не нужна.нужно сделать так, чтоб у народа вопросов не возникло, до кого дойдет что впн-а нет, до того дойдет, кто не сообразит - пускай куклу поднимает, связь все равно по локалу пойдет.. Вот для чего это затеяно...
>> Если свичи поддерживают портсекюрити, то авторизация вообще не нужна.
> нужно сделать так, чтоб у народа вопросов не возникло, до кого дойдет
> что впн-а нет, до того дойдет, кто не сообразит - пускай
> куклу поднимает, связь все равно по локалу пойдет.. Вот для чего
> это затеяно...запустите белую и серую сети в параллель.
Обеспечьте возможность работы как по старой, так и по-новой схеме параллельно.
Я думаю, с этим вопросов не должно возникнуть. Если есть - задавайте.
Сформируйте "кнопку", нажав на которую абонент заблокирует свой впн-аккаунт, информируя вас о том, что он уже готов работать напрямую. Желательно, в обработке нажатия кнопки проверить, что абонент действительно зашел со своего адреса и при этом он зашел не по впн, в противном случае отправить его на правила.
Проанонсируйте на внутрисетевых ресурсах правила перехода со старой схемы на новую. Внятно распишите, чтобы всем было понятно.
Особо активным абонентам (посмотрите статистику трафика) - можно отдельно позвонить и проинформировать их о плюсах перехода на новую схему (повысится скорость, удобство, уменьшится нагрузка на процессор, повысится стабильность работы интернета) и т п Расскажите отдельно про "кнопку".
Дальше они к друзьям товарищам сходят и им перенастроят всё сами, вашей ТП меньше работы...
Отслеживайте динамику перехода. Последних "протупивших" проинформируйте также отдельно, помогите им переехать на новую схему.
---Предпочительнее адреса раздавать по DHCP. Но тут может возникнуть накладка, если серые адреса тоже раздавались по DHCP. Тогда надо сделать кнопку, которая будет нажиматься пользователем до переконфигурации. В общем случае, тогда ему будет достаточно отключиться от впн (что тоже можно проверить в скрипте), а затем переподнять сетевой интерфейс (либо подождать часок без интернета, чтобы dhcp-клиент перезапросил новый адрес (вы же выставите в dhcpd время аренды айпи на очччень малое время, ведь так ? :-))) ) и быть в "прямом интернете". Ну а нажатие на кнопку сконфигурит, какой айпи выдать абоненту - серый или белый. Ну и впн-аккаунт отключит, чтобы была точка невозврата :-) Привязка на порту в этот момент должна уже быть "правильной" - либо измениться по нажатию кнопки абонентом, либо, что лучше (менее глючно :-) ) - на порту должны быть привязаны оба адреса, белый и серый.
Серые потом поубираете... для всех, кто кнопочки понажимал =)
> Серые потом поубираете... для всех, кто кнопочки понажимал =)Нажатие на кнопку для абонента должно быть обязательно (например, до нажатия кнопки по прямой конфигурации не будет доступен интернет, а только локальные ресурсы), чтобы вы могли проконтролировать процесс (процент) перехода, кто по-старому, кто по-новому и т п
отработать 2 схемы не получится в силу того что основной маршрутизатор инета будет переведен во внешнюю транзитную сеть, корневой роутер (дефолтный для юзера) будет центральным БГП который загромождать в цепочку с ВПНами проблематично. Да и цели пока не стоит всех переташить на реальники.>Внятно распишите, чтобы всем было понятно.
вот тут самые проблемы, за 9 лет уже вроде и пишим так что собака поймет, тем не менее есть вундеркинды и их не мало :))
>Привязка на порту в этот момент должна уже быть "правильной" - либо измениться по нажатию кнопки абонентом, либо, что лучше (менее глючно :-) ) - на порту должны быть привязаны оба адреса, белый и серый.
на порту все настроено, мак вбит, а ДХЦП снупинг свою работу сделает.
я понимаю вас как творческого человека, у нас техдиректор подобную схему придумал, но на реализацию уйдет времени очень прилично, тем более с нашими нюансами, которые я слегка в первой части сообщения описал..
вместе с отказом от ВПН хочется освободить сервера, им уже придумана новая роль, да и железо там приличное.. а в качестве псевдо-впна поставить какойньть простенький компутер, стерминировать 5-10к коннектов без кача ему будет по силам :)
> отработать 2 схемы не получится в силу того что основной маршрутизатор инета
> будет переведен во внешнюю транзитную сетьне совсем понял, а сейчас как ? тут надо на детали переходить...
> корневой роутер (дефолтный для юзера) будет центральным БГП который загромождать в цепочку с ВПНами проблематично.
ну и пусть будет, в чем проблематичность - я не понимаю.
у серверов, которые терминируют впны, есть интерфейс внешней стороны, на котором висят сети с реальными адресами.. Если нет такого интерфейса, а просто по внутренней сети между рутером и серверами маршрутизируются подсети реальных адресов, то создаете такой интерфейс (vlan), переносите маршрутизацию (адрес шлюза по умолчанию, выдаваемый клиентам по впн (хотя это особой роли не играет, поскольку интерфейс точка-точка) и в настройках дхцп по новой схеме) на роутер, Включаете proxyarp в настройках впн-сервера... В этот же вилан загоняете клиентов, подключившихся без впн-а.> Да и цели пока не стоит всех переташить на реальники.
> не совсем понял, а сейчас как ? тут надо на детали
> переходить...сейчас юзера могут ходить через ВПН и без ВПН, со вторыми все понятно у них только шлюз поменяется в ДХЦП, а вот первые... первые могут получать ИП как реальный, так и серый, летит все это дело на VPN, впнсервер получет пакет и смотрит куда его передать - пиринговые сети на бгп роутер или интернет, в пириг адреса ВПНтунелей не анонсированы, по этому там возникает НАТ и прочие прелести, пиринг часто обновляется анонсами, короче ппц, с инетом все проще, АС нету.
тот же БГП роутер на пиринге является всем в сети дефолтным шлюзом, маршрутизация с поднятым и опущеным ВПНом на юзерской машине идет разными путями, есть забитый костыль - народу прописаны основные пиринговые адреса вида 172.*.*.*вот такой огород накручен :)
ИМХО: бредовая затея.
1. рано или поздно, все приходят к некоей авторизации клиентов для доступа в инет (или локальным ресурсам провайдера).
2. п.1 всплывает не от безделия.
3. без pptp/pppoe, как вы намеряны давать белые адреса клиентам?
4. если п.3 вообще не предусмотрен в процессе развития - вам как провайдеру видимо очень мало лет ещё или для вас это игрушки.
5. по опыту: ситуация, когда вкл. компьютер и уже в инете очень часто мешает.
6. настройка pptp/pppoe на клиенте - дело не сложное и в большинстве случаев понятное. проблемы с маршрутами и т.п. - надумано, а домохозяйкам что pptp, что вирусня на компе - всё едино.
7. вычеслительные мощности вашего pptp/pppoe сервера? ну тут вам и карты в руки, что-то мне кажется что у вас не десятки тысяч клиентов. Если горя повидали с сервером - просто "вы его не умеете готовить", видимо.P.S. то что вы хотите скорее всего можно сделать, но если вам больше не начто потратить время и силы (а также бессонные ночи и нервы при общением с клиентами), то удачи вам, совершенно искенне, удачи.
без обид и понтов, просто я бы так делать у себя в сети не стал.
> ИМХО: бредовая затея.
> 1. рано или поздно, все приходят к некоей авторизации клиентов для доступа
> в инет (или локальным ресурсам провайдера).
> 2. п.1 всплывает не от безделия.Авторизации по IP - достаточно.
> 3. без pptp/pppoe, как вы намеряны давать белые адреса клиентам?
Посредством прямого выделение белого айпи по Ethernet. Очень глупый вопрос, задан так, как будто без pptp/pppoe этого сделать нельзя.
> 4. если п.3 вообще не предусмотрен в процессе развития - вам как
> провайдеру видимо очень мало лет ещё или для вас это игрушки.
> 5. по опыту: ситуация, когда вкл. компьютер и уже в инете очень
> часто мешает.Кому мешает ? приведите ситуации.
(паленый софт ставить, который при установке черные списки проверяет ? мешает, наверное :-))) )>[оверквотинг удален]
> случаев понятное. проблемы с маршрутами и т.п. - надумано, а домохозяйкам
> что pptp, что вирусня на компе - всё едино.
> 7. вычеслительные мощности вашего pptp/pppoe сервера? ну тут вам и карты в
> руки, что-то мне кажется что у вас не десятки тысяч клиентов.
> Если горя повидали с сервером - просто "вы его не умеете
> готовить", видимо.
> P.S. то что вы хотите скорее всего можно сделать, но если вам
> больше не начто потратить время и силы (а также бессонные ночи
> и нервы при общением с клиентами), то удачи вам, совершенно искенне,
> удачи.ну так потому чел и пришел на форум, поскольку думает о том, как бы в процессе переконфигурации спать по ночам побольше =)
> без обид и понтов, просто я бы так делать у себя в
> сети не стал.десятками тысяч раздаются белые айпи по проводу напрямую, и никаких проблем нет....
--------
> 1. рано или поздно, все приходят к некоей авторизации клиентов для доступа
> в инет (или локальным ресурсам провайдера).авторизация на основе положительного баланса.
> 2. п.1 всплывает не от безделия.
> 3. без pptp/pppoe, как вы намеряны давать белые адреса клиентам?с ДХЦП на картру, в чем проблема?
> 4. если п.3 вообще не предусмотрен в процессе развития - вам как
> провайдеру видимо очень мало лет ещё или для вас это игрушки.судя по вопросам я про вас такое подумал. надоело маршрутизировать локал отдельно от впн-а, надоели обмены маршрутами корневых роутеров с ВПН серверами, под ВПНами щас стоят SUN Fire-ы, с 4х головыми процами и нехватает, представьте нагруз. (в час пик 100метров прокач, сетевухи не вывозят)
> 5. по опыту: ситуация, когда вкл. компьютер и уже в инете очень
> часто мешает.инетересно чем?
> 6. настройка pptp/pppoe на клиенте - дело не сложное и в большинстве
> случаев понятное. проблемы с маршрутами и т.п. - надумано, а домохозяйкам
> что pptp, что вирусня на компе - всё едино.у нас впны создаются юзерам автоматически, ему только 3 кнопки мышкой нажать и пароль с логином впсать (что бывает очень сложно порой)
> 7. вычеслительные мощности вашего pptp/pppoe сервера? ну тут вам и карты в
> руки, что-то мне кажется что у вас не десятки тысяч клиентов.
> Если горя повидали с сервером - просто "вы его не умеете
> готовить", видимо.горя повидали с маршрутизацией, все работает криво, т.к. через ВПН маршрутить 100ку в пиринги и прочее - захлебнет любой сервер. про мощности я уже выше сказал что за сервера стоят, думаю вы таких названий не слышали.
> P.S. то что вы хотите скорее всего можно сделать, но если вам
> больше не начто потратить время и силы (а также бессонные ночи
> и нервы при общением с клиентами), то удачи вам, совершенно искенне,
> удачи.трата времени - час вместе с поднятием фри, настройки быстрой впна, в случае не возможности прозрачной авторизации - правим исходники (думаю час), про общение с юзерами - именно для этого и придуман сей финт чтоб избежать юзерского наплыва.
> без обид и понтов, просто я бы так делать у себя в
> сети не стал.Думаю когда перевалите за 10К юзеров, начнут мысли посещать подобные, когда встание перед выбором, либо 10G фуллспид аппаратный ВПН, либо пошло оно все нахер, то вспомните мои слова и мои идеи :) если дойдет до правки исходников MPD - вам лично не дам :)
> судя по вопросам я про вас такое подумал. надоело маршрутизировать локал отдельно
> от впн-а, надоели обмены маршрутами корневых роутеров с ВПН серверами, под
> ВПНами щас стоят SUN Fire-ы, с 4х головыми процами и нехватает,
> представьте нагруз. (в час пик 100метров прокач, сетевухи не вывозят)Эмм, ОС - фряха ?
> Эмм, ОС - фряха ?Да, 7.2, карты интел, дрова яндекс, юз нетграфом 30-40% от кадого ядра, сетевухи прогружаются до 100% по потоку, короче это пипец, на сервер 2-2.5к сессий
еще на каждом работает pf nat, который натит в пиринг поднятые тунели, но практика показывает что на фоне всего остального нат ресурсы не жрет а нюхает, в качестве теста выносил нат на свичи (extreme), кординально ничего не поменялось.
>> Эмм, ОС - фряха ?
> Да, 7.2, карты интел, дрова яндекс, юз нетграфом 30-40% от кадого ядра,
> сетевухи прогружаются до 100% по потоку, короче это пипец, на сервер
> 2-2.5к сессий
> еще на каждом работает pf nat, который натит в пиринг поднятые тунели,
> но практика показывает что на фоне всего остального нат ресурсы не
> жрет а нюхает, в качестве теста выносил нат на свичи (extreme),
> кординально ничего не поменялось.http://www.opennet.me/openforum/vsluhforumID1/90616.html#11 ?
> Да, 7.2, карты интел, дрова яндекс, юз нетграфом 30-40% от кадого ядра,
> сетевухи прогружаются до 100% по потоку, короче это пипец, на сервер
> 2-2.5к сессийНа прошлой работе мы ушли на линукс с accel-pptp, профит реально огромный.
> 2. не поднимать дефолтный шлюз на абонентской машине;АФАИР в винде галочка "Use default gateway on remote network" по умолчанию включена, т.е.
если в изначальной инструкции по подключению к вашей сети не было сказано снять ее, то не без ручных манипуляций со стороны пользователя не обойтись.
>> 2. не поднимать дефолтный шлюз на абонентской машине;
> АФАИР в винде галочка "Use default gateway on remote network" по умолчанию
> включена, т.е.
> если в изначальной инструкции по подключению к вашей сети не было сказано
> снять ее, то не без ручных манипуляций со стороны пользователя не
> обойтись.это все понятно, я имел ввиду исключить строку
set ipcp ranges defaultrtr/32 ippool poolsat
из конфига сервера МПД
> это все понятно, я имел ввиду исключить строку
> set ipcp ranges defaultrtr/32 ippool poolsat
> из конфига сервера МПДПо идее сделав так вы получите "IPCP: not converging" в лог и на этом все кончится.
> По идее сделав так вы получите "IPCP: not converging" в лог и
> на этом все кончится.это уже хуже... короче нужен сервер чтоб проверять :)
> я имел ввиду исключить строку
> set ipcp ranges defaultrtr/32 ippool poolsat
> из конфига сервера МПДЗаинтересовала идея. Попробовал у себя. Как ни странно, ничего не поменялось. Маршрут по умолчанию все равно был прописан и все продолжило работать как раньше :(