Jump to content

Recommended Posts

Posted (edited)

День добрый.

 

Возник вопрос. Мы VPN-провайдер (ибо у нас в городе есть всеобъемлющая LAN нескольких провайдеров).

Сейчас мы решаем выйти на клиентов с непосредственным подключением в домах по Ethernet. Соответственно вопрос:

 

Если делать авторизацию пользователей по PPPoE, то это очень удобно для нас с точки зрения учета сессий и т.п.

Отбрить клиента легко при отрицательном балансе. В общем, те же плюсы, что и при PPTP.

 

Реалии таковы, что большинство клиентов ожидают доступ к городской сети на скорости порта 100Mbit, соответственно, если

делать это по PPPoE, ни один BRAS за разумные деньги не выдержит (к тому же у нас торренты в городе в большом фаворе).

 

Хотелось бы иметь городскую сеть на свитчах без BRAS (возможно с VLAN-per-User) чтобы весь внутренний и городской трафик

разливать в ядре сети. Клиентов привязывать по MAC. Адреса белые.

 

А внешний трафик через рутер пускать в ТТК, РТК через 7206VXR.

 

Сеть будет полностью на управляемом оборудовании.

 

Вот, сейчас мне видится схема таким образом:

 

L3-свич ядра (смотрю на BigIron JetCore) (BGP с пирами в городе) + default на Shape-Vyatta/Linux, дальше на 7206VXR (РТК, ТТК). Без использования PPPoE и других механизмов контроля сессий. Если отрубаем внешний траф, то Deny на Shape-Vyatta.

 

Если отрубаем город, то выключаем VLAN на L3 в ядре (ну или на свичах доступа) в зависимости от реализации. Свичи доступа Extreme Alpine3808 (там можно набивку в 160 FastEthernet портов делать, да и цена за БУ полного фарша < 1000USD). Магистрали сети на оптике - 1Gbit звезда и кольца.

 

Покритикуйте. Если есть лучше схемы, прошу поделиться.

 

PS. Время от времени встречаю информацию по IPoE/ISG, если есть вменяемый мануал прошу ссылку дать, что-то Google мне ничего внятного не говорит.

Edited by dignity
Posted
Реалии таковы, что большинство клиентов ожидают доступ к городской сети на скорости порта 100Mbit, соответственно, если

делать это по PPPoE, ни один BRAS за разумные деньги не выдержит (к тому же у нас торренты в городе в большом фаворе).

ну конечно... абонентов то сколько в он-лайне?

я бы сказал с нарезкой полос не выдержит, а тупо концентрировать PPPoE сессии и роутить гигабитные скорости сможет.

 

Хотелось бы иметь городскую сеть на свитчах без BRAS (возможно с VLAN-per-User) чтобы весь внутренний и городской трафик

разливать в ядре сети. Клиентов привязывать по MAC. Адреса белые.

да без проблем, только учитывайте требования СОРМ-2

 

 

 

а клиента надо не к МАС-у привязывать а к порту коммутатора.

 

Posted

Когда мы использовали VPN/PPPoE, клиентам при подключении настраивались локальные маршруты, чтобы трафик к 192.168.*, 10.* и 172.16.* шёл не в туннель, а на LAN-шлюз.

 

На VPN-сервере трафик к локальным получателям запрещался файрволлом,

исключение было только для доступа на официальный сайт и личный кабинет.

 

Такая же схема, насколько я знаю, использовалась в Корбине.

Posted
Когда мы использовали VPN/PPPoE, клиентам при подключении настраивались локальные маршруты, чтобы трафик к 192.168.*, 10.* и 172.16.* шёл не в туннель, а на LAN-шлюз.

 

На VPN-сервере трафик к локальным получателям запрещался файрволлом,

исключение было только для доступа на официальный сайт и личный кабинет.

 

Такая же схема, насколько я знаю, использовалась в Корбине.

Типичный случай, когда провайдер делает так как удобно ему, а не пользователю.
Posted
Типичный случай, когда провайдер делает так как удобно ему, а не пользователю.
Привет Скайнету ;-)

Решением стал плавный отказ от VPN и PPPoE с переходом на привязку IP-MAC-Port.

