locoz Опубликовано 14 ноября, 2009 · Жалоба Молодой ethernet-провайдер строит сеть :) Один VLAN на один свич доступа, абоненты получают серые адреса от DHCP opt.82 по признаку порта на свиче агрегации. С абонентами-физиками пока всё понятно, будут ходить в инет через РРТР, юрикам же хотелось бы отдавать как минимум /30 подсеть белых адресов, причём без использования каких-либо туннелей. Могу ли я на свиче агрегации прописать на интерфейсе VLANа, который будет отдан юрику, белый адрес и отдать юрику этот адрес в качестве шлюза по-умолчанию? Т.е. не возникнут ли проблемы при смешении белого и серого адресного пространств? В теории всё вроде как ок: пакеты от юрика пошли на интерфейс этого VLANа, на свиче агрегации ушли на дефолтный шлюз, которым будет интферфейс VLANа на коммутаторе ядра, путь этот адрес и серый, а с него на локальный интерфейс бордер-роутера. Я правильно мыслю? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrеw Опубликовано 14 ноября, 2009 · Жалоба нарисуйте схему, ибо ничего не понятно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Nafanya Опубликовано 14 ноября, 2009 · Жалоба создайте ещё один vlan для юрика и прокиньте его до агрегации или хоть до самого бордера. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nevzorofff Опубликовано 14 ноября, 2009 · Жалоба Могу ли я на свиче агрегации прописать на интерфейсе VLANа, который будет отдан юрику, белый адрес и отдать юрику этот адрес в качестве шлюза по-умолчанию? Т.е. не возникнут ли проблемы при смешении белого и серого адресного пространств? В теории всё вроде как ок: пакеты от юрика пошли на интерфейс этого VLANа, на свиче агрегации ушли на дефолтный шлюз, которым будет интферфейс VLANа на коммутаторе ядра, путь этот адрес и серый, а с него на локальный интерфейс бордер-роутера. Я правильно мыслю?Всё правильно, проблем не возниктет, так белые адреса экономят даже старттелеком и мегафон, по крайней мере ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Magnum72 Опубликовано 14 ноября, 2009 · Жалоба Могу ли я на свиче агрегации прописать на интерфейсе VLANа, который будет отдан юрику, белый адрес и отдать юрику этот адрес в качестве шлюза по-умолчанию? Т.е. не возникнут ли проблемы при смешении белого и серого адресного пространств? В теории всё вроде как ок: пакеты от юрика пошли на интерфейс этого VLANа, на свиче агрегации ушли на дефолтный шлюз, которым будет интферфейс VLANа на коммутаторе ядра, путь этот адрес и серый, а с него на локальный интерфейс бордер-роутера. Я правильно мыслю?Всё правильно, проблем не возниктет, так белые адреса экономят даже старттелеком и мегафон, по крайней мере ) Сделать то можно, но возможно столкнетесь с проблемами нехватки мест для секондари интерфейсов, во вторых если сеть не управляемая то соседи могут легко поюзать инет за счет юрика, в третьих раз у вас на агрегации прописан дефолт, то при проблемах в локалке нефиг делать положить ядро. да и pim на секондари интерфейсах мало у кого из вендоров работает, прийдется юзать мультикаст влан. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
locoz Опубликовано 14 ноября, 2009 · Жалоба <user>---<access_sw>--[user_vlan]--<agg_sw>--[manage_vlan]--<core_sw>---<access_server/border>---<provider> Создавать себе и юрику гемор с доступом очень не хочется. нарисуйте схему, ибо ничего не понятно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
locoz Опубликовано 14 ноября, 2009 · Жалоба Сделать то можно, но возможно столкнетесь с проблемами нехватки мест для секондари интерфейсов, во вторых если сеть не управляемая то соседи могут легко поюзать инет за счет юрика, в третьих раз у вас на агрегации прописан дефолт, то при проблемах в локалке нефиг делать положить ядро. да и pim на секондари интерфейсах мало у кого из вендоров работает, прийдется юзать мультикаст влан. Поясните, если не затруднит, при каких, например, проблемах в локалке может лечь ядро? И о каких "местах" для вторичных интерфейсов идёт речь? Что есть pim? Неловко за безграмотность, но мой опыт в сетестроительстве ограничивается корпоративными сетями, никогда с операторскими сетями дела не имел. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Valaskor Опубликовано 15 ноября, 2009 · Жалоба не возникнут ли проблемы при смешении белого и серого адресного пространств?У вас получится смешанная таблица маршрутизации.Основная проблема в том, что юзерам с серыми адресами станет доступен дефолтный маршрут, в следствии этого они могут начать слать всякую вирусную фигню в инет. Поэтому: 1. на интерфейсы в сторону серых сете включить check reverse path или acl с проверкой src ip - от подмен адресов на реальные 2. acl на выход с дефолтного интерфейса - выпускать только с допустимыми src ip, чтоб отрезать вирусные ddosы как можно раньше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 15 ноября, 2009 (изменено) · Жалоба С абонентами-физиками пока всё понятно, будут ходить в инет через РРТР, юрикам же хотелось бы отдавать как минимум /30 подсеть белых адресов, причём без использования каких-либо туннелей. Странное решение. Физики у вас ходят по VPN, фактически с большей степенью изоляции трафика, чем могут обеспечить вланы, а юрики будут маршрутизироваться. По идее, стоило бы сделать наоборот: физикам -- вланы (не per-user, а например по одному на каждый downlink в агрегации), юрикам -- VPN, чтобы можно было и шифрование включить, если кому-то вдруг понадобится. Либо отказаться от VPN для физиков и всем все сделать на вланах. Еще не понятно, почему используется PPTP, а не L2TP? Изменено 15 ноября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrei Опубликовано 15 ноября, 2009 · Жалоба стоило бы сделать наоборот: физикам -- вланы (не per-user, а например по одному на каждый downlink в агрегации), юрикам -- VPN, чтобы можно было и шифрование включить, если кому-то вдруг понадобится. Даже если сеть построена частично на неуправляемых "мыльницах"? Т.е. в центре свич конечно управляемый, на доме центральный свич тоже, а в подъездах - мыльницы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 15 ноября, 2009 (изменено) · Жалоба Даже если сеть построена частично на неуправляемых "мыльницах"? Т.е. в центре свич конечно управляемый, на доме центральный свич тоже, а в подъездах - мыльницы. Тегирование делается только на портах управляемых свичей, на "мыльницы" и юзерские порты идет нетегированный трафик. Изменено 15 ноября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dsk Опубликовано 16 ноября, 2009 · Жалоба locoz: у вас на доступе стоят управляемые свичи или тупые? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
locoz Опубликовано 17 ноября, 2009 · Жалоба locoz: у вас на доступе стоят управляемые свичи или тупые? На доступе будут des-3526. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dsk Опубликовано 17 ноября, 2009 · Жалоба Тогда делайте отдельные вланы для юриков, + курите ACL для всех. PPTP тоже уберите, накой этот костыль нужен вместе с отлично управляемым доступом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
locoz Опубликовано 17 ноября, 2009 · Жалоба Тогда делайте отдельные вланы для юриков, + курите ACL для всех. PPTP тоже уберите, накой этот костыль нужен вместе с отлично управляемым доступом. Мне по малоопытности не очень ясно, каким образом в таком случае идентифицировать и обсчитывать абонентов-физиков, ведь адреса раздаются динамические?... РРТР предполагалось применять именно для этого. Биллинг и бордер в одном флаконе будет представлен в виде Ideco ICS 2.5. Там есть тип авторизации по mac+ip, но как отследить маки юзеров? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 17 ноября, 2009 (изменено) · Жалоба Там есть тип авторизации по mac+ip, но как отследить маки юзеров?Настройка DHCP-сервера с привязками IP-MAC и опцией 82: http://www.opennet.ru/base/net/dhcp_ip_mac.txt.html http://xgu.ru/wiki/DHCP_option_82 Для защиты от подмен создавайте на коммутаторах доступа привязки IP-MAC-port, у многих вендоров это делается средствами ACL. Изменено 17 ноября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
locoz Опубликовано 17 ноября, 2009 · Жалоба Там есть тип авторизации по mac+ip, но как отследить маки юзеров?Настройка DHCP-сервера с привязками IP-MAC и опцией 82: http://www.opennet.ru/base/net/dhcp_ip_mac.txt.html http://xgu.ru/wiki/DHCP_option_82 Для защиты от подмен создавайте на коммутаторах доступа привязки IP-MAC-port, у многих вендоров это делается средствами ACL. И как выглядит процесс накопления информации для этой привязки? Подключили нового абонента, монтажник смотрит, какой выдался абоненту IP, сообщает админу, а тот лезет в dhcp.leases искать там мас, которому отдался этот ip, после чего лезет на свич доступа и вбивает привязку? Ну и после каждого подключения нового абонента бекапить конфиг свича? А не много ль гемора? Просто я, видимо, не столь сильно люблю абонентов, что бы столько испытать, имея целью обеспечить им сладкую жизнь в стиле "воткнули кабель и сразу инет" :) Мне почему-то видится куда более простым создание РРТР-соединения и администрирование сервера доступа. Поправьте, если моё видение ошибочно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Konstantin Klimchev Опубликовано 17 ноября, 2009 · Жалоба И как выглядит процесс накопления информации для этой привязки?Подключили нового абонента, монтажник смотрит, какой выдался абоненту IP, сообщает админу, а тот лезет в dhcp.leases искать там мас, которому отдался этот ip, после чего лезет на свич доступа и вбивает привязку? Ну и после каждого подключения нового абонента бекапить конфиг свича? А не много ль гемора? Просто я, видимо, не столь сильно люблю абонентов, что бы столько испытать, имея целью обеспечить им сладкую жизнь в стиле "воткнули кабель и сразу инет" :) Вам же дали ссылку про Option_82. Читайте внимательно. На доступе изначально ACLом привязывайте ip-адреса к портам (до сих пор не понимаю зачем еще мас). Потом никуда лезть не надо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Kaban Опубликовано 17 ноября, 2009 · Жалоба Opton82 это конечно хорошо, но когда появляются дубликаты МАС-ов начинается конкретная веселуха. Правда это случается довольно редко. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dsk Опубликовано 18 ноября, 2009 · Жалоба Мне почему-то видится куда более простым создание РРТР-соединения и администрирование сервера доступа. Это вам видится, а пользователям не видится. Да и потом суппорт ваш затрахается, будут и криво вбитые адреса сервера, и неснятые галки шифрования, и порнозвонилки типа 8,, и прочая вирусня. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 18 ноября, 2009 (изменено) · Жалоба когда появляются дубликаты МАС-ов начинается конкретная веселуха. Правда это случается довольно редко.Бывает и такое. Материнские платы, сетевухи или роутеры с одинаковыми MAC-адресами -- это одна из типичных китайских шуток. А по поводу того, что якобы с DHCP сложнее абонентов подключать, скажу, что нужно самому написать некий веб-интерфейс в довесок к биллингу, который эти дела автоматизирует. Или договориться с разработчиками биллинга, чтобы они это сделали. С PPTP будет масса проблем: начиная с большей дороговизны терминирующего оборудования и заканчивая уязвимостями в самом протоколе. Информация к размышлению:http://www.schneier.com/paper-pptpv2.html http://www.schneier.com/pptp-faq.html Один из крупных провайдеров, внедрявших PPTP (бывшая Корбина, сейчас -- часть Билайна), отказался от него в пользу L2TP. Изменено 18 ноября, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
shaytan Опубликовано 18 ноября, 2009 (изменено) · Жалоба vlan-per-user + ip unnumbered for vlan-svi interfaces Изменено 18 ноября, 2009 пользователем shaytan Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...