Jump to content
Калькуляторы

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

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

 

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


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

 

Share this post


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

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

Share this post


Link to post
Share on other sites

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

 

 

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

 

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

Share this post


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

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

Что есть pim?

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

Share this post


Link to post
Share on other sites
не возникнут ли проблемы при смешении белого и серого адресного пространств?
У вас получится смешанная таблица маршрутизации.

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

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

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

Share this post


Link to post
Share on other sites

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

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

Edited by photon

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

Edited by photon

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
locoz: у вас на доступе стоят управляемые свичи или тупые?

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

Share this post


Link to post
Share on other sites

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

Share this post


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

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

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

Share this post


Link to post
Share on other sites
Там есть тип авторизации по 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 by photon

Share this post


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

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

 

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

 

Share this post


Link to post
Share on other sites
И как выглядит процесс накопления информации для этой привязки?

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Мне почему-то видится куда более простым создание РРТР-соединения и администрирование сервера доступа.

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

Share this post


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

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

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

 

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

Edited by photon

Share this post


Link to post
Share on other sites

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

Edited by shaytan

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this