Jump to content

IgaX

Forum Members
  • Posts

    950
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by IgaX

  1. Если проца будет хватать при наполнении до краев, то почему бы и нет, но .. "экономика должна быть экономной" (с) Все же хотел бы немного уточнить, а то иногда бывает путаница с HW MTU в плане включения L2 Header. Всем известен IP MTU (равный Ethernet MTU) в 1500. Сам же кадр = IP_MTU(1500) + L2_Header(12+2) + FCS(4) + Vlan_Tag_если_задан(на каждый по 4). Если я правильно понял, в наших стандартных конфигурациях кадры от роутера маркируются если задан vlan на соответствующем интерфейсе (отличный от vlan 1, который native для 802.1q), соответственно, в провод обычно (если не vlan1) попадает кадр 1500+14+4+4=1522 .. а там еще и preamble если глубже копать. Наш провод на GbE (м.б. не весь) поддерживает, как я понял, в т.ч. Experimental Ethernet, для которого IP MTU согласно RFC 895 - 1536. Таким образом, провод может, в теории, у нас переварить кадр, например, 1536+22=1558 .. а там еще вроде обещали Jumbo для G3 и LTE .. поэтому фз .. если на проводном меж-линке роутеров доступен Jumbo - точно нужен eoip_allow_fragment ? Как бы там ни было. По идее 1536 для IP datagram в Exp.Eth. Если берем стандартный IP MTU в 1500 для всех клиентов, то к бриджу, например, по проводу приходит тэгированный кадр размером 1522 (для воздуха вроде тоже можно vlan, но ждем настроек) .. попадая в бридж FCS и Vlan_Tag убираются, т.е. остается 1514. Далее для EoIP заворачиваем это в "GRE"(8) + добавляем IP_Header(20) .. итого IP datagram = 1514+8+20 = 1542. Если Jumbo нет, то в max. 1536 для IP datagram в Exp.Eth не влезаем. Формально, чтобы не напрягать без надобности проц - стараемся избегать IP-фрагментации, поэтому, как вариант, - на бриджах выставлять IP MTU с учетом дельты 1542-1536=6 (разница в 1500 и 1494 не очень существенна, поэтому для удобства и минимального напряга для всех передаем IP MTU в 1494 в т.ч. через 26-ю опцию DHCP) .. т.е. примерно так: - на К1 ip dhcp pool _WEBADMIN option 26 1494 ip dhcp pool _WEBADMIN_GUEST_AP option 26 1494 # не забываем про бриджи, в т.ч. на К2: interface Home ip mtu 1494 interface Guest ip mtu 1494 .. или вместо этого, если железо свитча роутера поддерживает Jumbo(?), то м.б. на меж-линке поднимем IP MTU до 1542: - на К1 и К2 interface 1 ip mtu 1542 Если ничего выше никак, то да, взводим: - на К1 и К2 system set net.core.eoip_allow_fragment 1 Поэтому, наверное, будут полезны всем желающим ответы на вопросы (если не затруднит): все правильно или где-то накосячил? что из этого возможно? какие модели К* поддерживают в т.ч. Experimental Ethernet, а какие Jumbo? Исходя из цели добиться максимального перформанса через минимальный напряг проца на потенциальные операции фрагментации EoIP-трафика.
  2. Подумал на тему - как бы я это сделал. Цель: обеспечить прозрачное бриджевание, чтобы в т.ч. на соответствующий прозрачный бридж можно было повесть всякие вкусности по настройке дров радио в части 802.11k и 802.11r, привязать тот же hostapd с любым выходом на EAP .. ну и потом уже просить пакетики из буфера пытаться перекидывать в нужную очередь, если дрова не умеют .. а то мало ли, вдруг, как-то умеют. Вопрос по радиопланированию ячеек итп. настройкам не рассматриваю. Значит, например, есть 2 гордые коробки (далее по тексту К1 и К2) с в т.ч. гостевым сегментом. Будем все делать прозрачным мостом через EoIP. EoIP пойдет по проводу отдельным физ.линком а-ля вторым wan, чтобы меньше думать, т.к. настройки "ленивые" для режимов ИЦ. Если что-то пропустил - прошу добавить, м.б. будет полезно для желающих подобной схемы. 1) Выделим, например, 1-й желтенький порт под физ.линк, соединим шнурком и далее из серии: - на К1 interface GigabitEthernet0/0 rename 1 switchport mode access switchport access vlan 101 up ! # Поставим public, чтобы не думать + сетку на 2 хоста ptp interface GigabitEthernet0/Vlan101 description "Wired DS Link" security-level public ip address 172.16.0.1/30 up ! # Если, вдруг, нет маршрута для 172.16.0.0/30, то для поинта ip route 172.16.0.2 GigabitEthernet0/Vlan101 - на К2 interface GigabitEthernet0/0 rename 1 switchport mode access switchport access vlan 101 up ! # Поставим public, чтобы не думать + второй поинт interface GigabitEthernet0/Vlan101 description "Wired DS Link" security-level public ip address 172.16.0.2/30 up ! # Если, вдруг, нет маршрута для 172.16.0.0/30, то для зеркального поинта ip route 172.16.0.1 GigabitEthernet0/Vlan101 -> по идее, имеем рабочий линк а-ля второй wan, с мини-зонтиком. 2) Поднимем тоннельчеги для "Home" и "Guest": - на К1 # Для Home interface EoIP0 tunnel destination 172.16.0.2 tunnel eoip id 1 up ! # Для Guest interface EoIP1 tunnel destination 172.16.0.2 tunnel eoip id 2 up ! - на К2 # Для Home interface EoIP0 tunnel destination 172.16.0.1 tunnel eoip id 1 up ! # Для Guest interface EoIP1 tunnel destination 172.16.0.1 tunnel eoip id 2 up ! -> security-level итп. не указываем, т.к. включим в мосты и навесим. 3) Наведем красоту, предположим, К1 у нас мастер-шлюз с выходом в мир: - на К1 interface Bridge0 rename Home description "Home WDS" inherit GigabitEthernet0/Vlan1 include AccessPoint include AccessPoint_5G include EoIP0 security-level private ip address 192.168.1.1/24 up ! interface Bridge1 rename Guest description "Guest WDS" inherit GigabitEthernet0/Vlan3 include GuestWiFi include EoIP1 security-level protected ip address 10.1.30.1/24 up ! # на К1 ставим DHCP обслуживающий весь прозрачный бридж ip dhcp pool _WEBADMIN range 192.168.1.3 192.168.1.254 default-router 192.168.1.1 dns-server 8.8.8.8 8.8.4.4 lease 25200 bind Home enable ! ip dhcp pool _WEBADMIN_GUEST_AP range 10.1.30.3 10.1.30.254 default-router 10.1.30.1 dns-server 8.8.8.8 8.8.4.4 lease 25200 bind Guest enable ! - на К2 interface Bridge0 rename Home description "Home WDS" inherit GigabitEthernet0/Vlan1 include AccessPoint include AccessPoint_5G include EoIP0 security-level private ip address 192.168.1.2/24 up ! interface Bridge1 rename Guest description "Guest WDS" inherit GigabitEthernet0/Vlan3 include GuestWiFi include EoIP1 security-level protected ip address 10.1.30.2/24 up ! # можно, конечно, нарезать на случай войны, но лучше учет в одном месте ip dhcp pool _WEBADMIN no enable ! ip dhcp pool _WEBADMIN_GUEST_AP no enable ! # помогаем самому К2 видеть мир ip route default 192.168.1.1 Bridge0 ip name-server 8.8.8.8 "" on Bridge0 ip name-server 8.8.4.4 "" on Bridge0 .. м.б. что-то забыл, но вроде ничего из важного .. м.б. для пользования а-ля DynDNS на К2, возможно, придется на Bridge0 еще ip global повесить .. если с MAC-ами на EoIP все норм(?), то вроде как все гуд .. сохраняемся .. ребутаем при необходимости, для проверки чтобы заработало само собой. .. предположим, это 2xG3 с AC1200 на GbE + беспровод вылизан и с учетом средней 65% MAC-эффективности 802.11 потенциально нагружает с обоих диапазонов на средние 780Mbps (1200*0.65) на каждом поинте + проводные (потенциально) saturate до полной картины -> вопрос: проц справится с программным EoIP или не выйдет упереться в проводное ограничение с учетом оверхеда? ppe поможет? или как лучше? .. и мяч на стороне разработчиков, "воздух" выходит в штрафную и .. =)
  3. Из теории: 1) Глава 11 + Приложение C https://drive.google.com/open?id=0BwkqH1x6vsOFWW5lR3dyN04tWFU 2) Немного тут https://technet.microsoft.com/en-us/library/cc727740(v=ws.10).aspx 3) Полезный дамп с примером вечных выборов https://wiki.wireshark.org/SampleCaptures#Browser_Elections 4) RFC 1001, 1002 https://tools.ietf.org/pdf/rfc1001.pdf https://tools.ietf.org/pdf/rfc1002.pdf 5) Крохи, не вижу оригинала: https://www.wireshark.org/docs/dfref/b/browser.html В общем, как я понял, основной посыл пользователя: включить, например, мелкомягкого клиента и увидеть почти сразу роутер с шарой в сетевом окружении или чтобы сетевой диск без проблем привязывался по NetBIOS-имени. Пожелание Master Browser из серии выделенного WINS (чтобы ни о чем не думать), что разумно для малых сетей, т.к. роутер всегда работает .. но если сложно, то тот же OPKG/Samba или ручками в реестре все роли и твики, имхо, лучше на FSR/FT/Radius бросить силы. Т.е. есть нюанс с резолвингом, м.б. роутер не откликается на броадкаст-запрос NBNS - NetBIOS Name Query Request после инициализации того же мелкомягкого клиента из-за процесса выборов. М.б. желательно дополнительно сделать так, чтобы роутер откликался (если еще нет) в т.ч. по LLMNR для систем Linux(?) и выше Vista. Что еще тут можно придумать .. м.б. по DHCP дополнительно пытаться ставить (на всякий случай), например, 46-й опцией: b-node (вроде когда-то были репорты, что может глючить в зависимости от комбинаций). DNS без правки реестра вроде норм по резолвингу для выше W2000, но как быть с теми, кто указывает другие DNS на клиенте .. если только перехватом. Какие еще мысли .. nbtstat -A по роутеру показывает: Таблица NetBIOS-имен удаленных компьютеров Имя Тип Состояние ---------------------------------------------------- KEENETIC-GIGA <00> Уникальный Зарегистрирован WORKGROUP <00> Группа Зарегистрирован KEENETIC-GIGA <20> Уникальный Зарегистрирован Адрес платы (MAC) = 00-00-00-00-00-00 Дамп по 138-му на Host Announcement KEENETIC-GIGA, Server, Print Queue Server, NT Server .. нет упоминаний по * Workstation не смотря на KEENETIC-GIGA <00>, т.е. роль в данном случае redirector формально не анонсируется, м.б. в этом тоже есть затык. + формально на клиенте-мастере: WORKGROUP <1D> Уникальный .. и это логично для мастера, но в его сторону все равно идет броадкаст и в других дампах тоже, так что непонятно что с RFC 1001 п.17.2 .. м.б. вообще попробовать в сторону Destination name '*' согласно тому же п.17.2 .. т.к. м.б. пока идут выборы и, возможно, нет: WORKGROUP <1D> Уникальный .. то анонс роутера м.б. никто не принимает и визуально этим вызывается задержка появления роутера (cifs) в сетевом окружении .. как бы один фиг де-факто броадкаст, попробовать бы другой Destination name. В общем .. это гемор, учитывая что M$ сами признают, что NBT особо никто не занимается и м.б. даже поломан, то трушной схемы на том же W10 уже может не быть, поэтому предлагаю проверить тему с LLMNR, mDNS для яблочников, м.б. перехват DNS для имени роутера (но чтобы гибко можно было бы вкл/выкл .. м.б. на уровне компонентов .. и самбу для мастера заодно раз ovpn можно).
  4. чтобы была польза в проводнике - для DNS придется вроде реестр править на клиентах - EnableDns. в принципе, понимаю почему не хочется делать Master Browser без готового кода .. я бы тоже не стал учитывая: это, это и это, а отправил бы делать мастеры и бэкапы на мелкомягких клиентах самостоятельно + м.б. уменьшил временной интервал при необходимости. *** так-то по памяти вроде было неудобство, что роутер (cifs) мог в сетевом окружении появиться не сразу + вроде бы не с первого раза откликался по имени в проводнике .. второе "вылечилось" вроде бы закрепленным ярлыком по ip, в том плане, что имя сервера стало разрешаться уже без прямого ip (т.е. NB отработал и запись ушла в кэш nbtstat -c), т.е. после коннекта со стороны клиента .. и то, что появляется не сразу наводит на мысль, что nbdgm с Host Announcement рассылаемый роутером раз в 30 сек. (а точно не будет конфликта? - а то там речь про 1-12 мин. выше) - не воспринимается .. nbss вроде норм каждые 30 сек. между клиентом и сервером в части smb (p.s. прошивка старая) .. первое впечатление, что не слышат друг-друга в разных частях древней логики (и фз кто "сломался"), но если пнуть другим механизмом, то заводится. специально в болото не полезу, напишу если увижу неувязку с позиции протокола в ближайшее время.
  5. Насколько я понял, для малых сетей формально стараются уйти в сторону LLMNR итп. из Zeroconf .. учитывая что мультикаст в UPnP недавно поправили, то похоже актуальность с Master Browser на коробке стала (в теории) меньше.
  6. Подробно не разбирал проблему в целом с выборами Master Browser, но подозреваю, что как обычно все было в настройках а-ля: preferred master = yes os level = 4 И, м.б., косяки с конфликтами от Winbind. В результате выборы, видимо, никогда не заканчивались. А так вот с примерами в т.ч. по выборам и разными моментами для проверки (как гайд для валидации выбора Master Browser на Linux). Не так чтобы свет клином сошелся на NBNS/NBT-NS учитывая весь набор, косяки могут быть и в других составляющих при траблшутинге .. все же, имхо, чаще всего это кривые фаеры и их инициаторы.
  7. Там мухи и котлеты в плане NetBIOS. Смотря как отключать. Если убирать фичу, то на некоторых системах заодно вырубается Browser как часть логики (крайний абзац): Поэтому рекомендуется на клиентах через тот же: To disable SMBv1 on the SMB client, run the following commands: sc.exe config lanmanworkstation depend= bowser/mrxsmb20/nsi sc.exe config mrxsmb10 start= disabled .. тут все для массовки.
  8. Можно было бы, как и задумано, по TTL из ответов того же https://developers.google.com/speed/public-dns/docs/dns-over-https#dns_response_in_json Но блочить по ip, имхо, плохо, "совсем дибилы" не вкусят цимеса. А матчить http.host или sni в tls хш и блочить aka - это вполне бы, уже привычно пользователю.
  9. скорее всего, дела обстоят так: управления роумингом для отстрела disassoc по rssi, чтобы клиент переподключался к bssid с лучшим сигналом при достижении определенного порога rssi на покидаемой bssid пусть в рамках essid - нет - если только на клиенте можно настроить, если нет, то линк будет сначала деградировать пока не отвалится и не переподключится к тому, чей маяк первым услышит. чтобы было незаметно нужно в т.ч. снимать кадры с буфера покидаемой AP и перекидывать их в очередь AP куда клиент пришел по роумингу - это если не думать про небольшой перерыв при хэндшейке на роуминге .. или про возможно заметный перерыв если ключи на базе а-ля радиус. чтобы совсем минимизировать время хэндшейка нужно, чтобы клиент заранее по-возможности получал уже готовые ключи от PMK по совпадению в своем кэше (чтобы сократить время согласования). как бы настройки есть в т.ч.: PreAuth PMKCachePeriod EAPifname PreAuthifname итп. для аутентификатора осталось загадать базовую реализацию FSR и чтобы Band Steering потенциально не мешал (а лучше самим его тоже настраивать через настройки, которые для этого есть в т.ч. на уровне дров) .. и чтобы народ не зря голосовал за воздух =)
  10. если в cli ограничения на ip traffic-shape host, то я бы поставил пачку на тараканов в сторону установки vlan id тогда уже непосредственно на клиентах через диспетчер устройств на сетевых или тэгированием виртуальными а-ля hyper-v с разборкой по бриджам (сколько их макс.?), шейпированием на них же, м.б. еще ip hotspot policy, а там по вкусу .. исходя из возможностей каждого клиента уже бы подумал как лучше все сегментировать/сгруппировать.
  11. да как угодно. https://support.microsoft.com/en-us/help/816042/how-to-configure-an-authoritative-time-server-in-windows-server e.g. "When you run the easy fix solution to configure an external time source you will need to specify the name of your NTP server" или присмотреться к окопу: https://support.microsoft.com/ru-ru/help/223184/registry-entries-for-the-w32time-service или просто сразу все расскажут: http://windowsnotes.ru/windows-server-2008/nastrojka-ntp-servera-v-windows/ или когда этого уже мало: http://www.timetoolsglobal.com/2013/06/21/how-to-synchronize-microsoft-windows-to-a-ntp-server-1/ https://technet.microsoft.com/ru-ru/library/Cc773263(v=WS.10).aspx#w2k3tr_times_tools_uhlp https://social.technet.microsoft.com/Forums/windowsserver/en-US/c6b3754d-d3e6-41bd-ac8e-3372a1afef04/ntpserver-registry-key?forum=winserverDS
  12. есть пара моментов после которых все понятно: 1) каждый раз при проходе "шлюза" (хоста) на L3 (т.е. когда на уровне IP происходит т.н. "routing decision") - обычно TTL уменьшается на 1 .. это сделано для того, чтобы пакеты, "которые никто не хочет", не бегали вечно в потенциальной петле, а помирали - если не могли бы добраться до места назначения за N "прыжков"/"хопов" (TTL в данном случае) .. это важно понимать, принимая во внимание: является ли Ваш модем одновременно и роутером или просто пашет как клиент; 2) какой TTL хочет видеть Ваш провайдер .. вот к этому значению прибавляем кол-во L3(!)-роутеров по пути где на каждом потенциально TTL уменьшается на 1 (обычно при этом происходит изменение подсети - чтобы на глаз примерно сразу .. т.е. много "роутеров" в одной плоской подсети еще ничего не говорит), чтобы на выходе в трубу провайдера был TTL, который он хочет видеть .. и ищем нужную настройку .. если сеть не видно, то можно просто попинговать путь - уменьшение TTL будет видно (или не будет - когда не уменьшается) .. ну там .. попинговали свой роутер, попинговали модем особенно если он ~ 192.168.8.1, попинговали шлюз провайдера (если пинги не режутся) .. все где уменьшается TTL станет понятно .. оборудование провайдера в режиме "моста"/"роутера" - все в т.ч. из этой оперы. 3) есть определенные вида трафика, где TTL=1, т.е. предполагается, что этот трафик не должен покидать пределы роутера, а дискардиться, но по факту это для L3 - а на L2 такой трафик можно толкать сколько хочешь (поэтому чаще всего и заморачиваются с L2) .. ну и есть редкие кейсы, когда тебя в мост не пускают, а сразу на форвард .. и вот там TTL=1 может и сгореть, если попасть на "routing decision". 4) в т.ч. есть хитропопые, которые манипулируют TTL, чтобы маскировать узлы и их функцию. итд.итп.
  13. Не, речь как раз о том, что было бы в кассу: port-share И если честно, то после WoSign и StartCom читать не стал.
  14. они все-равно палятся, когда не по форме отвечают: https://www.sslchecker.com/sslchecker
  15. Это смена пользователя. Если бы digest кэшировался, то по кнопке Назад можно было бы вернуться. Тот же запрос к /ci не кэшируется, поэтому такой подход и работает.
  16. Нет тут никакой фишки. На устройство завернули, предъявили фейковый сертификат, клиент слопал, после чего устройство прямо совершает невозможное и открывает туннель в сторону настоящей цели и пропускает через себя все. В том же браузере виден сертификат конца туннеля - не надо думать, что устройство никто не заметит, если имитировать этот конец. Фишка будет, когда пров скажет, что для доступа к интернету установите наш удостоверяющий центр в целях борьбы .. не знаю .. чего там жить мешает .. с лестницами, риск падения с которых почти в 3 раза превышает риск нападения с применением огнестрельного оружия. Угу, уже давно .. а там м.б. и заодно удобный L7-роутинг .. и все остальное за что голосовали =)
  17. Вроде при --key-method 2 используется TLS PRF function, так что формально туннель используется. Имхо, что важно: 1) Сбивают, видимо, в основном на ClientHello, где plain text и SNI, да и вообще надо смотреть все оптимизации и extensions; 2) Если очень захотеть, то можно заодно подвязать к ALPN extension (если его используют); 3) В теории, можно дополнительно верифицировать по сертификату в ServerHello, а то, вдруг, не та бездна; 4) Если dpi с mitm, то совсем незаметно выйдет только если "втюхать" в "trusted"-хранилище клиента левый сертификат или CA его удостоверивший .. просто для корпоративного пространства это норма, но частный доступ - святая корова; 5) Если при этом "борзеть" притворством с trusted chain, то специально обученный проект это выяснит и вся планета скажет "фи"; 6) Чтобы дешифровать сессию без очень значительных вычислительных мощностей нужно либо снимать сессионные ключи с того же клиента, либо иметь доступ к приватным ключам (а некоторым службам, по идее, не отказывают), но и там палки в колеса может ставить dhe/ecdhe; 7) Часто сервисы/службы имеют определенный footprint, зная его и имея доступ к определенным исходникам, в теории, можно стоять незаметно под фонарем открытых портов даже для продвинутых зондеркоманд. Так что .. на мой взгляд, - не те джунгли, где dpi может быть комфортно.
  18. проксирование самим openvpn. я ж говорю, tls1.2, дерзайте с dpi, остальные уже некошерные вроде .. как разгрызут как раз неубиваемый 1.3 подойдет .. как этот разгрызут, надеюсь, уже Марс или Луну начнем колонизировать и на эту хрень кому чего запрещать времени уже не будет =) ну вот где там в tls-хендшейке есть возможность привязаться к разграничению на уровне application? .. к тому моменту cipher suite уже взлетает и усеее .. хава нагила =)
  19. =) как серфинг и voip .. но педалируя до tcp congestion с паттерном уже будет проблематично
  20. Да, по идее, для любого браузера сделать закладку, где в качестве ссылки указать а-ля: javascript:(function(c){var a,b="Пятачок покинул здание.";try{a=document.execCommand("ClearAuthenticationCache")}catch(d){}a||((a=window.XMLHttpRequest?new window.XMLHttpRequest:window.ActiveXObject?new ActiveXObject("Microsoft.XMLHTTP"):void 0)?(a.open("HEAD",c||location.href,!0,"logout",(new Date).getTime().toString()),a.send(""),a=1):a=void 0);a||(b="Your browser is too old or too weird to support log out functionality. Close all windows and restart the browser.");alert(b)})(/*pass safeLocation here if you need*/); .. и для выхода из админки просто по этой закладке тапать/кликать (находясь на вкладке с админкой) .. проверил, работает вроде.
  21. А как же "больше хаков вкусных и разных"? Уже ведь было. Совершил "чудо" минутным копипастом в лоб некрасиво на href (кнопку не перекрашивал, просто продублировал "Приложения"): Кликнул по "дублю", получил ожидаемо: Закрыл, попробовал перейти на вкладку #security.acl: В логе ожидаемо: (conn: *4895338) user "logout" was not found in config, client: 78.47.125.180 Зарезервировать logout в системе и подавить для него ошибку в логе, наверное, не будет сложно. Для IE и этого не потребуется. Кнопку можно показывать в тех браузерах, где точно работает (интересно, где не сможет). В общих случаях пользователям будет достаточно.
  22. даже ведущие антивирусы нифига не детектяд в запаролированных архивах .. и вот, например, ovpn мимикровал на, например, 8531-й и .. эм .. скажем, превратился в "wsus over https", tls1.2 пройден, rsa под 2048, dhe под 2048 или ecdhe под 256, csr и crt шли с sha-2 .. и какие действия? и вот dpi прямо вот сразу по зубам от TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 или TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 .. а есть и выше, но перформанс .. имхо dpi даже не узнает, что там внутри нет http .. или, может, в следующей жизни =) но если по-чесноку - правоверные даже не посмотрят на 8531-й, пока не покажут, а их там вагон, где встать можно.
×
×
  • Create New...