Как в серой сети раздать юрикам белые адреса без применения PPPoE/PPTP?

[locoz]

Молодой ethernet-провайдер строит сеть :)

 

Один VLAN на один свич доступа, абоненты получают серые адреса от DHCP opt.82 по признаку порта на свиче агрегации.

С абонентами-физиками пока всё понятно, будут ходить в инет через РРТР, юрикам же хотелось бы отдавать как минимум /30 подсеть белых адресов, причём без использования каких-либо туннелей.

Могу ли я на свиче агрегации прописать на интерфейсе VLANа, который будет отдан юрику, белый адрес и отдать юрику этот адрес в качестве шлюза по-умолчанию? Т.е. не возникнут ли проблемы при смешении белого и серого адресного пространств? В теории всё вроде как ок: пакеты от юрика пошли на интерфейс этого VLANа, на свиче агрегации ушли на дефолтный шлюз, которым будет интферфейс VLANа на коммутаторе ядра, путь этот адрес и серый, а с него на локальный интерфейс бордер-роутера. Я правильно мыслю?

[Andrеw]

нарисуйте схему, ибо ничего не понятно

[Nafanya]

создайте ещё один vlan для юрика и прокиньте его до агрегации или хоть до самого бордера.

[nevzorofff]

Могу ли я на свиче агрегации прописать на интерфейсе VLANа, который будет отдан юрику, белый адрес и отдать юрику этот адрес в качестве шлюза по-умолчанию? Т.е. не возникнут ли проблемы при смешении белого и серого адресного пространств? В теории всё вроде как ок: пакеты от юрика пошли на интерфейс этого VLANа, на свиче агрегации ушли на дефолтный шлюз, которым будет интферфейс VLANа на коммутаторе ядра, путь этот адрес и серый, а с него на локальный интерфейс бордер-роутера. Я правильно мыслю?

Всё правильно, проблем не возниктет, так белые адреса экономят даже старттелеком и мегафон, по крайней мере )

 

[Magnum72]

Могу ли я на свиче агрегации прописать на интерфейсе VLANа, который будет отдан юрику, белый адрес и отдать юрику этот адрес в качестве шлюза по-умолчанию? Т.е. не возникнут ли проблемы при смешении белого и серого адресного пространств? В теории всё вроде как ок: пакеты от юрика пошли на интерфейс этого VLANа, на свиче агрегации ушли на дефолтный шлюз, которым будет интферфейс VLANа на коммутаторе ядра, путь этот адрес и серый, а с него на локальный интерфейс бордер-роутера. Я правильно мыслю?

Всё правильно, проблем не возниктет, так белые адреса экономят даже старттелеком и мегафон, по крайней мере )

Сделать то можно, но возможно столкнетесь с проблемами нехватки мест для секондари интерфейсов, во вторых если сеть не управляемая то соседи могут легко поюзать инет за счет юрика, в третьих раз у вас на агрегации прописан дефолт, то при проблемах в локалке нефиг делать положить ядро. да и pim на секондари интерфейсах мало у кого из вендоров работает, прийдется юзать мультикаст влан.

[locoz]

<user>---<access_sw>--[user_vlan]--<agg_sw>--[manage_vlan]--<core_sw>---<access_server/border>---<provider>

 

 

Создавать себе и юрику гемор с доступом очень не хочется.

 

нарисуйте схему, ибо ничего не понятно

[locoz]

Сделать то можно, но возможно столкнетесь с проблемами нехватки мест для секондари интерфейсов, во вторых если сеть не управляемая то соседи могут легко поюзать инет за счет юрика, в третьих раз у вас на агрегации прописан дефолт, то при проблемах в локалке нефиг делать положить ядро. да и pim на секондари интерфейсах мало у кого из вендоров работает, прийдется юзать мультикаст влан.

Поясните, если не затруднит, при каких, например, проблемах в локалке может лечь ядро? И о каких "местах" для вторичных интерфейсов идёт речь?

Что есть pim?

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

[Valaskor]

не возникнут ли проблемы при смешении белого и серого адресного пространств?

У вас получится смешанная таблица маршрутизации.

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

1. на интерфейсы в сторону серых сете включить check reverse path или acl с проверкой src ip - от подмен адресов на реальные

2. acl на выход с дефолтного интерфейса - выпускать только с допустимыми src ip, чтоб отрезать вирусные ddosы как можно раньше.

[photon]

С абонентами-физиками пока всё понятно, будут ходить в инет через РРТР, юрикам же хотелось бы отдавать как минимум /30 подсеть белых адресов, причём без использования каких-либо туннелей.

Странное решение. Физики у вас ходят по VPN, фактически с большей степенью изоляции трафика, чем могут обеспечить вланы, а юрики будут маршрутизироваться. По идее, стоило бы сделать наоборот: физикам -- вланы (не per-user, а например по одному на каждый downlink в агрегации), юрикам -- VPN, чтобы можно было и шифрование включить, если кому-то вдруг понадобится. Либо отказаться от VPN для физиков и всем все сделать на вланах. Еще не понятно, почему используется PPTP, а не L2TP?

