форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Открытые системы на сервере (VPN)
Изначальное сообщение		[ Отслеживать ]

"уход от VPN сервера, немного практики"	+/–
Сообщение от 2ihi (ok) on 24-Дек-10, 18:36
Суть вопроса - однозначный ответ по моей "затее", а именно: исторически сложилось так, что интернет раздается в сети через ВПН, горя с ним много повидали (маршрутизация, авторизация, вычислительные мощности итд), по сему была проведена работа по защите несанкционированного доступа в сеть (привязка мак+ип), площадка для ухода от ВПН подготовлена, сказать всем мол завтра ВПН более не нужно подключать не выход, всегда найдется тот кто новости не читает, либо просто ничего не понимает и делать естественно не хочет, по этому нужно как-то сделать так, чтоб все было гладко, тихо и спокойно для конечного потребителя услуг. 5 минут назад меня посетила мысль, 1. а что если впн не останавливать а просто авторизовать всех на прежних условиях с некоторыми послаблениями в авторизации - пускать всех с любыми комбинациями логин-пароль; 2. не поднимать дефолтный шлюз на абонентской машине; собственно кто может сказать однозначно, реализуемо ли это на MPD 5.3 во FreeBSD, чтоб коннект поднимался, а локальную виндовую таблицу маршрутизации это не затрагивало..? второй подвопросик, как поведут себя домашние роутеры типа длинк дир-XXX, поймут ли они такое извращение? Не плодил бы тему, если б на работе сидел, все проверить получится только в понедельник, а любопытство раздирает :) 2 недели планы вынашивали как более мягко все это провернуть, а тут осенило..
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "уход от VPN сервера, немного практики"	+/–
Сообщение от Square (ok) on 24-Дек-10, 19:50
> была проведена работа по защите несанкционированного доступа в сеть (привязка мак+ип), Вы идиоты? Вы в курсе что комбинацию мак+ип можно изменить в любой ОС произвольным образом? Именно по этой причине в домашних сетях используют PPTP-PPPoE, или выносят периметр безопасности ближе к пользователю(авторизуя его на порту подключения).
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "уход от VPN сервера, немного практики"	+/–
Сообщение от Аноним (??) on 24-Дек-10, 19:51
Если "привязка мак+ип" в вашем понимании для тех кто не относится к таким кто "просто ничего не понимает и делать естественно не хочет", то удачи!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "уход от VPN сервера, немного практики"	+/–
	Сообщение от 2ihi (ok) on 24-Дек-10, 19:57
	эм, я не так выразился, IP+MAC port binding + DHCP Snooping на порту юзера. вопрос не в этом. корче если на порту свича мак отличный от мака юзера, то траф не ходит. повторю вопрос, возможно ли средствами МПД дать возможность поднимать коннект анониму, и не менять его таблицу маршрутизации "новыми" дефолтными шлюзами, потенциально интересует клиент ms windows и сохороутерты.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	4. "уход от VPN сервера, немного практики"	+/–
	Сообщение от Aquarius (ok) on 24-Дек-10, 20:58
	> эм, я не так выразился, IP+MAC port binding + DHCP Snooping на > порту юзера. вопрос не в этом. корче если на порту свича > мак отличный от мака юзера, то траф не ходит. > повторю вопрос, возможно ли средствами МПД дать возможность поднимать коннект анониму, > и не менять его таблицу маршрутизации "новыми" дефолтными шлюзами, потенциально интересует > клиент ms windows и сохороутерты. IMHO, маршрут устанавливается клиентской стороной и никак с серверной стороны не контролируется
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	5. "уход от VPN сервера, немного практики"	+/–
	Сообщение от 2ihi (ok) on 24-Дек-10, 22:03
	> IMHO, маршрут устанавливается клиентской стороной и никак с серверной стороны не контролируется да, но шлюз берется с сервера, не помню на вскидку параметр и лезть уже лениво, пиво+ночь делает свое дело :) а по поводу "прозрачной" авторизации?
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	6. "уход от VPN сервера, немного практики"	+/–
	Сообщение от Square (ok) on 24-Дек-10, 22:10
	>> IMHO, маршрут устанавливается клиентской стороной и никак с серверной стороны не контролируется > да, но шлюз берется с сервера, не помню на вскидку параметр и > лезть уже лениво, пиво+ночь делает свое дело :) > а по поводу "прозрачной" авторизации? Если свичи поддерживают портсекюрити, то авторизация вообще не нужна.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	7. "уход от VPN сервера, немного практики"	+/–
	Сообщение от 2ihi (ok) on 25-Дек-10, 08:10
	> Если свичи поддерживают портсекюрити, то авторизация вообще не нужна. нужно сделать так, чтоб у народа вопросов не возникло, до кого дойдет что впн-а нет, до того дойдет, кто не сообразит - пускай куклу поднимает, связь все равно по локалу пойдет.. Вот для чего это затеяно...
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	11. "уход от VPN сервера, немного практики"	+/–
	Сообщение от PavelR (??) on 25-Дек-10, 09:28
	>> Если свичи поддерживают портсекюрити, то авторизация вообще не нужна. > нужно сделать так, чтоб у народа вопросов не возникло, до кого дойдет > что впн-а нет, до того дойдет, кто не сообразит - пускай > куклу поднимает, связь все равно по локалу пойдет.. Вот для чего > это затеяно... запустите белую и серую сети в параллель. Обеспечьте возможность работы как по старой, так и по-новой схеме параллельно. Я думаю, с этим вопросов не должно возникнуть. Если есть - задавайте. Сформируйте "кнопку", нажав на которую абонент заблокирует свой впн-аккаунт, информируя вас о том, что он уже готов работать напрямую. Желательно, в обработке нажатия кнопки проверить, что абонент действительно зашел со своего адреса и при этом он зашел не по впн, в противном случае отправить его на правила. Проанонсируйте на внутрисетевых ресурсах правила перехода со старой схемы на новую. Внятно распишите, чтобы всем было понятно. Особо активным абонентам (посмотрите статистику трафика) - можно отдельно позвонить и проинформировать их о плюсах перехода на новую схему (повысится скорость, удобство, уменьшится нагрузка на процессор, повысится стабильность работы интернета) и т п Расскажите отдельно про "кнопку". Дальше они к друзьям товарищам сходят и им перенастроят всё сами, вашей ТП меньше работы... Отслеживайте динамику перехода.  Последних "протупивших" проинформируйте также отдельно, помогите им переехать на новую схему. --- Предпочительнее адреса раздавать по DHCP. Но тут может возникнуть накладка, если серые адреса тоже раздавались по DHCP. Тогда надо сделать кнопку, которая будет нажиматься пользователем до переконфигурации. В общем случае, тогда ему будет достаточно отключиться от впн (что тоже можно проверить в скрипте), а затем переподнять сетевой интерфейс (либо подождать часок без интернета, чтобы dhcp-клиент перезапросил новый адрес (вы же выставите в dhcpd время аренды айпи на очччень малое время, ведь так ? :-))) ) и быть в "прямом интернете". Ну а нажатие на кнопку сконфигурит, какой айпи выдать абоненту - серый или белый. Ну и впн-аккаунт отключит, чтобы была точка невозврата :-)  Привязка на порту в этот момент должна уже быть "правильной" - либо измениться по нажатию кнопки абонентом, либо, что лучше (менее глючно :-) )   - на порту должны быть привязаны оба адреса, белый и серый. Серые потом поубираете... для всех, кто кнопочки понажимал =)
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	15. "уход от VPN сервера, немного практики"	+/–
	Сообщение от PavelR (??) on 25-Дек-10, 09:52
	> Серые потом поубираете... для всех, кто кнопочки понажимал =) Нажатие на кнопку для абонента должно быть обязательно (например, до нажатия кнопки по прямой конфигурации не будет доступен интернет, а только локальные ресурсы), чтобы вы могли проконтролировать процесс (процент) перехода, кто по-старому, кто по-новому и т п
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	16. "уход от VPN сервера, немного практики"	+/–
	Сообщение от 2ihi (ok) on 25-Дек-10, 09:58
	отработать 2 схемы не получится в силу того что основной маршрутизатор инета будет переведен во внешнюю транзитную сеть, корневой роутер (дефолтный для юзера) будет центральным БГП который загромождать в цепочку с ВПНами проблематично. Да и цели пока не стоит всех переташить на реальники. >Внятно распишите, чтобы всем было понятно. вот тут самые проблемы, за 9 лет уже вроде и пишим так что собака поймет, тем не менее есть вундеркинды и их не мало :)) >Привязка на порту в этот момент должна уже быть "правильной" - либо измениться по нажатию кнопки абонентом, либо, что лучше (менее глючно :-) )   - на порту должны быть привязаны оба адреса, белый и серый. на порту все настроено, мак вбит, а ДХЦП снупинг свою работу сделает. я понимаю вас как творческого человека, у нас техдиректор подобную схему придумал, но на реализацию уйдет времени очень прилично, тем более с нашими нюансами, которые я слегка в первой части сообщения описал.. вместе с отказом от ВПН хочется освободить сервера, им уже придумана новая роль, да и железо там приличное.. а в качестве псевдо-впна поставить какойньть простенький компутер, стерминировать 5-10к коннектов без кача ему будет по силам :)
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	17. "уход от VPN сервера, немного практики"	+/–
	Сообщение от PavelR (??) on 25-Дек-10, 10:19
	> отработать 2 схемы не получится в силу того что основной маршрутизатор инета > будет переведен во внешнюю транзитную сеть не совсем понял, а сейчас как ?  тут надо на детали переходить... > корневой роутер (дефолтный для юзера) будет центральным БГП который загромождать в цепочку с ВПНами проблематично. ну и пусть будет, в чем проблематичность - я не понимаю. у серверов, которые терминируют впны, есть интерфейс внешней стороны, на котором висят сети с реальными адресами.. Если нет такого интерфейса, а просто по внутренней сети между рутером и серверами маршрутизируются подсети реальных адресов, то создаете такой интерфейс (vlan), переносите маршрутизацию (адрес шлюза по умолчанию, выдаваемый клиентам по впн (хотя это особой роли не играет, поскольку интерфейс точка-точка) и в настройках дхцп по новой схеме) на роутер,  Включаете proxyarp в настройках впн-сервера... В этот же вилан загоняете клиентов, подключившихся без впн-а. > Да и цели пока не стоит всех переташить на реальники.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	20. "уход от VPN сервера, немного практики"	+/–
	Сообщение от 2ihi (ok) on 25-Дек-10, 11:24
	> не совсем понял, а сейчас как ?  тут надо на детали > переходить... сейчас юзера могут ходить через ВПН и без ВПН, со вторыми все понятно у них только шлюз поменяется в ДХЦП, а вот первые... первые могут получать ИП как реальный, так и серый, летит все это дело на VPN, впнсервер получет пакет и смотрит куда его передать - пиринговые сети на бгп роутер или интернет, в пириг адреса ВПНтунелей не анонсированы, по этому там возникает НАТ и прочие прелести, пиринг часто обновляется анонсами, короче ппц, с инетом все проще, АС нету. тот же БГП роутер на пиринге является всем в сети дефолтным шлюзом, маршрутизация с поднятым и опущеным ВПНом на юзерской машине идет разными путями, есть забитый костыль - народу прописаны основные пиринговые адреса вида 172.*.*.* вот такой огород накручен :)
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

