[Kaban]

Фильтровать на свичах левые PPPoE сервера на порядок проще чем фильтровать кривые ARP пакеты.

 

Ни разу не наблюдал ситуации когда под виндой не работает pppoe но работает pptp, зато обратная ситуация наблюдалась регулярно. Это и стало основной причиной по которой от развития pptp отказались.

Изменено 9 апреля, 2010 пользователем Kaban

[Ivan_83]

Я согласен с вашими доводами, касательно того что PPPoE есть в каждой железке.

И меня, в не операторских применениях, PPTP достал со своим GRE, потому я перешёл на L2TP.

 

А как пользователя интернетов мне уже порядком надоели все PPP (PPPoE, PPTP, L2TP), хочется просто вбить настройки в сетевуху (или автоматом получить по DHCP) и не воспоминать больше об этом.

 

Помню в одной конторе стояла ISA2006, пока дсл модем стоял бриджем и настройки были прописаны в сетевуху статикой всё было шикарно - иса2006 ничего не знала об обрывах и работала себе. Потом сделали нам PPTP, и началось... Да, это проблемы ISA2006 что она не умеет адекватно поднимать ппп соединения, но всё было проще и работало стабильно без ппп.

 

Кроме того, любой ппп это оверхэд по сравнению с эзернетом, не только по заголовкам в пакете, но и по производительности.

[SokolovS]

Фильтровать на свичах левые PPPoE сервера на порядок проще чем фильтровать кривые ARP пакеты.

Ерунда, в D-Link 3526 функция ARP Spoofing Prevention в два клика делает фильтр. Да в общем то связку "IP-MAC шлюза" не проблема в любых ACL сделать.

IPoE работает что тут еще скажешь, но перерасход IP по сравнение с PPTP/L2TP, PPPoE напрягает :(

 

[Kaban]

ARP Spoofing Prevention всего лишь костыль в виде статической привязки МАК-а к IP реализованой через через правила CBACL. И ставят ее для защиты от спуфинга адреса шлюза, что абсолютно не помешает хулиганам или вирусне спуфить мак-и других юзеров создавая геморой юзерам и саппорту. Каждый раз когда меняется МАК шлюза это правило надо обновлять. А фильтр на левые PPPoE сервера состоящий из одного CBACL устанавливается один единственнный раз на все клиентские порты после чего о нем забывают.

[photon]

Это все сказки по поводу того, что якобы в IPoE против спуфинга нет приема. Делается ACL правило с привязкой вида ip-mac-switch port, и пакеты пришедшие на данный порт коммутатора с какими-либо другими IP или mac будут отброшены. В некоторых свичах есть даже автоматическое выключение порта при спуфинге. Да, для поддержки этих правил нужен биллинг, умеющий рулить свичами. А кому он не нужен при количестве пользователей более 1000?

 

Каждый раз когда меняется МАК шлюза это правило надо обновлять.

Еще раз: на абонентском порту свича доступа создается ACL, содержащий IP абонента, MAC абонента и номер порта свича. Нигде никаких маков шлюза не используется. Все просто.

Изменено 11 апреля, 2010 пользователем photon

[s.lobanov]

>Да, для поддержки этих правил нужен биллинг, умеющий рулить свичами. А кому он не нужен при количестве пользователей более 1000?

 

Зачем? dhcp snooping+ip source guard. А если кому-то нужна статика, то прописывать соответствие ip-mac(хотя безопаснее ip-option82) на dhcp-сервере, а не на коммутаторе. Тогда из биллинга надо рулить только dhcp-сервером, что куда проще, чем железом, которое может быть, вообще говоря, недоступно.