Перейти к содержимому
Калькуляторы

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

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Что есть pim?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем 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.

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

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

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

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем shaytan

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.