Целый список вопросов по поводу моей wisp-операции.

В основном, именно этим мы и занимаемся. Большинство работает нормально для PPPoE как такового, но у многих возникают странные взаимодействия с различными методами MAC-NAT, которые используют распространенные CPE. Особенно важно убедиться, что маршрутизаторы включают тег “Host-Uniq” в свои PADI-пакеты. У нас обычно плохой опыт с Netgear и D-Link, и обычно хороший с Trandnet, Sonicwall и Linksys. Хотя на самом деле это очень сильно зависит от конкретной модели и версии прошивки, так что обязательно протестируйте всё тщательно перед развертыванием. Не продавайте конкретную комбинацию CPE и маршрутизатора, пока не будете точно знать, чего ожидать. Конечно, использование MT для маршрутизатора и/или CPE клиента полностью решает эту проблему. Сначала можно использовать централизованный PPPoE-сервер на вашем бридже в процессе конвертации. Затем, когда все в определенном сегменте будут конвертированы, вы сможете перевести PPPoE-терминацию на локальный концентратор. Начните с добавления ваших новых MT AP в сеть, как обычные AP; и как только все пользователи на этом AP будут конвертированы, отключите бридж и завершите их PPPoE на AP. Мы обнаружили, что 1492 обычно хорошо работает для MTU, с обеих сторон. Хотя были исключительные случаи, которые требовалось обрабатывать индивидуально. Мы обычно используем 10 сек для таймаута, и мы не отключаемся на основе времени простоя. Старайтесь минимизировать потерю пакетов и джиттер, максимально стабилизируя беспроводные сети (фиксированные скорости передачи данных и т.д.). Храните как можно больше индивидуальных настроек пользователей в центральной базе данных, стараясь избежать привязки клиентов к конкретному маршрутизатору/AP. Также старайтесь избегать необычных настроек на ваших AP и маршрутизаторах, делайте их легко воспроизводимыми. Radius — ваш друг. Если возможно, назначайте IP-адреса как можно большему числу пользователей из локальных пулов, и объявляйте эти пулы в вашем маршрутном протоколе как агрегат, а не как отдельные /32. Когда пользователю нужен переносной статический IP, нормально объявлять их /32, но старайтесь, чтобы таких было как можно меньше. –Eric

Ну, тут с тобой не согласен. PPPoE упрощает управление сетью. Настраиваешь IP-пулы, даешь роутеру выдавать частные IP-адреса пользователям и назначаешь несколько публичных, а потом можешь просто отойти и дать роутеру делать свою работу. Единственный минус, с которым я сталкивался — непостоянство в поддержании сессии. Хотелось бы, чтобы была возможность сделать это более надежным.

Перешёл на PPPoe около двух лет назад и очень рад этому, честно говоря. Без назначенного IP-адреса для беспроводного интерфейса это гораздо сложнее, чем подделывать MAC-адрес и вводить правильный IP. Да и чем меньше клиент должен настраивать, тем лучше, то есть IP-адреса и прочее. Как только они пройдут PPPoe-мастера и установят соединение, мы контролируем всё остальное. PPPoe также позволяет нашим пользователям использовать любое устройство в сети, а также подключаться к любому из 10 передатчиков по городу, используя одно и то же имя пользователя и пароль. Если честно, PPPoe – это единственный верный путь.

Ладно, PPPoE требует определенного обучения, но что делать в ситуациях, когда:

Клиентам нужен маршрутизируемый IP? Без проблем, Cisco PIX со статическим правилом и кондуктами.
Клиенты хотят запускать серверы? Без проблем, Cisco PIX со статическим правилом и кондуктами.
Клиенты используют мультихоминг, то есть два ISP? Никогда не было проблем.
Клиенты подключаются к вам с разных направлений? Хм?
Клиентам нужен BGP? Мои клиенты — это частные лица и малый бизнес. Зачем им BGP?
Клиенты используют свои собственные IP-адреса? Мои клиенты — это частные лица и малый бизнес. Зачем им свои IP-адреса?
Клиенты сами являются провайдерами? Настоящий провайдер никогда не станет покупать трафик через PPPoE-соединение.

NAT и статические маршруты — это нормально (и очень полезно, не поймите меня неправильно, я часто использую оба), но ни то, ни другое не масштабируется. Когда и где я сказал, что использую статические маршруты?

Кстати, файрвол может стать настоящей проблемой (особенно если у вас клиенты, которые всё считают до копейки), если не делать его ОЧЕНЬ тщательно и на детальном уровне. Я просто использую свой файрвол для предоставления NAT. Я не даю своим клиентам никаких гарантий безопасности файрволом и не несу никакой ответственности.

WEP* я бы полностью отверг как механизм контроля доступа, его слишком легко взломать (либо прямым взломом, либо просто через нечестных клиентов). Это хорошо лишь для отпугивания случайных хакеров, IMHO. Может помочь остановить бестолковых, но бесполезно против решительных.

К тому же, любая система, которая зависит от адресов MAC и/или IP-адресов источника, будет взломана кем угодно, даже теми, кто совсем не в теме – это слишком просто.

Опять же, я не согласен. У меня никогда не было украденного соединения.

*WPA и подобные вещи немного лучше, но все равно не защищают вас от плохих клиентов. Может, нам просто согласиться, что мы не согласны?

Эрик.

Давай вернёмся к роутерам и их настройкам. Что конкретно нам нужно использовать для роутеров? И если я могу использовать D-Link, какие настройки PPPoE мне нужно будет вводить для режима (always on, manual, connect-on-demand) и времени простоя? MTU установлен на 1492. Мне нужно настроить их так, чтобы даже если сессия обрывается, она быстро восстанавливалась. Нужно, чтобы клиентский опыт был приятным.

Я должна установить MRU одинаковый?

Да, но сколько в итоге стоило заменить все роутеры?

Стоило поменять роутеры – теперь никаких проблем… и используем теперь только Zyxel, остались совсем немного Linksys – они тоже работают, после некоторых обновлений прошивки…

Если я смотрю сессию на Mikrotik, Dlink’и переподключаются каждые несколько минут (от 4 минут до 10 часов), и я получаю звонки от клиентов с жалобами на отсутствие интернета. Перезагружаю Dlink, и все снова работает как надо. А вот Linksys — никаких проблем, сессии остаются открытыми днями, прежде чем переподключится, и звонков о них не приходит.