Posted
Типичный случай, когда провайдер делает так как удобно ему, а не пользователю.
Привет Скайнету ;-)

Решением стал плавный отказ от VPN и PPPoE с переходом на привязку IP-MAC-Port.

А таки эта схема работает?

А то я уже и DHCP-сервер под это дело ваяю, и управление веб-смартами... Стоит ли?

Posted

Решением стал плавный отказ от VPN и PPPoE с переходом на привязку IP-MAC-Port.

А таки эта схема работает?

А то я уже и DHCP-сервер под это дело ваяю, и управление веб-смартами... Стоит ли?

Главный критерий - количество заявок в техподдержку.

После отказа от VPN/PPPoE оно уменьшилось _примерно_ раза в два.

Posted

Решением стал плавный отказ от VPN и PPPoE с переходом на привязку IP-MAC-Port.

А таки эта схема работает?

А то я уже и DHCP-сервер под это дело ваяю, и управление веб-смартами... Стоит ли?

Главный критерий - количество заявок в техподдержку.

После отказа от VPN/PPPoE оно уменьшилось _примерно_ раза в два.

Что и требовалось доказать ;).

Не подскажете - какой используете биллинг? Или своё? Слабо представляю, как прикрутить то, что у меня получается, к какому-либо биллингу.

Как выдаете клиентам внешние айпи? Натите на пачку адресов? Я вот думаю по получению айпи клиентом (внутреннего) делать stateless nat (т.е тупо менять source/destination) по принципу один внутренний айпи = один внешний.

Posted
Не подскажете - какой используете биллинг? Или своё?

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

 

Как выдаете клиентам внешние айпи? Натите на пачку адресов?

Я вот думаю по получению айпи клиентом (внутреннего) делать stateless nat

(т.е тупо менять source/destination) по принципу один внутренний айпи = один внешний.

Используем несколько разных биллингов плюс кучу собственных костылей.

Для управления коммутаторами написано собственное ПО:

http://forum.nag.ru/forum/index.php?showtopic=54023

Сейчас обслуживает 4 биллинга и ~2.5k устройств разных типов.

 

Адреса выдаём статически, так сложилось много лет назад,

тестовое внедрение DHCP показало, что выигрыш минимальный (в нашем случае).

 

Для публичных адресов есть статическая подсеть в отдельном VLAN,

плюс BiNAT на шлюзе для тех клиентов, до которых этот VLAN не прокинуть.

Правила BiNAT для PF и iptables+ipset строятся из биллинга автоматически.

Posted
Типичный случай, когда провайдер делает так как удобно ему, а не пользователю.
Привет Скайнету ;-)

Решением стал плавный отказ от VPN и PPPoE с переходом на привязку IP-MAC-Port.

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

Клиентов можно привязывать и по порту/VLAN.

 

Вообще, идеальная картина мира для нас такая: Клиент заехал в дом, видит стоит розетка (и бумажка "воткнись - будет тебе счастье) - воткнулся - страница сайта где написано куда звонить/идти/платить.

 

Posted
Для управления коммутаторами написано собственное ПО:

http://forum.nag.ru/forum/index.php?showtopic=54023

Сейчас обслуживает 4 биллинга и ~2.5k устройств разных типов.

О, то что надо! =) И даже на перле.

Я понимаю, что документации нет, но может где завалялись комментарии, какая ф-ция в модулях управления коммутаторами что делает? Какие из них обязательны? А то у меня под мои TP-Link-и уже кое-чего написано, так что просто возьму и перетащу.

Posted
Для управления коммутаторами написано собственное ПО:

http://forum.nag.ru/forum/index.php?showtopic=54023

Сейчас обслуживает 4 биллинга и ~2.5k устройств разных типов.

О, то что надо! =) И даже на перле.

Я понимаю, что документации нет, но может где завалялись комментарии, какая ф-ция в модулях управления коммутаторами что делает? Какие из них обязательны? А то у меня под мои TP-Link-и уже кое-чего написано, так что просто возьму и перетащу.

Все вопросы по routers_mgmt задавайте в соответствующей теме:

http://forum.nag.ru/forum/index.php?showtopic=54023

Join the conversation

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

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.