Edited November 15, 2009 by photon

[Andrei]

стоило бы сделать наоборот: физикам -- вланы (не per-user, а например по одному на каждый downlink в агрегации), юрикам -- VPN, чтобы можно было и шифрование включить, если кому-то вдруг понадобится.

Даже если сеть построена частично на неуправляемых "мыльницах"? Т.е. в центре свич конечно управляемый, на доме центральный свич тоже, а в подъездах - мыльницы.

[photon]

Даже если сеть построена частично на неуправляемых "мыльницах"? Т.е. в центре свич конечно управляемый, на доме центральный свич тоже, а в подъездах - мыльницы.

Тегирование делается только на портах управляемых свичей, на "мыльницы" и юзерские порты идет нетегированный трафик.

Edited November 15, 2009 by photon

[dsk]

locoz: у вас на доступе стоят управляемые свичи или тупые?

[locoz]

locoz: у вас на доступе стоят управляемые свичи или тупые?

На доступе будут des-3526.

[dsk]

Тогда делайте отдельные вланы для юриков, + курите ACL для всех. PPTP тоже уберите, накой этот костыль нужен вместе с отлично управляемым доступом.

[locoz]

Тогда делайте отдельные вланы для юриков, + курите ACL для всех. PPTP тоже уберите, накой этот костыль нужен вместе с отлично управляемым доступом.

Мне по малоопытности не очень ясно, каким образом в таком случае идентифицировать и обсчитывать абонентов-физиков, ведь адреса раздаются динамические?...

РРТР предполагалось применять именно для этого. Биллинг и бордер в одном флаконе будет представлен в виде Ideco ICS 2.5. Там есть тип авторизации по mac+ip, но как отследить маки юзеров?

[photon]

Там есть тип авторизации по 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.

Edited November 17, 2009 by photon

[locoz]

Там есть тип авторизации по 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, после чего лезет на свич доступа и вбивает привязку? Ну и после каждого подключения нового абонента бекапить конфиг свича? А не много ль гемора? Просто я, видимо, не столь сильно люблю абонентов, что бы столько испытать, имея целью обеспечить им сладкую жизнь в стиле "воткнули кабель и сразу инет" :)

Мне почему-то видится куда более простым создание РРТР-соединения и администрирование сервера доступа.

 

Поправьте, если моё видение ошибочно.

 

[Konstantin Klimchev]

И как выглядит процесс накопления информации для этой привязки?

Подключили нового абонента, монтажник смотрит, какой выдался абоненту IP, сообщает админу, а тот лезет в dhcp.leases искать там мас, которому отдался этот ip, после чего лезет на свич доступа и вбивает привязку? Ну и после каждого подключения нового абонента бекапить конфиг свича? А не много ль гемора? Просто я, видимо, не столь сильно люблю абонентов, что бы столько испытать, имея целью обеспечить им сладкую жизнь в стиле "воткнули кабель и сразу инет" :)

Вам же дали ссылку про Option_82. Читайте внимательно.

На доступе изначально ACLом привязывайте ip-адреса к портам (до сих пор не понимаю зачем еще мас). Потом никуда лезть не надо.

[Kaban]

Opton82 это конечно хорошо, но когда появляются дубликаты МАС-ов начинается конкретная веселуха. Правда это случается довольно редко.

[dsk]

Мне почему-то видится куда более простым создание РРТР-соединения и администрирование сервера доступа.

Это вам видится, а пользователям не видится. Да и потом суппорт ваш затрахается, будут и криво вбитые адреса сервера, и неснятые галки шифрования, и порнозвонилки типа 8,, и прочая вирусня.

[photon]

когда появляются дубликаты МАС-ов начинается конкретная веселуха. Правда это случается довольно редко.

Бывает и такое. Материнские платы, сетевухи или роутеры с одинаковыми MAC-адресами -- это одна из типичных китайских шуток. А по поводу того, что якобы с DHCP сложнее абонентов подключать, скажу, что нужно самому написать некий веб-интерфейс в довесок к биллингу, который эти дела автоматизирует. Или договориться с разработчиками биллинга, чтобы они это сделали. С PPTP будет масса проблем: начиная с большей дороговизны терминирующего оборудования и заканчивая уязвимостями в самом протоколе. Информация к размышлению:

http://www.schneier.com/paper-pptpv2.html

http://www.schneier.com/pptp-faq.html

 

Один из крупных провайдеров, внедрявших PPTP (бывшая Корбина, сейчас -- часть Билайна), отказался от него в пользу L2TP.

Edited November 18, 2009 by photon

[shaytan]

vlan-per-user + ip unnumbered for vlan-svi interfaces

Edited November 18, 2009 by shaytan