Jump to content

IgaX

Forum Members
  • Posts

    950
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by IgaX

  1. Боюсь, под экранами не пахнет радиаторами и теплоотводом в привычном понимании .. там что-то вроде этого:
  2. Вроде можно проще (и порой даже бесплатно) из этой серии.
  3. 1) Максимум 64 записи на каждый ACL, а если надо больше? 2) Говорят, не смотря на запреты, все примерно настолько просто: https://4pda.ru/forum/index.php?showtopic=650682 https://4pda.ru/forum/index.php?showtopic=543627 итп. + для Вашего удобства данные по клиентам:
  4. WPS с пином в любом случае риск. А с перламутровыми пуговицами в виде Easy-2-Use App и PEAPv0/EAP-MSCHAPv2 можно? Домохозяйки и их коты оценят раздельные учетки и вроде как универсальную нативную поддержку со времен XP
  5. Но без поддержки 802.11w можно сделать жизнь невыносимой и на wpa2 .. тут как бы есть еще куда двигаться.
  6. Always-on VPN? Говорят hostapd еще полегче .. можно повесить и на wireless и как standalone .. пользователей из админки ndms скармливать, например, и дело близко к шляпе .. но судя по отзывам есть гемор и лучше сразу в сторону freeradius.
  7. там как раз описан случай с psk без radius .. если ikev2 использует самоподписанный сертификат, то вроде как остается только "удобно" вытащить его, добавить в trusted .. подправить реестр (но я бы не стал) .. т.е. под вопросом только eap-mschapv2 для проверки конструкции .. а для продакшена и удобства юзверей конечно надо бы нормальную выдачу сертификатов сделать (заодно сбудется мечта яблочников с always-on) .. и потом уже радиус прикрутить, чтобы не только для wireless .. нормальный зверек бы вышел.
  8. если у народа заводится ikev2, то по идее мы не далеко от этого: https://doc.pfsense.org/index.php/IKEv2_with_EAP-MSCHAPv2
  9. Таких наглых медвежатников, чтобы щелкали ptk как семечки, а потом еще вставали под фонарь dhcp еще поискать надо .. это юзеры кладут болт на политику безопасности или какой-нибудь клиент скомпрометирован по полной бортовым кейлоггером местного кулхацкера ради какой-то идеи или от нечего делать.
  10. https://forum.keenetic.net/topic/768-eap/ @ndmEDIT: объединили тему - не ново под луной, но попробуем говорят, этот неплохой, есть порт под windows .. а так windows server нативно и другие за деньги.
  11. как пример: http://jsfiddle.net/euka4rm3/ или про выбор: https://ihofmann.wordpress.com/2012/07/31/resizable-table-columns-with-jquery-ui/
  12. Если мы начнем набирать голоса за очевидное, то все, это дно А уже поднимали вопрос, чтобы ширину столбцов самим задавать мышой или тачем и все эти подстройки по visual (включая вид сортировки по столбцам) хранить в куках? У кого печенек нет могли бы наслаждаться текущим дефолтным видом. И не пришлось бы голосовать по каждому подобному вопросу. не так чтобы очень, почти все решаемо
  13. Немного пруфов. Картинко. После успешного TCP ACK в сторону 192.168.2.39 спустя ~3 сек. идет ptp ARP к этому же клиенту, ответ и помчали дальше.
  14. И есть подозрение, что эта часть: - не работает, по крайней мере, на wireless .. это было бы самым простым объяснением.
  15. Ладно, не трогаем сканер Если выключить сканер, то я смогу добраться до нативных механизмов linux, например, с помощью: set net.ipv4.neigh.default.base_reachable_time_ms - поставленного в начале конфига? Как я понимаю, для всех созданных после команды интерфейсов ttl arp-кэша пойдет как: - или есть подводные камни помимо сканера? .. какие-нибудь неучтенные нюансы, которые переписывают правила по ходу пьесы? И еще вопросик: set .. все могу касательно ядра 3.4 в пределах возможностей или что-то специально выпилено? Спасибо.
  16. угу .. потратим еще полгода на достижение, а потом снова начнем укатывать тот же асфальт в том же месте .. вот радость. так-то вроде как новый дизигн ждем, вроде как надеемся, что графики будут отдаваться клиентам через а-ля Chart.js итд итп., возможностей то море, есть из чего выбрать.
  17. нам бы дополнить SNMP поддерживаемыми данными из IEEE802dot11-MIB
  18. Или м.б. как-нибудь так для минимизации гулянья arp: 1) 1 бридж - 1 сканер; 2) на бридже, например: 192.168.1.1/26 (62 хоста - 1 (роутер)) -> 61 хост для сканирования (Ntot); 3) ip hotspot auto-scan interval 0 - включает "новый" механизм (для обратной совместимости); 4) можно установить ip hotspot auto-scan passive 0.1 hps -> скорость: 1 хост в 10 секунд -> общее время сканирования: 61*10=610 сек. или Ntot/hps -> 61/0.1=610 сек. + по совместительству - это интервал (Ttot) получения broadcast arp по кругу одним и тем же потенциальным сканируемым хостом (если нет записи в кэше роутера) или unicast arp (если запись есть) - т.е. сканер заодно и рефрешер; 5) можно установить ttl записей кэша роутера как: Ttot+buf (где buf - время "пограничного ожидания" ролей на случай отсутствия запроса сканера (например, выключился) в течение которого могут использоваться нативные методы валидирования arp; предположим, buf=60 сек.), ожидается, что ttl записи кэша обновляется автоматически нативными механизмами до заданного значения Ttot+buf при получении соответствующего broadcast/unicast от клиентов; 6) продолжая п.4 и учитывая дублирующую систему из п.5 - если по unicast arp ответа нет, то повторная попытка, например, по параметру ip hotspot auto-scan timeout 15 (если запись еще жива в кэше не смотря на п.5) и если ответа нет, то удаляем запись; 7) если предполагается, что все клиенты с привязкой ip к mac от dhcp, то можно заодно привести все под общий знаменатель со стороны клиентов с помощью 35-й опции dhcp как: Ttot+buf... т.е. минимизируем нативную валидацию arp со стороны клиентов. В разных симуляциях вроде бы норм.
  19. Так-то если комплексно .. нужно в т.ч. снизить трафик в сторону клиентов, в т.ч. служебный/управляющий. Т.е. даже если оставить сканер на wireless (если в т.ч. можно было бы подстраивать нужный интерфейс), но на минимуме напряга, скажем: ip hotspot auto-scan interface AccessPoint passive 1 hps (int? т.е. меньше никак видимо) + м.б. таймаут записи кэша в зав-ти от скорости скана и размера подсети (но тут конечно от архитектуры) + ip hotspot auto-scan interface AccessPoint interval 60 unicast (point-to-point ARP - особо погоды не сыграет в этом сценарии, но как вишенка на торте и внимание к деталям, некоторые это оценят) Дальше даже не знаю, если раскопать .. божоле-нуво подойдет? Предположим, все возможно, клиенты топовые, идем исключительно на скорости, физические препятствия минимальны/приемлемы итд., т.е. вполне вероятная ситуация для не особо подготовленного пользователя, но есть педальки (при мощности макс. на TxPower=100). Смотрим на резалт калькулятора при: BasicRate=2048 (54 Mbps онли, да, уменьшит покрытие, но это всегда индивидуально) BeaconPeriod=1024 (вроде макс. по манускрипту, т.е. ~1 маяк/сек) (про крайне вероятную необходимость изменения других связанных параметров не говорю) -> Служебный оверхед минимален (и разница очевидна). Потом уже можно крутить DtimPeriod. Больше особо тут не выжмешь в этом аспекте (вроде бы).
  20. поэтому и "опционально" .. чтобы опцией могли воспользоваться те, кто сознательно готов пожертвовать этой информацией. может, тогда возможность крутить таймаут записей кэша для разных интерфейсов (независимо от рефрешера ip hotspot auto-scan interval {time} и ip hotspot auto-scan timeout {time}) .. и проблему на public.
  21. М.б. все же сделать опционально. Т.к. тогда вопросы к многими антивирусами и IDS. http://serverfault.com/a/409891 (See RFC1122, section 2.3.2.1 - ARP Cache Validation) Плюс, опять же - это нормальное поведение, даже я это вижу с отключенным сканером и никакой ругани: И некоторые комментарии: https://supportforums.cisco.com/discussion/11416946/arp-cache-timeout-cisco-routers https://supportforums.cisco.com/discussion/10901751/router-arp-request-unicast Если предложение выше не пройдет, то, по возможности, чтобы записи статики ip arp (если намертво прибиваются в кэш) не опрашивались сканером в private и не только .. в отношении public бы тоже не хотелось (м.б. опционально, если специально для чего-то еще используется), но там м.б. proxy arp жарит. В общем, если есть ip arp, то в отношении этих записей не делать валидацию кэша. Это нормальная практика, в т.ч. с позиции безопасности (чтобы не отсвечивать лишний раз), чтобы нормальные ids в т.ч. среагировали на появление arp-a, когда его быть не должно.
  22. Если ноги растут со стороны заказчика, то м.б. имеет смысл .. иначе как-то все странно получается.
  23. за всех не стоит
×
×
  • Create New...