8. "уход от VPN сервера, немного практики"	+/–
Сообщение от Grey (ok) on 25-Дек-10, 09:03
ИМХО: бредовая затея. 1. рано или поздно, все приходят к некоей авторизации клиентов для доступа в инет (или локальным ресурсам провайдера). 2. п.1 всплывает не от безделия. 3. без pptp/pppoe, как вы намеряны давать белые адреса клиентам? 4. если п.3 вообще не предусмотрен в процессе развития - вам как провайдеру видимо очень мало лет ещё или для вас это игрушки. 5. по опыту: ситуация, когда вкл. компьютер и уже в инете очень часто мешает. 6. настройка pptp/pppoe на клиенте - дело не сложное и в большинстве случаев понятное. проблемы с маршрутами и т.п. - надумано, а домохозяйкам что pptp, что вирусня на компе - всё едино. 7. вычеслительные мощности вашего pptp/pppoe сервера? ну тут вам и карты в руки, что-то мне кажется что у вас не десятки тысяч клиентов. Если горя повидали с сервером - просто "вы его не умеете готовить", видимо. P.S. то что вы хотите скорее всего можно сделать, но если вам больше не начто потратить время и силы (а также бессонные ночи и нервы при общением с клиентами), то удачи вам, совершенно искенне, удачи. без обид и понтов, просто я бы так делать у себя в сети не стал.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	9. "уход от VPN сервера, немного практики"	+/–
	Сообщение от PavelR (??) on 25-Дек-10, 09:15
	> ИМХО: бредовая затея. > 1. рано или поздно, все приходят к некоей авторизации клиентов для доступа > в инет (или локальным ресурсам провайдера). > 2. п.1 всплывает не от безделия. Авторизации по IP - достаточно. > 3. без pptp/pppoe, как вы намеряны давать белые адреса клиентам? Посредством прямого выделение белого айпи по Ethernet. Очень глупый вопрос, задан так, как будто без pptp/pppoe этого сделать нельзя. > 4. если п.3 вообще не предусмотрен в процессе развития - вам как > провайдеру видимо очень мало лет ещё или для вас это игрушки. > 5. по опыту: ситуация, когда вкл. компьютер и уже в инете очень > часто мешает. Кому мешает ? приведите ситуации. (паленый софт ставить, который при установке черные списки проверяет ? мешает, наверное  :-))) ) >[оверквотинг удален] > случаев понятное. проблемы с маршрутами и т.п. - надумано, а домохозяйкам > что pptp, что вирусня на компе - всё едино. > 7. вычеслительные мощности вашего pptp/pppoe сервера? ну тут вам и карты в > руки, что-то мне кажется что у вас не десятки тысяч клиентов. > Если горя повидали с сервером - просто "вы его не умеете > готовить", видимо. > P.S. то что вы хотите скорее всего можно сделать, но если вам > больше не начто потратить время и силы (а также бессонные ночи > и нервы при общением с клиентами), то удачи вам, совершенно искенне, > удачи. ну так потому чел и пришел на форум, поскольку думает о том, как бы в процессе переконфигурации спать по ночам побольше =) > без обид и понтов, просто я бы так делать у себя в > сети не стал. десятками тысяч раздаются белые айпи по проводу напрямую, и никаких проблем нет.... --------
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	10. "уход от VPN сервера, немного практики"	+/–
	Сообщение от 2ihi (ok) on 25-Дек-10, 09:22
	> 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 - вам лично не дам :)
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	12. "уход от VPN сервера, немного практики"	+/–
	Сообщение от PavelR (??) on 25-Дек-10, 09:30
	> судя по вопросам я про вас такое подумал. надоело маршрутизировать локал отдельно > от впн-а, надоели обмены маршрутами корневых роутеров с ВПН серверами, под > ВПНами щас стоят SUN Fire-ы, с 4х головыми процами и нехватает, > представьте нагруз. (в час пик 100метров прокач, сетевухи не вывозят) Эмм, ОС - фряха ?
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	13. "уход от VPN сервера, немного практики"	+/–
	Сообщение от 2ihi (ok) on 25-Дек-10, 09:40
	> Эмм, ОС - фряха ? Да, 7.2, карты интел, дрова яндекс, юз нетграфом 30-40% от кадого ядра, сетевухи прогружаются до 100% по потоку, короче это пипец, на сервер 2-2.5к сессий еще на каждом работает pf nat, который натит в пиринг поднятые тунели, но практика показывает что на фоне всего остального нат ресурсы не жрет а нюхает, в качестве теста выносил нат на свичи (extreme), кординально ничего не поменялось.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	14. "уход от VPN сервера, немного практики"	+/–
	Сообщение от PavelR (??) on 25-Дек-10, 09:50
	>> Эмм, ОС - фряха ? > Да, 7.2, карты интел, дрова яндекс, юз нетграфом 30-40% от кадого ядра, > сетевухи прогружаются до 100% по потоку, короче это пипец, на сервер > 2-2.5к сессий > еще на каждом работает pf nat, который натит в пиринг поднятые тунели, > но практика показывает что на фоне всего остального нат ресурсы не > жрет а нюхает, в качестве теста выносил нат на свичи (extreme), > кординально ничего не поменялось. http://www.opennet.me/openforum/vsluhforumID1/90616.html#11 ?
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	19. "уход от VPN сервера, немного практики"	+/–
	Сообщение от guest (??) on 25-Дек-10, 10:26
	> Да, 7.2, карты интел, дрова яндекс, юз нетграфом 30-40% от кадого ядра, > сетевухи прогружаются до 100% по потоку, короче это пипец, на сервер > 2-2.5к сессий На прошлой работе мы ушли на линукс с accel-pptp, профит реально огромный.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

