Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 81
коллега, а зачем вообще такое извращение, почему не хочется кучку (254) хостов засунуть в один влан нормальным образом?
Что плохого в том, что пользователи находятся в одном L2?
Ну это зависит от количества пользователей. Сотня пользователей в одном бродкаст-домене (L2) — ничего особо страшного. Тысяча — катастрофа, одним бродкаст-пингом можно положить всю сеть. Конечно, активное сетевое оборудование может бороться с штормами, но не стоит делать большие бродкаст-домены, полагаясь только на эту защиту.
Ну, зачем экстримизм? /24-23 сетка — более чем достаточно.
коллега, шторма не будет, если нет L2-петель. Бродкастов много, за счет ARP, netbios и т.п., но это не шторм в классическом понимании, когда множится один и тот же кадр за счет петли.
Если петли есть, шторм будет в любом случае.
А безопастность пользователя в целом вы не рассматриваете как класс? Vlan-per-user решает все гипотетические проблемы одним движением.
Вы меня спрашивали? а какие, простите, реальные (не из учебников) проблемы Вы предлагаете рассматривать? разные VLAN сами режут только бродкастный трафик. доступ между юзерами одной сети обычно почти полный. А потом, если у меня белый IP, бояться внутренних стоит не больше внешних.
Мне как провайдеру приятно знать что трафик (бродкасты, мультикасты, пошареные на запись диски Цэ:) хоть немного контролируется.
К счастью я не теоретик.
К счастью я не теоретик.
если пользователь настолько туп — он найдет себе головную боль и без бродкастов. А вот нормальным пользователям жизнь испортить можно. Впрочем, это дело каждого провайдера.
А вы обладаете статистикой соотношения «нормальных» пользователей к «ненормальным»?
Имею на даный момент прибивание мака к порту-vlan-per-user-прибивание айпишки к маку. Никто не жалуется кажись. Через местную фтп-помойку очень успешно юзера могут поменятся своей порнухой чтобы не «слать письма гмылом».
Предчувствую что сейчас адепты-теоретики рррое и прочих танцев вокруг mpd начнут плакать о том что «ай бедный пользователь меняет минимум 3 раза в неделю мать-сетевуху и напрягает этим саппорт»…
С ppp(dialup)/ pppoe (xdsl/802.11)/ pptp (docsis) за предыдущих ~10 лет на старой работе я уже насмотрелся и на «ошибку 619» и на «ввожу пароль восемь звездочек и не работает» и на «ой сессия повисла, лцп не отстрелило» — практика показывает, что проблем для сапорта есть несравнимо меньше (девочка на телефоне обучается ровно за 3 часа нахождению маков в ХР/Висте/7 в случае если пользователь таки поменял сетевуху)
Там выше кажись были доводы в пользу тунелек на тему «ой корбина» или «вон у еще [вставьте любого монстра]» используют рррое — значит это круто. Хоть кто-то из послылающихся на эти конторы пробовал посчитать стоимость смены метода авторизации-аутентификации для такого количества пользователей? У монстров чуть другая экономика и реалии чем у «домашней сетки вовки с третьего подъезда»
Когда мне представилась возможность строить большую сеть с нуля я был счастлив отказаться от костылей и упереться в дхцп с опшн82. Думаю многие другие тоже желалибы. На Украине есть наглядный пример такого подхода построенного недавно — Триолан, например.
Имею на даный момент прибивание мака к порту-vlan-per-user-прибивание айпишки к маку. Никто не жалуется кажись. Через местную фтп-помойку очень успешно юзера могут поменятся своей порнухой чтобы не «слать письма гмылом».
Предчувствую что сейчас адепты-теоретики рррое и прочих танцев вокруг mpd начнут плакать о том что «ай бедный пользователь меняет минимум 3 раза в неделю мать-сетевуху и напрягает этим саппорт»…
С ppp(dialup)/ pppoe (xdsl/802.11)/ pptp (docsis) за предыдущих ~10 лет на старой работе я уже насмотрелся и на «ошибку 619» и на «ввожу пароль восемь звездочек и не работает» и на «ой сессия повисла, лцп не отстрелило» — практика показывает, что проблем для сапорта есть несравнимо меньше (девочка на телефоне обучается ровно за 3 часа нахождению маков в ХР/Висте/7 в случае если пользователь таки поменял сетевуху)
Там выше кажись были доводы в пользу тунелек на тему «ой корбина» или «вон у еще [вставьте любого монстра]» используют рррое — значит это круто. Хоть кто-то из послылающихся на эти конторы пробовал посчитать стоимость смены метода авторизации-аутентификации для такого количества пользователей? У монстров чуть другая экономика и реалии чем у «домашней сетки вовки с третьего подъезда»
Когда мне представилась возможность строить большую сеть с нуля я был счастлив отказаться от костылей и упереться в дхцп с опшн82. Думаю многие другие тоже желалибы. На Украине есть наглядный пример такого подхода построенного недавно — Триолан, например.
я не за туннели. Я как раз за привязку по маку. Просто считаю целесообразным не плодить по влану на юзера, а группировать их разумное количество (/24) в одну.
Мой провайдер использует как раз такую схему, сам пользуюсь уже около 5ти лет, особых проблем не наблюдаю и не читал о них в форуме.
Мой провайдер использует как раз такую схему, сам пользуюсь уже около 5ти лет, особых проблем не наблюдаю и не читал о них в форуме.
А что васе из 172.16.2.3 будет от этого сильно легче раз вова пообещавший ему колекцию private будет с 172.16.7.3 в случае ваших этих самых «по /24»?
Тогда уж логичнее vlan на дом как бюджетный вариант (а на дом уж и мыльницы можно тогда ставить — эх! вспомним 90-00-е...). Тогда раз уж вася и вова живут в одном доме у них будет шанс на порнуху в обход ядра сети и даже возможно local peer discovery =)
Тогда уж логичнее vlan на дом как бюджетный вариант (а на дом уж и мыльницы можно тогда ставить — эх! вспомним 90-00-е...). Тогда раз уж вася и вова живут в одном доме у них будет шанс на порнуху в обход ядра сети и даже возможно local peer discovery =)
И из-за этого «одного движения» я не могу связаться с компом соседа без использования сторонних сервисов. Файлы друг другу через Америку (gmail)шлём. А раньше, пока не решили «позаботиться» о нашей «безопасности» дальше провайдерской сетки выходить не надо было.
Ну это не проблема технологии, это проблема провайдера.
Я тоже думаю, что глупо блокировать возможность пользователей обмениваться трафиком, это лишь приведет к возрастанию нагрузки на внешние каналы.
Я тоже думаю, что глупо блокировать возможность пользователей обмениваться трафиком, это лишь приведет к возрастанию нагрузки на внешние каналы.
1. Я сделаю откровение если расскажу что в 802.1q может быть более одного порта в влане? :)
2. Во времена kaht2 в вот таких вот сеточках было очень занятно. Более чем уверен что и сейчас есть аналоги.
2. Во времена kaht2 в вот таких вот сеточках было очень занятно. Более чем уверен что и сейчас есть аналоги.
Это мнение идет откуда-то из середины 80-х, когда коммутаторы — это было что-то неизвестное, а хабы и репитеры — более-менее привычное. :-) Примерно оттуда же и классическое «Правило 5-4-3» и прочие подобные изыски. :-)
На самом деле если на уровне доступа используются нормальные коммутаторы, на которых нормально настроена фильтрация — L2 сегмент может быть практически сколь угодно большим. Пусть сетевые циско-гуру закидывают меня тапками, но я сам делал L2 сегмент примерно на 3 тыс. пользователей и все работало просто отлично. Разумеется, перед этим пришлось потратить время и адекватно настроить/оттестить конфигурацию коммутаторов (использовались банальные Длинки 3526, 3028, 3326gsr на агрегации и 3610 стоял «над всеми» и роутил L3), но потом в течении около двух лет до того, как я уволился из той организации (и, насколько я в курсе, сейчас без меня все аналогично), не было ни единого широковещательного шторма и вообще каких-либо проблем. При этом, разумеется, в сети, как водится, была куча неадекватных деятелей, вирусни и прочей обычной атрибутики. В самое загруженное вечернее время количество широковещательных пакетов (был разрешен, разумеется, только arp) не превышало 10-20 в секунду.
Я, разумеется, не призываю всех делать также, но в Москве так делают многие, в т.ч. и «большие» провайдеры типа Билайна (видел лично) или НетБайНета. Собственно, если доступ в интернет идет через туннели, то так само и просится избавится от необходимости ворочать на уровнях ближе к ядру весь этот дурацкий локальный пользовательский трафик — лучше один раз нормально настроить коммутаторы и забыть…
На самом деле если на уровне доступа используются нормальные коммутаторы, на которых нормально настроена фильтрация — L2 сегмент может быть практически сколь угодно большим. Пусть сетевые циско-гуру закидывают меня тапками, но я сам делал L2 сегмент примерно на 3 тыс. пользователей и все работало просто отлично. Разумеется, перед этим пришлось потратить время и адекватно настроить/оттестить конфигурацию коммутаторов (использовались банальные Длинки 3526, 3028, 3326gsr на агрегации и 3610 стоял «над всеми» и роутил L3), но потом в течении около двух лет до того, как я уволился из той организации (и, насколько я в курсе, сейчас без меня все аналогично), не было ни единого широковещательного шторма и вообще каких-либо проблем. При этом, разумеется, в сети, как водится, была куча неадекватных деятелей, вирусни и прочей обычной атрибутики. В самое загруженное вечернее время количество широковещательных пакетов (был разрешен, разумеется, только arp) не превышало 10-20 в секунду.
Я, разумеется, не призываю всех делать также, но в Москве так делают многие, в т.ч. и «большие» провайдеры типа Билайна (видел лично) или НетБайНета. Собственно, если доступ в интернет идет через туннели, то так само и просится избавится от необходимости ворочать на уровнях ближе к ядру весь этот дурацкий локальный пользовательский трафик — лучше один раз нормально настроить коммутаторы и забыть…
>Собственно, если доступ в интернет идет через туннели, то так само и просится избавится от необходимости ворочать на уровнях ближе к ядру весь этот дурацкий локальный пользовательский трафик
Можно вопрос немного не в тему. Как в таком случае провайдеры страхуются от ситуации, когда часть пользователей локальным трафиком забивает аплинк свича? Скажем, тянут пользователи свича А файло у пользователей свича Б. Аплинки обоих свичей забиты. Как с этим борются?
Можно вопрос немного не в тему. Как в таком случае провайдеры страхуются от ситуации, когда часть пользователей локальным трафиком забивает аплинк свича? Скажем, тянут пользователи свича А файло у пользователей свича Б. Аплинки обоих свичей забиты. Как с этим борются?
никак не борются, потому что аплинк свища жирнее чем порты пользователя, как результат даже нескольким пользователям забить его будет сложно, одному — вообще не возможно.
простой пример: DES3526 — 24 порта 10/100 и 2 шареда на 10/100/1000. тянем до агрегации два провода в lacp, получаем на свищ доступа 2гбе канал. т.о. чтобы его «забить», надо заставить одновременно «качать» сразу 20 пользователей, вероятность чего крайне мала.
особо отчаяным можно конечно нарисовать кос. имхо, оно не надо.
простой пример: DES3526 — 24 порта 10/100 и 2 шареда на 10/100/1000. тянем до агрегации два провода в lacp, получаем на свищ доступа 2гбе канал. т.о. чтобы его «забить», надо заставить одновременно «качать» сразу 20 пользователей, вероятность чего крайне мала.
особо отчаяным можно конечно нарисовать кос. имхо, оно не надо.
Вам уже ответили — такой проблемы в реальности не существует и никто с ними не борется. :-)
А вот наоборот бывает — когда весь трафик гонят в ядро (в случае выдачи индивидуальных вланов или использовании ip unnumbered) и пытаются там его разрулить…
А вот наоборот бывает — когда весь трафик гонят в ядро (в случае выдачи индивидуальных вланов или использовании ip unnumbered) и пытаются там его разрулить…
начнем с того что 802.1q vlan — это технология доступа. ни одного абонентсткого влана не должно быть в ядре. они все заканчиваются на районной L3 аггрегации. тем самым никто трафик между вланами не гонит в ядро сети, да и как мне кажется даже если и гонят, его в любом случае не больше чем интернета или чего еще что за пределами сети. ну а то что трафик между двумя пользователями на соседних портах одного свища течет через свищ аггрегации — не особо большое зло. спросите себя сами: «как часто вы качаете что-то у соседа?», да даже на вопрос «как часто вы качаете что-то в пределах своей (т.е. провайдера) сети?» ответ будет вида «где-то раз в году может быть». а лично я вообще отвечу «никогда». :-)
я не особо любитель vlan per user, но оно имеет свои преимущества. например, можно брать на доступ свищи за $150 способные лишь на вланы и не озадачиваться на ойпи сурс гварды и арп инспекшны :) но если брать свищи например за $300 то можно и без vlan per user жить. :)
однако, как мне кажется, vpn-based варианты все таки для небольших хоменетов только начавших свое развитие. оно имеет свои преимущества, позволяет «дешево» наращивать абонентскую базу не тратя бабла на управляемые коммутаторы. но когда-нибудь придет осознание что содержать vpn стало слишком дорого и накладно, и пользователи не довольны и вообще жуть что происходит. на моей деревне есть далеко не один пример хоменета отказывающегося от впн в пользу управляемого доступа.
я не особо любитель vlan per user, но оно имеет свои преимущества. например, можно брать на доступ свищи за $150 способные лишь на вланы и не озадачиваться на ойпи сурс гварды и арп инспекшны :) но если брать свищи например за $300 то можно и без vlan per user жить. :)
однако, как мне кажется, vpn-based варианты все таки для небольших хоменетов только начавших свое развитие. оно имеет свои преимущества, позволяет «дешево» наращивать абонентскую базу не тратя бабла на управляемые коммутаторы. но когда-нибудь придет осознание что содержать vpn стало слишком дорого и накладно, и пользователи не довольны и вообще жуть что происходит. на моей деревне есть далеко не один пример хоменета отказывающегося от впн в пользу управляемого доступа.
Соглашусь про агрегацию и ядро. А вот насчет остального — нет. Наоборот, когда сеть маленькая, можно каждого пользователя по порту и mac'у контролировать без проблем, а с ростом абонентской базы это уже тяжело и слишком большой overhead. Я уже приводил в пример московских Билайна и НетБайНет — крупнейших ethernet-провайдеров, у которых как раз используются туннели (в Билайне еще со времен Корбины — pptp, в НБН — pppoe; кстати, во многом именно благодаря Корбине/Билайну в массовых коммутаторах начала появляться функция dual access с созданием туннеля pptp поверх обычного линка) — думается, там не совсем уж дураки сидят. На практике, конечно, возможны и другие варианты, но у меня перед глазами как раз именно этот находится и вполне успешно работает…
Опять же — чем больше сеть, тем больше трафик замыкается внутри нее. Например, у Стрима низкоскоростной ADSL с прямым IP, а у Билайна — 100Мбит внутри сети с «серым» адресом. Для того, чтобы качать торренты второй вариант обычно выгоднее несмотря на отсутствие прямого IP из-за того, что у Билайна здоровенная сеть и почти все торренты есть внутри нее — наружу зачастую вылезать и не надо, только за какими-то редкими вещами. Поэтому если вы не качаете ничего внутри вашей сети, то это значит лишь то, что она, скорее всего, слишком маленькая.
Опять же, я повторяю, что наличие vpn не отменяет требование нормального оборудования на доступе. Это вообще не связанные вещи. :-) Для пользователя vpn не особо сложен, как показывает практика. Вон, у того же ADSL несмотря на то, что каждая линия — индивидуальная, все равно используется PPPoE и никто из абонентов на это не ропщет…
Опять же — чем больше сеть, тем больше трафик замыкается внутри нее. Например, у Стрима низкоскоростной ADSL с прямым IP, а у Билайна — 100Мбит внутри сети с «серым» адресом. Для того, чтобы качать торренты второй вариант обычно выгоднее несмотря на отсутствие прямого IP из-за того, что у Билайна здоровенная сеть и почти все торренты есть внутри нее — наружу зачастую вылезать и не надо, только за какими-то редкими вещами. Поэтому если вы не качаете ничего внутри вашей сети, то это значит лишь то, что она, скорее всего, слишком маленькая.
Опять же, я повторяю, что наличие vpn не отменяет требование нормального оборудования на доступе. Это вообще не связанные вещи. :-) Для пользователя vpn не особо сложен, как показывает практика. Вон, у того же ADSL несмотря на то, что каждая линия — индивидуальная, все равно используется PPPoE и никто из абонентов на это не ропщет…
>> Наоборот, когда сеть маленькая, можно каждого пользователя по порту и mac'у контролировать без проблем, а с ростом абонентской базы это уже тяжело и слишком большой overhead.
автоматизация процесса управления вам незнакома? да и кто сказал что нужно смотреть что там на портах творится? от силы нужно только поднимать/опускать порт. остальное за нас сделает сам коммутатор. выше упомянутый DES3526 прекрасно умеет на основании ответов dhcp строить acl на порту.
>> Я уже приводил в пример московских Билайна и НетБайНет — крупнейших ethernet-провайдеров, у которых как раз используются туннели (в Билайне еще со времен Корбины — pptp, в НБН — pppoe; кстати, во многом именно благодаря Корбине/Билайну в массовых коммутаторах начала появляться функция dual access с созданием туннеля pptp поверх обычного линка) — думается, там не совсем уж дураки сидят.
они «крупнейшие», им срать как и что работает, лишь бы работало и пипл хавал. они до следующего тысячелетия успешно на своих дслях и пппое доживут если ничего не прижмет. а пипл и хавает. и да, вы таке хотели сказать «в массовых сохо-мыльницах-рутирах». спешу вас огорчить, асус двухгодичной давности умеет этот «дуалакцес», другое дело что откуда ему знать какие маршруты на какой линк вешать. будете модифицировать прошивки или всех заставлять покупать нужное оборудование доступа? а если обычный комп? гора скриптов и ебля вола? Ж) лолшто. техподдержка должна решать проблемы, а не полоскать мозги пользователю о том какой куда скрипт присунуть чтобы трафик «внутренний/пиринговый» поплыл по нужному линку.
>> Для того, чтобы качать торренты второй вариант обычно выгоднее несмотря на отсутствие прямого IP из-за того, что у Билайна здоровенная сеть и почти все торренты есть внутри нее — наружу зачастую вылезать и не надо, только за какими-то редкими вещами. Поэтому если вы не качаете ничего внутри вашей сети, то это значит лишь то, что она, скорее всего, слишком маленькая.
для того чтобы качать что-то торрентами нужна как минимум retracker.local запись в днсе того кому больше всего пользователей с серыми ойпи смотрят. какая бы ваша сеть большой не была, она всегда будет меньше всех участников городской пиринговой площадки.
перейдем к объяснению на пальцах:
у вас есть компьютер с windows xp в который воткнут провод. по dhcp получаете адрес 172.16.1.111 и шлюзом 172.16.1.1, и до 100мбе внутреннего/пирингого трафика. настраивая vpn вы получаете трубу в интернет в 2мбе и белый адрес и следующий дефолт гетвей на ппп0 интерфейс с меньшей метрикой, короче весь трафик идет теперь через ппп линк в 2мбе. что теперь делать пользователю, если он хочет одновременно и в аське трещать, и торрент с локалпиров качать на нормальной скорости? на рутсервере пиринга скажем пицот сетей которые надо смаршрутизировать через внутренний линк. список может меняться. с большим интересом прослушаю о том как техподдержка пользователю будет рассказывать о «скачать скрипт, добавить в шедулер заданий, радоваться жизни».
>> Опять же, я повторяю, что наличие vpn не отменяет требование нормального оборудования на доступе. Это вообще не связанные вещи. :-) Для пользователя vpn не особо сложен, как показывает практика.
для чего дорогой доступ? чтобы отрезать все фреймы кроме pppoe? ну скажем так, я не понимаю ваших доводов в пользу впнов не к месту.
>> Вон, у того же ADSL несмотря на то, что каждая линия — индивидуальная, все равно используется PPPoE и никто из абонентов на это не ропщет…
adsl2+ в вакууме дает 24мбе ассимметричного канала. на деле, учитывая плачевного состояния линий телефонной электросвязи имеем в лучшем случае пару-тройку мегабит на канале. а зачастую мегабит и меньше. adsl — это другой костыль, призванный сэкономить на использовании для шпд уже существующей сети электросвязи. опять же, экономия. это не заменяет соверменные вещи, а лишь дает отсрочку на внедрение. а ввиду всего этого глубоко срать pppoe там или нет. в абонентском комплекте адсл в нагрузку идет модем, настроенный мастером и о торрентах с пирингами в таком случае не приходится даже мечтать. если в этом же доме есть хоменет с езернетом, нормальный человек убежит к нему. :)
автоматизация процесса управления вам незнакома? да и кто сказал что нужно смотреть что там на портах творится? от силы нужно только поднимать/опускать порт. остальное за нас сделает сам коммутатор. выше упомянутый DES3526 прекрасно умеет на основании ответов dhcp строить acl на порту.
>> Я уже приводил в пример московских Билайна и НетБайНет — крупнейших ethernet-провайдеров, у которых как раз используются туннели (в Билайне еще со времен Корбины — pptp, в НБН — pppoe; кстати, во многом именно благодаря Корбине/Билайну в массовых коммутаторах начала появляться функция dual access с созданием туннеля pptp поверх обычного линка) — думается, там не совсем уж дураки сидят.
они «крупнейшие», им срать как и что работает, лишь бы работало и пипл хавал. они до следующего тысячелетия успешно на своих дслях и пппое доживут если ничего не прижмет. а пипл и хавает. и да, вы таке хотели сказать «в массовых сохо-мыльницах-рутирах». спешу вас огорчить, асус двухгодичной давности умеет этот «дуалакцес», другое дело что откуда ему знать какие маршруты на какой линк вешать. будете модифицировать прошивки или всех заставлять покупать нужное оборудование доступа? а если обычный комп? гора скриптов и ебля вола? Ж) лолшто. техподдержка должна решать проблемы, а не полоскать мозги пользователю о том какой куда скрипт присунуть чтобы трафик «внутренний/пиринговый» поплыл по нужному линку.
>> Для того, чтобы качать торренты второй вариант обычно выгоднее несмотря на отсутствие прямого IP из-за того, что у Билайна здоровенная сеть и почти все торренты есть внутри нее — наружу зачастую вылезать и не надо, только за какими-то редкими вещами. Поэтому если вы не качаете ничего внутри вашей сети, то это значит лишь то, что она, скорее всего, слишком маленькая.
для того чтобы качать что-то торрентами нужна как минимум retracker.local запись в днсе того кому больше всего пользователей с серыми ойпи смотрят. какая бы ваша сеть большой не была, она всегда будет меньше всех участников городской пиринговой площадки.
перейдем к объяснению на пальцах:
у вас есть компьютер с windows xp в который воткнут провод. по dhcp получаете адрес 172.16.1.111 и шлюзом 172.16.1.1, и до 100мбе внутреннего/пирингого трафика. настраивая vpn вы получаете трубу в интернет в 2мбе и белый адрес и следующий дефолт гетвей на ппп0 интерфейс с меньшей метрикой, короче весь трафик идет теперь через ппп линк в 2мбе. что теперь делать пользователю, если он хочет одновременно и в аське трещать, и торрент с локалпиров качать на нормальной скорости? на рутсервере пиринга скажем пицот сетей которые надо смаршрутизировать через внутренний линк. список может меняться. с большим интересом прослушаю о том как техподдержка пользователю будет рассказывать о «скачать скрипт, добавить в шедулер заданий, радоваться жизни».
>> Опять же, я повторяю, что наличие vpn не отменяет требование нормального оборудования на доступе. Это вообще не связанные вещи. :-) Для пользователя vpn не особо сложен, как показывает практика.
для чего дорогой доступ? чтобы отрезать все фреймы кроме pppoe? ну скажем так, я не понимаю ваших доводов в пользу впнов не к месту.
>> Вон, у того же ADSL несмотря на то, что каждая линия — индивидуальная, все равно используется PPPoE и никто из абонентов на это не ропщет…
adsl2+ в вакууме дает 24мбе ассимметричного канала. на деле, учитывая плачевного состояния линий телефонной электросвязи имеем в лучшем случае пару-тройку мегабит на канале. а зачастую мегабит и меньше. adsl — это другой костыль, призванный сэкономить на использовании для шпд уже существующей сети электросвязи. опять же, экономия. это не заменяет соверменные вещи, а лишь дает отсрочку на внедрение. а ввиду всего этого глубоко срать pppoe там или нет. в абонентском комплекте адсл в нагрузку идет модем, настроенный мастером и о торрентах с пирингами в таком случае не приходится даже мечтать. если в этом же доме есть хоменет с езернетом, нормальный человек убежит к нему. :)
У нас с вами вместо диалога получается два несвязанных монолога. :-)
Я так полагаю, что дело именно в мировоззренческих позициях. Для вас overhead — это VPN и заморочки с маршрутизацией, а для меня — привязка к порту с учетом того, что смысла в ней нет и все равно легко ломается. Очевидно, что каждому свое и каждый строит сети так, как ему нравится — лишь бы работало. :-)
Что касается крупных операторов — разве это не главное, чтобы «пипл хавал»? Мне кажется, что это и есть главный критерий. Системное администрирование — это, прямо скажем, не та сфера, где нужно стремиться к некоему абстрактному эталону и чтобы все было эстетично и совершенно. Поставленная задача должна решаться, а профит должен быть максимальным — это же бизнес, вы же этим не для голого удовольствия занимаетесь. :-) Ну и зависимость прямая — чем лучше решение задачи, тем активнее пипл хавает и тем больше профита. Так что я бы все-таки поливать всех крупных операторов скопом не стал бы. Они существуют и это говорит в их пользу.
Я так полагаю, что дело именно в мировоззренческих позициях. Для вас overhead — это VPN и заморочки с маршрутизацией, а для меня — привязка к порту с учетом того, что смысла в ней нет и все равно легко ломается. Очевидно, что каждому свое и каждый строит сети так, как ему нравится — лишь бы работало. :-)
Что касается крупных операторов — разве это не главное, чтобы «пипл хавал»? Мне кажется, что это и есть главный критерий. Системное администрирование — это, прямо скажем, не та сфера, где нужно стремиться к некоему абстрактному эталону и чтобы все было эстетично и совершенно. Поставленная задача должна решаться, а профит должен быть максимальным — это же бизнес, вы же этим не для голого удовольствия занимаетесь. :-) Ну и зависимость прямая — чем лучше решение задачи, тем активнее пипл хавает и тем больше профита. Так что я бы все-таки поливать всех крупных операторов скопом не стал бы. Они существуют и это говорит в их пользу.
безусловно все решает бабло. но еще хорошо бы чтобы пользователей за людей считали и не навязывали плясать под дудку саппорта, ога?
в моей деревне едва ли ни каждый маломальски подросший хоменет съезжает с впна в пользу управляемого доступа. не сразу, не быстро, но его профит очевиден. у голденов и сибирьтелекомов другое. особенно у последних: одни спроэктировали, другие купили, третьи ввели в эксплуатацию. проверить как оно работает и работает ли вообще некому. да, потому что большие, потому что на все срать, потому что много где банально монополисты, чаще всего из-за того что большие Ж) замкнутый круг, ага. чем больше телеком, тем более инертный. может быть они и рады выбросить свои впны и дсли, но размеры таки диктуют другое: дешевле костыли подставлять чем перестраивать всё и вся.
в моем доме штук пять, если не больше, провайдеров, среди них есть даже магистрал пришедший в народ, сионисты из перьми, даже сибирьтелеком с голдой любимой вами есть и скромный хоменет на управляемом доступе без тараконов в голове. угадайте чьим абонентом я стал и чьих абонентов я дразню результатами пирингового спидтеста? :)
>> Поставленная задача должна решаться, а профит должен быть максимальным — это же бизнес
поэтому я считаю что впн для небольших сетей без умного доступа, а привязка на порту — для больших сетей с умным доступом. потому что чем больше сеть, тем больше трафика вам нужно будет прожевать вашим брасом. в итоге вы все равно придете сначало к статикам на оборудовании пользователя, а потом к выбрасыванию впна. просто еще не пришли. =]
в моей деревне едва ли ни каждый маломальски подросший хоменет съезжает с впна в пользу управляемого доступа. не сразу, не быстро, но его профит очевиден. у голденов и сибирьтелекомов другое. особенно у последних: одни спроэктировали, другие купили, третьи ввели в эксплуатацию. проверить как оно работает и работает ли вообще некому. да, потому что большие, потому что на все срать, потому что много где банально монополисты, чаще всего из-за того что большие Ж) замкнутый круг, ага. чем больше телеком, тем более инертный. может быть они и рады выбросить свои впны и дсли, но размеры таки диктуют другое: дешевле костыли подставлять чем перестраивать всё и вся.
в моем доме штук пять, если не больше, провайдеров, среди них есть даже магистрал пришедший в народ, сионисты из перьми, даже сибирьтелеком с голдой любимой вами есть и скромный хоменет на управляемом доступе без тараконов в голове. угадайте чьим абонентом я стал и чьих абонентов я дразню результатами пирингового спидтеста? :)
>> Поставленная задача должна решаться, а профит должен быть максимальным — это же бизнес
поэтому я считаю что впн для небольших сетей без умного доступа, а привязка на порту — для больших сетей с умным доступом. потому что чем больше сеть, тем больше трафика вам нужно будет прожевать вашим брасом. в итоге вы все равно придете сначало к статикам на оборудовании пользователя, а потом к выбрасыванию впна. просто еще не пришли. =]
>>> как часто вы качаете что-то в пределах своей (т.е. провайдера) сети?
retracker.local часто рулит…
retracker.local часто рулит…
поправка: не
echo 1>/proc/sys/net/ipv4/conf/eth0.101/proxy_arpа
echo 1 >/proc/sys/net/ipv4/conf/eth0.101/proxy_arp
При использовании технологии Client-VLAN возникает проблема: как сэкономить IP-адреса?
Вы таки все еще экономите приватные IP адреса? Аттракцион невиданной жадности прям-)
А вот я все-таки за туннели. Привязка IP к MAC'у пришла в last mile провайдинг из офисного сетестроительства. Собственно, весь Ethernet изначально для этого строился и больше чем на кампусные сети рассчитан не был… Однако же, появились коммутаторы, с которых и началось через множество костылей приспосабливание Ethernet'а под совершенно другие цели и вот — чу! — уже есть у нас провайдеры мирового уровня, типа Коджента (он же уже Tier 1 себя называет), которые все свои сети строили и строят исключительно на Ethernet…
Впрочем, я отвлекся. Так или иначе, но привязка MAC к IP — это, как уже сказано, попытка приспособить средство внутриофисного управления пользователями для совершенно других задач. Поскольку с задачами контроля коммерческих клиентов средство справлялось и справляется откровенно плохо — сразу начали придумывать дополнительные костыли. Одним из них стала привязка дополнительно и к порту, что позволяет нам идентифицировать пользоваться по триплету IP-MAC-PORT. Но это действительно уже тяжко и слишком громоздко. Автор не разжевал этого подробнее, но идея в том, чтобы как раз отказаться от фиксации MAC и любому оборудованию, появляющемуся на определенной порту — «верить на слово», что оно «хорошее» и сразу выдавать нужный IP. Однако, какие системы не навешивай, какие умные коммутаторы ни ставь, и даже если все-таки помимо порта продолжать контролировать и MAC'и — все равно это не защищает ни грамма от атак типа «maт-in-the-middle», когда тупо режется кабель клиента и в разрыв ставится свич/иное_свое_оборудование.
Все крайне просто — если человеку не надо никого «ломать», то для минимальной защиты и борьбы с мелкими косяками достаточно просто MAC где-нибудь вообще на уровне агрегации L3 проверять. Но если человеку надо — то он, как ни проверяй на коммутаторах, — все равно «влезет» в разрыв кабеля до другого клиента, просниффает все что надо, притвориться кем надо и будет воровать все что ему надо. Это неизбежно. Так, спрашивается, стоит ли парить себе мозг всеми этими Option 82 и dhcp relay на коммутаторах, которые перманентно глючат в той или иной степени, тратить деньги на этот функционал и грузить тех.поддержку/монтажников дополнительным моментом в работе — контролем порта, куда вставлен клиент? Мне кажется — нет, т.к. игра не стоит свеч. Уж лучше проверенные PPPoE и PPTP (кстати, вопрос к автору — а зачем у вас в этом слове буква T — маленькая? Point-to-Point-Tunneling-Protocol — там все буквы равноценны) с логином/паролем. Благо все это сейчас поддерживается автоматически системами и роутерами — не то, что лет 10-15 назад…
Впрочем, я отвлекся. Так или иначе, но привязка MAC к IP — это, как уже сказано, попытка приспособить средство внутриофисного управления пользователями для совершенно других задач. Поскольку с задачами контроля коммерческих клиентов средство справлялось и справляется откровенно плохо — сразу начали придумывать дополнительные костыли. Одним из них стала привязка дополнительно и к порту, что позволяет нам идентифицировать пользоваться по триплету IP-MAC-PORT. Но это действительно уже тяжко и слишком громоздко. Автор не разжевал этого подробнее, но идея в том, чтобы как раз отказаться от фиксации MAC и любому оборудованию, появляющемуся на определенной порту — «верить на слово», что оно «хорошее» и сразу выдавать нужный IP. Однако, какие системы не навешивай, какие умные коммутаторы ни ставь, и даже если все-таки помимо порта продолжать контролировать и MAC'и — все равно это не защищает ни грамма от атак типа «maт-in-the-middle», когда тупо режется кабель клиента и в разрыв ставится свич/иное_свое_оборудование.
Все крайне просто — если человеку не надо никого «ломать», то для минимальной защиты и борьбы с мелкими косяками достаточно просто MAC где-нибудь вообще на уровне агрегации L3 проверять. Но если человеку надо — то он, как ни проверяй на коммутаторах, — все равно «влезет» в разрыв кабеля до другого клиента, просниффает все что надо, притвориться кем надо и будет воровать все что ему надо. Это неизбежно. Так, спрашивается, стоит ли парить себе мозг всеми этими Option 82 и dhcp relay на коммутаторах, которые перманентно глючат в той или иной степени, тратить деньги на этот функционал и грузить тех.поддержку/монтажников дополнительным моментом в работе — контролем порта, куда вставлен клиент? Мне кажется — нет, т.к. игра не стоит свеч. Уж лучше проверенные PPPoE и PPTP (кстати, вопрос к автору — а зачем у вас в этом слове буква T — маленькая? Point-to-Point-Tunneling-Protocol — там все буквы равноценны) с логином/паролем. Благо все это сейчас поддерживается автоматически системами и роутерами — не то, что лет 10-15 назад…
>Благо все это сейчас поддерживается автоматически системами и роутерами — не то, что лет 10-15 назад…
Тут Вы немного лукавите. Есть масса soho-железячек, в которых PPPoE нет или оно не рабочее. Большинство клиентов, так же, не особо разбираются в настройке оных. Как быть? Удручать тех. поддержку настройкой сетевого металлолома клиентов? Или отказывать в подключении?
Тут Вы немного лукавите. Есть масса soho-железячек, в которых PPPoE нет или оно не рабочее. Большинство клиентов, так же, не особо разбираются в настройке оных. Как быть? Удручать тех. поддержку настройкой сетевого металлолома клиентов? Или отказывать в подключении?
Быть очень просто — продавать клиентами правильное оборудование и оказывать платные услуги по выезду на дом и настройке всего, чего клиент пожелает. :-)
Это, разумеется, ваше право. :-) Но подумайте — зачем вы нужны провайдеру со своим глючным и древним (раз уж оно даже PPPoE не поддерживает!) оборудованием, с которым вы только создаете проблемы и не хотите платить деньги? :-) Провайдер же не благотворительностью занимается. Освободившееся от геморроя с вами и вашим древним железом время он лучше потратит на других клиентов и на зарабатывание денег… :-) Это же бизнес.
Вы просто все оцениваете со своей колокольни, которая столь же далеко от колокольни обычного пользователя, как и от колокольни провайдера. :-)
Обычный пользователь не знает ничего из тех страшных слов, что вы написали. Он знает, что Интернет — это когда щелкаешь на иконку с буквой «Е» и открывается mail.ru, а чтобы этот Интернет работал — надо обращаться вот по этому телефону, который он себе записал на бумажку и повесил сбоку от монитора после визита монтажников, кинувших в квартиру кабель.
Для провайдера такой обычный пользователь — это нормальная привычная среда. Ты его обслуживаешь, он к тебе если что обращается — все довольны. Пассивный продвинутый пользователь — тоже хорошо. Кинул ему кабель, дал бумажку с настройками и он тебя больше не трогает, только денежку платит. Хуже всего активные продвинутые пользователи, потому что они большей частью крохоборы (они же продвинутые — зачем им действительно платить деньги за что-то?) и кроме того капитально выносят мозг. :-)
Разумеется, ни один из пользователей ничего не должен провайдеру и голосует ногами. Фишка в том, что нормальному провайдеру совершенно не хочется тратить время на удержание упомянутых активных продвинутых — от них проблем больше чем пользы. Пусть они голосуют ногами в сторону того провайдера, которых хочет с ними возиться, лучше это время на обычных пользователей потратить…
Зачем привязывать mac к ip вы не понимаете по той же причине — вы не провайдер и по трафику за интернет не платите. Если бы платили — то очень хорошо бы понимали. :-)
Обычный пользователь не знает ничего из тех страшных слов, что вы написали. Он знает, что Интернет — это когда щелкаешь на иконку с буквой «Е» и открывается mail.ru, а чтобы этот Интернет работал — надо обращаться вот по этому телефону, который он себе записал на бумажку и повесил сбоку от монитора после визита монтажников, кинувших в квартиру кабель.
Для провайдера такой обычный пользователь — это нормальная привычная среда. Ты его обслуживаешь, он к тебе если что обращается — все довольны. Пассивный продвинутый пользователь — тоже хорошо. Кинул ему кабель, дал бумажку с настройками и он тебя больше не трогает, только денежку платит. Хуже всего активные продвинутые пользователи, потому что они большей частью крохоборы (они же продвинутые — зачем им действительно платить деньги за что-то?) и кроме того капитально выносят мозг. :-)
Разумеется, ни один из пользователей ничего не должен провайдеру и голосует ногами. Фишка в том, что нормальному провайдеру совершенно не хочется тратить время на удержание упомянутых активных продвинутых — от них проблем больше чем пользы. Пусть они голосуют ногами в сторону того провайдера, которых хочет с ними возиться, лучше это время на обычных пользователей потратить…
Зачем привязывать mac к ip вы не понимаете по той же причине — вы не провайдер и по трафику за интернет не платите. Если бы платили — то очень хорошо бы понимали. :-)
Для пущего контроля. Чтобы потом не вышло ситуации, что денег на счету нет, а абонент работает в локалке нахаляву, а то и в инет под чужим адресом пойдет. У нас на портах коммутаторов доступа прописаны статические МАС и все настройки выдаются по DHCP. Проникновение компьютерной техники и интернета вышло уже за рамки гиков и интересующихся товарищей. Компьютер сейчас есть и у домохозяек и у детей лет 10. Объяснять им, как прописать IP в настройках сетевой карты дольше, чем выдавать его автоматически, привязав к МАС и зафиксировав этот МАС на порту. Случаев с заменой оборудования и отсутствием доступа в интернет, потребовавшим выезда бригады для настройки абонентского оборудования просто НЕТ. Все решается на уровне первой линии техподдержки, которая может зайти на коммутатор и проверить, какой же МАС-адрес сейчас светится на порту.
Удручать себя настройками и гемором с IPoE стоит хотя бы потому, что это все уводить управление сетью на гораздо менее умные железки. Когда вы столкнетесь с необходимостью приобретения очередного маршрутизатора стоимостью 300-400 тысяч, неизбежно придется задуматься, а можно ли как-то по другому работать.
PPP хорош в dsl и прочих сегментах, а если же вся сеть на управляемом ethernet, то почему просто не маршрутить статикой? Это может любой полноценный L3 коммутатор. Стоят они на порядок дешевле, объемы прожевываемого трафика в десятки раз больше. Функционала старших маршрутизаторов по большей части в клиентском провайдинге ну нафиг не надо. Идеальный вариант это классический влан на клиента, но серая адресация не есть гуд, ибо в итоге нужен будет еще и нат, да и не красиво. Самым экономичным в плане организации является выдача белых айпишников, но тут надо изворачиваться и их экономить, для чего и применяется IP unnembered.
Есть слабые места у данной реализации, что очень сложно вычислять сессию (иногда это требуется), нет как таковой авторизации (верим всем кто воткнут в порт, привязки ip-mac-port не рассматриваем, они на клиентском оборудовании глючат жестоко), но в целом данная схема стоит того что бы жить.
ps а в некоторой литературе встречается кстати PPtP как протокол поинт ту поинт, еще с универа помнится =)
PPP хорош в dsl и прочих сегментах, а если же вся сеть на управляемом ethernet, то почему просто не маршрутить статикой? Это может любой полноценный L3 коммутатор. Стоят они на порядок дешевле, объемы прожевываемого трафика в десятки раз больше. Функционала старших маршрутизаторов по большей части в клиентском провайдинге ну нафиг не надо. Идеальный вариант это классический влан на клиента, но серая адресация не есть гуд, ибо в итоге нужен будет еще и нат, да и не красиво. Самым экономичным в плане организации является выдача белых айпишников, но тут надо изворачиваться и их экономить, для чего и применяется IP unnembered.
Есть слабые места у данной реализации, что очень сложно вычислять сессию (иногда это требуется), нет как таковой авторизации (верим всем кто воткнут в порт, привязки ip-mac-port не рассматриваем, они на клиентском оборудовании глючат жестоко), но в целом данная схема стоит того что бы жить.
ps а в некоторой литературе встречается кстати PPtP как протокол поинт ту поинт, еще с универа помнится =)
*бррр, прошу прощения за орфографию и грамматику, все-таки утро и воскресенье.
Так, давайте разделять мух и котлеты. :-)
Во-первых, насчет «умных железок» все с точностью до наоборот. IP+MAC+port с нормальной поддержкой option82 — это автоматически означает коммутаторы уровня L2+ на доступе. Как минимум — те же Длинки, которые уже сколько лет пилят. Обычным «шаблонным» L2-коммутатором, коих китайцы уже научились штамповать — как раз уже не обойдешься.
Насчет «маршутизатора за 300-400 тысяч» — не понял. Для каких целей? Туннели терминировать? Знаете, когда ставится задача держать сотни-тысячи сессий — мне даже продажники Циски советовали всегда не парить себе мозг, а какой-нибудь mpd использовать… :-)
Во-вторых, «не маршрутить статикой» (подразумеваю — не пускать в интернет без туннеля) именно по тем причинам, что я описал выше — несекурно. Как ни крути, что ни делай — все равно. Можете считать меня параноиком. :-) А самое главное, если на кабель клиента кто-то врежется и начнет «сосать» его трафик — вы зачастую этого и не узнаете. И клиент узнает в лучшем случае когда счет получит (но поскольку у всех сейчас анлимы, то даже тогда не узнает). И в итоге все недовольны — вы думаете, что это клиентский трафик, а клиент думает что его обманывают (выставляют на деньги или зажимают скорость)…
В-третьих, L3-коммутаторы для роутинга никто не отменяет. :-) Просто к ним добавляются VPN'ы для терминации туннелей. И это совсем небольшие деньги…
В-четвертых, я лично вообще против «белых» адресов для клиентов. Зачем это нужно? Только чтобы избавиться от NAT'а, который лениво поддерживать? Странная причина, честно говоря… Не надо путать типичного компьютерщика и типичного «хомячка». Обычный человек не знает, что такое «белый» адрес (и что такое вообще адрес) и он ему не нужен. А кто знает и кому нужен — пусть платить за это деньги. Если не хочется брать деньги — пусть будет бесплатно, но хотя бы опять же на кончике туннеля, а не прямо на интерфейсе сетевушки…
В-пятых, вы и сами указываете на фактическое отсутствие авторизации. Я об этом изначально и говорю. И это — главный гвоздь в гроб выдачи интернета прямо на физический интерфейс пользователю с какими угодно привязками.
Но вообще, конечно же, все вышесказанное — мое глубоко личное мнение, основанное на своих предрассудках, опыте администрирования и тараканах в голове. :-) Каждый строит свою сеть так, как ему удобнее, лишь бы она выполняла возложенные на нее задачи. :-)
ps: Это разные вещи. Point-to-Point-Protocol — это PPP, который есть и внутри PPPoE, и внутри PPTP. Собственно, разница только в инкапсуляции — в PPPoE PPP ходит сразу поверх Ethernet на уровне L2, а в PPTP — поверх туннеля GRE на уровне L3.
Во-первых, насчет «умных железок» все с точностью до наоборот. IP+MAC+port с нормальной поддержкой option82 — это автоматически означает коммутаторы уровня L2+ на доступе. Как минимум — те же Длинки, которые уже сколько лет пилят. Обычным «шаблонным» L2-коммутатором, коих китайцы уже научились штамповать — как раз уже не обойдешься.
Насчет «маршутизатора за 300-400 тысяч» — не понял. Для каких целей? Туннели терминировать? Знаете, когда ставится задача держать сотни-тысячи сессий — мне даже продажники Циски советовали всегда не парить себе мозг, а какой-нибудь mpd использовать… :-)
Во-вторых, «не маршрутить статикой» (подразумеваю — не пускать в интернет без туннеля) именно по тем причинам, что я описал выше — несекурно. Как ни крути, что ни делай — все равно. Можете считать меня параноиком. :-) А самое главное, если на кабель клиента кто-то врежется и начнет «сосать» его трафик — вы зачастую этого и не узнаете. И клиент узнает в лучшем случае когда счет получит (но поскольку у всех сейчас анлимы, то даже тогда не узнает). И в итоге все недовольны — вы думаете, что это клиентский трафик, а клиент думает что его обманывают (выставляют на деньги или зажимают скорость)…
В-третьих, L3-коммутаторы для роутинга никто не отменяет. :-) Просто к ним добавляются VPN'ы для терминации туннелей. И это совсем небольшие деньги…
В-четвертых, я лично вообще против «белых» адресов для клиентов. Зачем это нужно? Только чтобы избавиться от NAT'а, который лениво поддерживать? Странная причина, честно говоря… Не надо путать типичного компьютерщика и типичного «хомячка». Обычный человек не знает, что такое «белый» адрес (и что такое вообще адрес) и он ему не нужен. А кто знает и кому нужен — пусть платить за это деньги. Если не хочется брать деньги — пусть будет бесплатно, но хотя бы опять же на кончике туннеля, а не прямо на интерфейсе сетевушки…
В-пятых, вы и сами указываете на фактическое отсутствие авторизации. Я об этом изначально и говорю. И это — главный гвоздь в гроб выдачи интернета прямо на физический интерфейс пользователю с какими угодно привязками.
Но вообще, конечно же, все вышесказанное — мое глубоко личное мнение, основанное на своих предрассудках, опыте администрирования и тараканах в голове. :-) Каждый строит свою сеть так, как ему удобнее, лишь бы она выполняла возложенные на нее задачи. :-)
ps: Это разные вещи. Point-to-Point-Protocol — это PPP, который есть и внутри PPPoE, и внутри PPTP. Собственно, разница только в инкапсуляции — в PPPoE PPP ходит сразу поверх Ethernet на уровне L2, а в PPTP — поверх туннеля GRE на уровне L3.
К сожалению от атаки man-in-the-middle ничего не спасет, только авторизация через сертификаты м.б., но это такой гемор, с которым конечный пользователей (хомячек как вы сказали) заморачиваться не будет, тут надо смотреть как провайдер какого сервиса вы себя позиционируете. Или очень секурный, или пользовательский. Оценить риски, мероприятия которые нужны для их сокращения, и геморой для конечного пользователя который они повлекут. А ведь геморой для конечного пользователя — одно из конкуретный преимуществ. Вобщем думать, а не переться на пролом. Каждое решение хорошо в своем месте.
А с белыми адресами, эт тоже свои тараканы ;) Каждая конкретная крупная сеть не похожа на другую, в целом то все по стандартам, но реализации у всех разные.
PS mpd хорошее решение, тут я спорить не буду, но в некоторых местах софтовые решения не любят, вы это, судя по уровню, знаете наверное.
pps я не спорю, я просто говорю что такое встречается ;)
А с белыми адресами, эт тоже свои тараканы ;) Каждая конкретная крупная сеть не похожа на другую, в целом то все по стандартам, но реализации у всех разные.
PS mpd хорошее решение, тут я спорить не буду, но в некоторых местах софтовые решения не любят, вы это, судя по уровню, знаете наверное.
pps я не спорю, я просто говорю что такое встречается ;)
Ну вот туннели спасают… Но там, конечно же, свои косяки есть… Кстати, знал я одну провайдерскую сеть, где через сертификаты была авторизация у обычных пользователей. Жутко геморройно, но оно у них работало…
Безусловно, для самого пользователя все должно быть максимально удобно. Туннели, конечно, еще один лишний шаг и лишнее звено, но на мой взгляд как раз это тот случае, когда overhead не очень большой и преимущества его покрывают… Хотя, каждому действительно свое.
Ну, кто не любит софтовые решения — может их не использовать. Как раз, если по туннелю выдавать сразу «белые» адреса нет необходимости туннели сразу NAT'ить, то можно и железку специальную использовать — терминировать VPN есть чем. Но как раз именно по причине наличия mpd смысла в этом особого нет. :-) Уж слишком mpd прекрасен. :-)
Безусловно, для самого пользователя все должно быть максимально удобно. Туннели, конечно, еще один лишний шаг и лишнее звено, но на мой взгляд как раз это тот случае, когда overhead не очень большой и преимущества его покрывают… Хотя, каждому действительно свое.
Ну, кто не любит софтовые решения — может их не использовать. Как раз, если по туннелю выдавать сразу «белые» адреса нет необходимости туннели сразу NAT'ить, то можно и железку специальную использовать — терминировать VPN есть чем. Но как раз именно по причине наличия mpd смысла в этом особого нет. :-) Уж слишком mpd прекрасен. :-)
В случае использования IPoE, как врезавшийся в кабель клиента злоумышленник сможет сосать трафик без ведома самого клиента? На порту VLAN, на VLAN роутится один единственный IP. Два хоста с одинаковым IP в одной сети, работать будет только один. Или тут есть что-то, чего я не учитываю? Если еще и MAC себе поставить клиентский, то опять же одновременно корректно работать они не смогут.
ARP Poisoning/Spoofing никто не отменял. Ну и вообще — Гугл в помощь по словам «ethernet man in the middle» и типа того. :-) Всем этим атакам — тысячи лет, все их знают и по ним написана куча документации. Если вас не ломали — то это не значит, что их не существует. :-) Или вы слишком маленький провайдер, или просто не замечали этих атак (т.е. они были успешными). Опять же — тот же Билайн (exCorbina) или NetByNet (а кто еще у нас в Москве есть из крупных ethernet-провайдеров?) почему-то используют именно туннели для доступа в Интернет и их не пугают ни связанные с этим трудности «пиринга», ни необходимость в VPN-серверах… При том что на оборудовании они не экономят. Билайн вон даже ленится у Длинков 3526 конденсаторы в БП перепаивать (хотя всем известно, что перепаяный Длинк надежнее и служит дольше, чем новый, т.к. ставятся нормальные конденсаторы, а не та «рассыпуха», что они на заводе туда лепят) — они просто меняют девайс на новый, а старый продают с уценкой тем, кто не ленится. :-)
Теперь понял. Вклиниваемся в кабель клиента, его трафик роутим через себя, а сами при этом также пользуемся его каналом. Но, при использовании туннелей, хоть PPTP, хоть PPPoE, не намного сложнее провести аналлогичную атаку. Аутентификация PAP тупо перехватывается, CHAP немного сложнее, но тоже особых проблем не будет.
PAP никто много лет не использует. Способов перехватить ms-chapv2 я не знаю. Его по-моему вообще нет смысла перехватывать — там же пароль не передается в принципе.
MS-CHAP v2 лишь добавляет взаимность в процесс аутентификации.
Выяснение самого пароля в случае MS-CHAP и MS-CHAPv2 возможно очень долгим подбором. Однако сам пароль нам и не нужен. Получив хэши, мы уже сможем прозрачно вклиниться между клиентом и сервером.
На недоверенных каналах связи более-менее надежен лишь PEAP.
Выяснение самого пароля в случае MS-CHAP и MS-CHAPv2 возможно очень долгим подбором. Однако сам пароль нам и не нужен. Получив хэши, мы уже сможем прозрачно вклиниться между клиентом и сервером.
На недоверенных каналах связи более-менее надежен лишь PEAP.
1) Гм. Наверное, я чего-то не до конца понимаю. В ms-chap не пересылаются хэши. Пересылается от сервера рандомная строка, которая кодируется (хэшируется опять же) клиентом, пересылается обратно и сервера проверяет — правильно ли закодировал. Перехватывай — не перехватывай — толку нет. Разумеется, если линк без шифрования то потом проснифать его можно, но это уже неизбежно. Чужим инетом нельзя воспользоваться — и хорошо.
Так или иначе, но я взломов pptp+chap не видел никогда. В отличие от воровства интернета пользователями друг у друга несмотря на все ограничения mac'ов и прочего…
2) А они его на Ethernet используют или где? Просто на adsl или коммутируемых линиях в общем-то по фигу. Если на коммутируемых, то скорее всего это вообще по причине устарелости серверного оборудования…
Так или иначе, но я взломов pptp+chap не видел никогда. В отличие от воровства интернета пользователями друг у друга несмотря на все ограничения mac'ов и прочего…
2) А они его на Ethernet используют или где? Просто на adsl или коммутируемых линиях в общем-то по фигу. Если на коммутируемых, то скорее всего это вообще по причине устарелости серверного оборудования…
1) Я подобных взломов не делал, так что могу только дать ссылку: www.nestor.minsk.by/sr/2007/03/sr70314.html.
2) И на Ethernet и на ADSL. Коммутируемые линии, к счастью, уже стали забытым кошмаром.
2) И на Ethernet и на ADSL. Коммутируемые линии, к счастью, уже стали забытым кошмаром.
А про PAP Вы наверное не поверите…
Волгателеком — крупнейший провайдер всего Поволжья использует PPPoE с PAP :) Думаю, что обстановка по всей стране примерно такая.
Волгателеком — крупнейший провайдер всего Поволжья использует PPPoE с PAP :) Думаю, что обстановка по всей стране примерно такая.
Злоумышленник может перерезать кабель, обжать его до и после разрыва и вставить оба конца в роутер, который будет иметь одинаковые IP-адреса на двух интерфейсах. Так честный пользователь, даже при наличии сниффера, не увидит активности злоумышленника.
туннели не вариант как минимум по двум причинам:
1. каким образом с туннелем отделять пиринговый трафик от интернета на порту пользователя? по дшцп костылями ему вдуть тонну маршрутов статики? заставить его регулярно запускать скрипт который качает список сетей с рутсервера провайдера и прописывает его в статику? это все слишком сложно и этого быть не должно. пользователь не должен греться такой х*йней.
2. раз гигобиты пирингового трафика нельзя отделить, то надо их рутить через брас => покупка конячих брасов. при этом без них вообще можно было обойтись если не пользовать туннели.
pptp/l2tp/pppoe и т.п. существуют лишь для того чтобы избавиться от проблемы подмены адресов/маков в случае если доступ на неуправляемых свищах, как это было лет 5 назад на моей деревне. тогда и каналы были поменьше и пиринги не так чтобы уж шибко развиты и управляемые свищи дорогими. :D
1. каким образом с туннелем отделять пиринговый трафик от интернета на порту пользователя? по дшцп костылями ему вдуть тонну маршрутов статики? заставить его регулярно запускать скрипт который качает список сетей с рутсервера провайдера и прописывает его в статику? это все слишком сложно и этого быть не должно. пользователь не должен греться такой х*йней.
2. раз гигобиты пирингового трафика нельзя отделить, то надо их рутить через брас => покупка конячих брасов. при этом без них вообще можно было обойтись если не пользовать туннели.
pptp/l2tp/pppoe и т.п. существуют лишь для того чтобы избавиться от проблемы подмены адресов/маков в случае если доступ на неуправляемых свищах, как это было лет 5 назад на моей деревне. тогда и каналы были поменьше и пиринги не так чтобы уж шибко развиты и управляемые свищи дорогими. :D
пользователь подобной х*йней и не греется. трафик шейпится на порту оператора. либо на границе, либо на агрегаторе. dscp ведь не просто так в заголовке ip находится. 64 метки хватит для любых типов трафика. пометил на границе трафик, а дальше обрабатывай его как хочешь, режь, не режь.
1) Что такое «пиринговый трафик» и зачем его отделять? Вы имеете в виду бесплатный линк с соседними сетями, чтобы народ файло лил на халяву? :-) Я считаю, что подобные бесплатные для абонентов «пиринги» имею право жить только на «серых» адресах, а в таком случае «вдуть по дшцп» достаточно буквально несколько маршрутов и прописать тоже достаточно один раз пару строчек — проблемы как таковой нет. А вот делать для абонентов какую-то часть «белого» интернетовского трафика бесплатной — это, вы уж простите, ересь полная. Провайдерский пиринг служит для уменьшения расходов провайдеров, а не для увеличения доли халявы абонентов. :-) Опять же, если так посмотреть, то можно на MSK-IX подключиться и весь этот «пиринг» своим клиентам бесплатно отдавать с такой логикой. :-)
Или я вас не понял и вам один трафик от другого на порту пользователя надо для каких-то других целей отделять?
2) Я уже сказал выше — я за то, чтобы четко отделять внутрисеть от внешнего мира. Внутри — «серая» адресация с какими угодно пирингами и гигабитами. По туннелю — белый адрес и «выход в свет». Никаких брасов не нужно — обычные L3 коммутаторы, разве что еще VPN терминировать чем угодно…
3) Я опять же сказал выше — никакие привязки mac-ip-port не защищают от тупой врезки в кабель. Да, пользователь Вася из одной половины сети не сможет сказать, что он — Петя из другой половины. Но он легко и непринужденно может «закосить» под Вову, который живет этажом ниже. Если провайдер более-менее нормальный и плотность подключений высокая (т.е. нет проблемы найти Вову этажом ниже) — вторая ситуация от первой ничем не отличается…
Или я вас не понял и вам один трафик от другого на порту пользователя надо для каких-то других целей отделять?
2) Я уже сказал выше — я за то, чтобы четко отделять внутрисеть от внешнего мира. Внутри — «серая» адресация с какими угодно пирингами и гигабитами. По туннелю — белый адрес и «выход в свет». Никаких брасов не нужно — обычные L3 коммутаторы, разве что еще VPN терминировать чем угодно…
3) Я опять же сказал выше — никакие привязки mac-ip-port не защищают от тупой врезки в кабель. Да, пользователь Вася из одной половины сети не сможет сказать, что он — Петя из другой половины. Но он легко и непринужденно может «закосить» под Вову, который живет этажом ниже. Если провайдер более-менее нормальный и плотность подключений высокая (т.е. нет проблемы найти Вову этажом ниже) — вторая ситуация от первой ничем не отличается…
окей, я понял что у каждого свой взгляд на то каким должен быть «пиринг». но это не меняет того факта что впн не нужен при наличии управляемого доступа.
однако, даже исходя из вашей логики «пирингов», где «пиринг» это серые адреса, придется каждого пользователя заставлять прописывать все используемые диапазоны таких адресов либо вручную, либо заставлять качать скрипты всякие, либо экспериментировать с дшцп. зачем эти сложности не ясно.
да, впн терминировать это еще та затея. то с горой писюков вола насиловать, анонсирую в бэкбон по /32 от каждого подключившегося ебонента, то большую и дорогую железяку покупай, то еще что. это все хорошо и замечательно, когда нет умного доступа.
почему не защищают? если мак прибит гвоздями к порту, то как врезавшийся в кабель гастролер узнает этот мак чтобы начать работать? позвонит в саппорт и попросить флушнуть мак? а номер договора абонента он назовет или каким способом проавторизуется у саппорта?
однако, даже исходя из вашей логики «пирингов», где «пиринг» это серые адреса, придется каждого пользователя заставлять прописывать все используемые диапазоны таких адресов либо вручную, либо заставлять качать скрипты всякие, либо экспериментировать с дшцп. зачем эти сложности не ясно.
да, впн терминировать это еще та затея. то с горой писюков вола насиловать, анонсирую в бэкбон по /32 от каждого подключившегося ебонента, то большую и дорогую железяку покупай, то еще что. это все хорошо и замечательно, когда нет умного доступа.
почему не защищают? если мак прибит гвоздями к порту, то как врезавшийся в кабель гастролер узнает этот мак чтобы начать работать? позвонит в саппорт и попросить флушнуть мак? а номер договора абонента он назовет или каким способом проавторизуется у саппорта?
Проснифает и узнает. В этом и проблема. Добропорядочный пользователь и так ломать ничего не будет. А недобропорядочному все эти «прибития гвоздями» — как мертвому припарки… Секурность всегда обеспечивают максимально «тупые» и простые решения. Туннель с логином и паролей — такое. Фиксация и контроль триплета ip-mac-port, да еще и option82 с вечно глючащим dhcp-relay на коммутаторах — слишком сложное и избыточное. ИМХО, разумеется. :-)
а если соседи по пирингу не с серыми адресами и если их настолько много, что по дхцп уже столько не передать? а еще есть соседи которые серую адресацию не принимают.
я если честно так и не нашел красивого решения как заставить локальный трафик ходить через локальный интерфейс, а не через тунель, если подскажете, честно буду признателен, интересно.
а по поводу 3 — я уже писал выше — от грамотной врезки в кабель ничего практически не защитит
я если честно так и не нашел красивого решения как заставить локальный трафик ходить через локальный интерфейс, а не через тунель, если подскажете, честно буду признателен, интересно.
а по поводу 3 — я уже писал выше — от грамотной врезки в кабель ничего практически не защитит
Если все так, как вы описываете, то выгнать пиринговый трафик из туннеля действительно несколько затруднительно. Но тут уже пора не технические, а административные решения принимать. Например, оставить в пиринге только «серую» адресацию и тех партнеров, у которых только «белые» адреса. dhcp-пакет не безлимитный, но туда на самом деле достаточно много влезает…
У себя я в туннелях пиринговый трафик вообще резал, чтобы было однозначно понятно — через что он у клиента конкретно сейчас пытается идти. Тех.поддержка видит это и сразу говорит, что делать — проблем особых не было.
У себя я в туннелях пиринговый трафик вообще резал, чтобы было однозначно понятно — через что он у клиента конкретно сейчас пытается идти. Тех.поддержка видит это и сразу говорит, что делать — проблем особых не было.
Кстати, вопрос автору, вы это используете где-то на работе? Сколько виртуальных интерфейсов у вас роутер поднимает? 100-200? 1000-2000? 10000-20000?
сам использую анлогичную схему у себя в сети. но немного навороченнее. не могу раскрывать всех секретов но больше всяких защитных протоколов поверх Option 82. MPLS для транспорта каждого клиента. радиус аувторизация DHCP запросов. а вот оборудование на котором это все стоит вабще пипец которое грубо гуворя не должно поддерживать DHCP snooping.
PS. ой ща заминусуют за интриганство. но увы, извиняйте копирайт конфига не за мной.
PS. ой ща заминусуют за интриганство. но увы, извиняйте копирайт конфига не за мной.
Авторизация через RADIUS для DHCP-запросов? Вы поставляете клиентам модифицированные DHCP-клиенты, которые поддерживают авторизацию?
Или Вы имеете в виду патч www.netpatch.ru/dhcp2radius.html, в котором RADIUS играет лишь роль прослойки между DHCP и SQL-базой. А нужно это исключительно для удобства задания настроек DHCP.
Или Вы имеете в виду патч www.netpatch.ru/dhcp2radius.html, в котором RADIUS играет лишь роль прослойки между DHCP и SQL-базой. А нужно это исключительно для удобства задания настроек DHCP.
Какое-то сплошное мужеложство. Зачем все это? Вам не хватает приватных сетей и влсм? Зачем все усложнять?
Подобная схема никому не нужна — в маленьких локалках она нафиг не упала, в больших — себе дороже городить такие костыли.
Подобная схема никому не нужна — в маленьких локалках она нафиг не упала, в больших — себе дороже городить такие костыли.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
IPoE, а также Client-VLAN и DHCP Option 82