Вообще так:
1) щетка шлет твит «у меня появились седые волосы и кажется что вообще я лысею»
2) шарф-маска тоже шлет твит «подышал гадостью» и 50 «мне понравилось» под ним
3) шорты могут вибрировать и для других целей. Подкачка попных мышц (тверк?), сигнализировать о скидках в молле («я как узнала о тех сумочках, аж затрясло») и когда парень сзади пялится (а вот тут камера нужна на спину)
4) трость. Твит «прогнала от подъезда двух наркоманов и одну проститутку». «Петровне и Ивановне это нравится».
5) «Ваша игра дерьмо! Я почуствовал это, как только вступил на ландшафт из полигонов»
6) ну вот шорты только что ок, хотя можно взять обычные и прошить между тканью мелкую металлическую сетку. Можно прикалываться в аэропорту на металлодетекторе, наверное.
Вряд ли это уже для вас актуально, все-такие три года прошло, но я оставлю это тут как решение для тех, кто будет искать:
VLAN Name Override, появилась с 8.1
===
The VLAN Name Override feature is useful in deployments that have a single central radius authenticating multiple branches. With hundreds of different branches, it becomes very difficult to standardize VLAN IDs across all sites and requires a configuration that provides a unique VLAN Name mapped locally to a VLAN ID that can be different across different branch locations.
This design involving different VLAN IDs across different sites is also useful from the sizing and scaling perspective to limit the number of clients per Layer 2 broadcast domain.
===
Закупили две точки AIR-AP1852-I-E-K9, одна работает контроллером, вторая приземляет клиентов.
Из приятного:
Веб интерфейс очень простой, все понятно настраивается.
Можно смотреть по клиентам, кто сколько какого трафика накачал (различает гугл, фейсбук, просто ssl, music streaming etc..)
Можно для выбранного SSID настроить captive portal
Можно создавать пользователей на локальном RADIUS
Для конкретного SSID можно настроить firewall (простенький, на уровне — туда ходить, а сюда нет)
Для SSID можно настроить QoS (профили Platinum, Gold, Silver, Bronze. Сами профили не настраиваются).
Из странного:
Одна из точек (ведомая) периодически сбрасывает клиентов и уходит искать контроллер. При этом она пропадает из сети. Uptime OK и порт на коммутаторе не уходит в Down/Up.
Настройки выбора канала(ов) и ширины канала, заданные в конфигурации точек, могут через определенное время "уплыть". То есть выставляешь для 2.4GHz например канал 11 и ширину 20Mhz, для 5Ghz канал 36 и ширину 80Mhz, через два часа(или дня) обнаруживаешь, что все настройки уехали в "Automatical", а 80MHz на 5-ке вернулось в дефолтные 20 и пользователи жалуются на связь.
Нет возможности настроить минимальный rate, что бы не "тянуть" медленных клиентов, которые будут мешать всем.
Обнаружение Rogue-точек на уровне "вот картинка с каналами и оранжевыми кружками". Странно. И непонятно, что с этим делать.
Питание обязательно нужно 802.3at, которое называется PoE+. С обычным 802.3af много ограничений.
Кому интересно, спрашивайте детали. Что смогу, расскажу.
p.s. Да, точки стоят в другой стране.
Поставщик сказал, что в России к заказу их нет (может стоит поискать другого)
1) Есть мой домен example.com, я настроил p=quarantine (понаблюдать).
2) Есть домен партнера partner.com, у них есть список рассылки вида group123@partner.com, в который входят получатели user1@example.com, user2@example.com
3) Мой пользователь user3@example.com шлет на group123@partner.com, в результате user1 и user2 получают это письмо помарканое как спам, потому что From: указан как example.com, а IP в SPF не из моих блоков.
4) В результате, если был бы p=reject, то письмо пропало бы вовсе.
На партнера повлиять нельзя (в плане настройки его серверов).
Замкнутый круг =(
Проясните следующее:
Я настроил у себя p=none, получаю отчеты от разных провайдеров со сводной статистикой.
Кто-то (из пользователей) настроил у себя отправку писем с from: мой-домен.tld, при этом письмо не проходит через мои сервера и теоретически дропнется в DMARC.
Вроде как есть этот отчет, но если серьезно, то на мой взгляд, он бесполезный. Я вижу только IP последнего received и временной промежуток. Нет ни оригинального From: или To:, нет темы, нет message-id. Ничего.
Что я должен делать с этими отчетами? У меня есть только информация, что письмо прошло не через мои сервера (факт получения отчета) и IP (например, какой-то IP из пула DSL в США). Я не могу узнать даже пользователя, который отправлял письмо. Что делать дальше?
1) внедрить p=reject и тупо потерять множество писем?
2) добавить этот неизвестный IP в +ip4:x.x.x.x в DNS?
3) не внедрять DMARC вообще? Какой тогда смысл.
То есть получается, что пользователи не могут настроить себе редирект на другой ящик и участвовать в подавляющем большинстве рассылок? Как они живут вообще тогда, интересно.
Вероятно, что прелесть в NAT внутри VRF. Таким образом при падении одного аплинка не надо ждать таймаутов NAT или делать clear ip nat tr *
Но нужно проверять.
1) проблема может быть в том, что если снимать netflow с «внешнего» интерфейса при том, что он является nat outside, то в show ip ca flow будут видны адреса, в которые занатился пакет (адрес на интерфейсе isp1), что делает практически бесполезным сбор netflow, так как в нем нет необходимой информации. Покажите, как вы снимате netflow (конфигурация на интерфейсах) и вывод show ip ca flow
Проблема с DMARC еще в том, что это совершенно отвратительно работает со списками рассылки. Цитата из FAQ по DMARC:
Is there special handling required to receive DMARC email from mailing lists?
Mailing lists usually do not take authorship of the emails they relay. It means the From: header in the email will not contain the domain name of the mailing list, and if the mailing list add DKIM to all its emails, DKIM d= will not match. If the domain in the From: header is from an organization that publishes a DMARC record, the email is likely to not be delivered. If emails from mailing lists are important to your users, you may therefore consider to apply specific rules for emails coming from mailing lists. These rules can be assimilated to a sort of whitelist, but you need to be careful, as to not allow others to exploit these rules. You could take benefit of the «Original Authentication Results» header of mailing lists that support this feature.
А из реально «жестких» примеров я видел paypal.com и amazon.com, причем первый ставит вообще reject.
Появилось несколько вопросов.
1) как при такой схеме работает сбор Netflow?
2) не уверен, что директива log в ACL это хорошая идея. Роутер умрет на реальной загрузке.
3) в обоих sla у вас используется vrf isp1. Это ошибка?
4) почему в ip route vrf isp2 0.0.0.0 0.0.0.0 9.9.9.2 120 нет трекинга sla?
https://developers.google.com/speed/public-dns/docs/dns-over-https
Никто не встречал реализации для client side?
1) щетка шлет твит «у меня появились седые волосы и кажется что вообще я лысею»
2) шарф-маска тоже шлет твит «подышал гадостью» и 50 «мне понравилось» под ним
3) шорты могут вибрировать и для других целей. Подкачка попных мышц (тверк?), сигнализировать о скидках в молле («я как узнала о тех сумочках, аж затрясло») и когда парень сзади пялится (а вот тут камера нужна на спину)
4) трость. Твит «прогнала от подъезда двух наркоманов и одну проститутку». «Петровне и Ивановне это нравится».
5) «Ваша игра дерьмо! Я почуствовал это, как только вступил на ландшафт из полигонов»
6) ну вот шорты только что ок, хотя можно взять обычные и прошить между тканью мелкую металлическую сетку. Можно прикалываться в аэропорту на металлодетекторе, наверное.
VLAN Name Override, появилась с 8.1
===
The VLAN Name Override feature is useful in deployments that have a single central radius authenticating multiple branches. With hundreds of different branches, it becomes very difficult to standardize VLAN IDs across all sites and requires a configuration that provides a unique VLAN Name mapped locally to a VLAN ID that can be different across different branch locations.
This design involving different VLAN IDs across different sites is also useful from the sizing and scaling perspective to limit the number of clients per Layer 2 broadcast domain.
===
tcpdump -ni eth0 -E aes128-hmac96@0x2a787e41bbdc2f949ced721c7fcf934e 'ip[20:4] = 0x97e0f68e'
Могу немного рассказать.
Закупили две точки AIR-AP1852-I-E-K9, одна работает контроллером, вторая приземляет клиентов.
Из приятного:
Из странного:
Питание обязательно нужно 802.3at, которое называется PoE+. С обычным 802.3af много ограничений.
Кому интересно, спрашивайте детали. Что смогу, расскажу.
p.s. Да, точки стоят в другой стране.
Поставщик сказал, что в России к заказу их нет (может стоит поискать другого)
1) Есть мой домен example.com, я настроил p=quarantine (понаблюдать).
2) Есть домен партнера partner.com, у них есть список рассылки вида group123@partner.com, в который входят получатели user1@example.com, user2@example.com
3) Мой пользователь user3@example.com шлет на group123@partner.com, в результате user1 и user2 получают это письмо помарканое как спам, потому что From: указан как example.com, а IP в SPF не из моих блоков.
4) В результате, если был бы p=reject, то письмо пропало бы вовсе.
На партнера повлиять нельзя (в плане настройки его серверов).
Замкнутый круг =(
Я настроил у себя p=none, получаю отчеты от разных провайдеров со сводной статистикой.
Кто-то (из пользователей) настроил у себя отправку писем с from: мой-домен.tld, при этом письмо не проходит через мои сервера и теоретически дропнется в DMARC.
Вроде как есть этот отчет, но если серьезно, то на мой взгляд, он бесполезный. Я вижу только IP последнего received и временной промежуток. Нет ни оригинального From: или To:, нет темы, нет message-id. Ничего.
Что я должен делать с этими отчетами? У меня есть только информация, что письмо прошло не через мои сервера (факт получения отчета) и IP (например, какой-то IP из пула DSL в США). Я не могу узнать даже пользователя, который отправлял письмо. Что делать дальше?
1) внедрить p=reject и тупо потерять множество писем?
2) добавить этот неизвестный IP в +ip4:x.x.x.x в DNS?
3) не внедрять DMARC вообще? Какой тогда смысл.
Если интересно, могу вспомнить детали.
но нужно проверять.
Но нужно проверять.
А из реально «жестких» примеров я видел paypal.com и amazon.com, причем первый ставит вообще reject.
1) как при такой схеме работает сбор Netflow?
2) не уверен, что директива log в ACL это хорошая идея. Роутер умрет на реальной загрузке.
3) в обоих sla у вас используется vrf isp1. Это ошибка?
4) почему в ip route vrf isp2 0.0.0.0 0.0.0.0 9.9.9.2 120 нет трекинга sla?
На volgasg.megafon.ru/ROBOTS/SC_TRAY_INFO?X_Username=USER&X_Password=PASS сервер отвечает 403.
Поддержка мегафона пока тормозит с ответом и говорит что-то о запуске нового сервиса lk.megafon.ru