18. "уход от VPN сервера, немного практики"	+/–
Сообщение от guest (??) on 25-Дек-10, 10:23
> 2. не поднимать дефолтный шлюз на абонентской машине; АФАИР в винде галочка "Use default gateway on remote network" по умолчанию включена, т.е. если в изначальной инструкции по подключению к вашей сети не было сказано снять ее, то не без ручных манипуляций со стороны пользователя не обойтись.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	21. "уход от VPN сервера, немного практики"	+/–
	Сообщение от 2ihi (ok) on 25-Дек-10, 11:27
	>> 2. не поднимать дефолтный шлюз на абонентской машине; > АФАИР в винде галочка "Use default gateway on remote network" по умолчанию > включена, т.е. > если в изначальной инструкции по подключению к вашей сети не было сказано > снять ее, то не без ручных манипуляций со стороны пользователя не > обойтись. это все понятно, я имел ввиду исключить строку set ipcp ranges defaultrtr/32 ippool poolsat из конфига сервера МПД
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	22. "уход от VPN сервера, немного практики"	+/–
	Сообщение от guest (??) on 25-Дек-10, 12:11
	> это все понятно, я имел ввиду исключить строку > set ipcp ranges defaultrtr/32 ippool poolsat > из конфига сервера МПД По идее сделав так вы получите "IPCP: not converging" в лог и на этом все кончится.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	23. "уход от VPN сервера, немного практики"	+/–
	Сообщение от 2ihi (ok) on 25-Дек-10, 12:27
	> По идее сделав так вы получите "IPCP: not converging" в лог и > на этом все кончится. это уже хуже... короче нужен сервер чтоб проверять :)
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	24. "уход от VPN сервера, немного практики"	+/–
	Сообщение от Sot on 26-Дек-10, 19:12
	> я имел ввиду исключить строку > set ipcp ranges defaultrtr/32 ippool poolsat > из конфига сервера МПД Заинтересовала идея. Попробовал у себя. Как ни странно, ничего не поменялось. Маршрут по умолчанию все равно был прописан и все продолжило работать как раньше :(
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема