CPU

Cisco NBD warranty

Подрядчик на одном объекте поставил Каталист 2960x. Я поехал заливать туда конфиг и обнаружил сгоревший порт. Т.к. оборудование ещё не принял, поручил подрядчику самому заниматься заменой (гарантия Next Business Day Advance Hardware Replacement).
Оказалось:
  1. Три дня (48 часов + разница во времени) уходит на регистрацию железа.
  2. Два дня уходит на общение с TAC.
  3. Один день уходит на открытие RMA.
  4. Шесть дней уходит на доставку железа до Хабаровска.

Итого: 11 дней и требование вернуть железо в течение (!) 10 дней. Интересно, сколько бы времени я потратил, если б занимался сам.
CPU

High CPU for PKID process

Сегодня демонстрировал Косте, вводимый в прод SRX340 - несколько недель уже как трудится в качестве NAT (после карантинов буду пытаться на него L7-фаерволл с MS TMG перетаскивать).
Костя в заббиксе сразу смекнул на высокую загрузку RE-CPU (в полку). Потери пакетов нет, да и пользователи не жалуются. Решил разобраться позднее.
Далее выяснилось, что весь проц съедает процесс pkid. Гугление сходу привело на PR1336733:High CPU usage on pkid process might be seen in IPSec scenario with pki certificates, но у меня нет IPSec (пока), да и JunOS у меня 19.3R2 против 18.4R1 (в котором эту PR уже исправили).
Далее наткнулся на оффорум джуна, где описывают мою проблему и способ решения.

Вкратце, качаем список well-known CA (секьюрненько, ничего не скажешь).
Очищаем локальную группу CA: clear security pki ca-certificate ca-profile-group DEFAULT-CA
Заливаем well-known CA: request security pki ca-certificate ca-profile-group load ca-group-name DEFAULT-CA filename cacert.pem
Где DEFAULT-CA - имя группы, в которой будут хранится well-known серты, а cacert.pem - собственно файл с сертами.

После вышеописанных манипуляций загрузка RE-CPU упала до старых 19%, а я в мониторинг прикрутил триггер (до карантина не успел). Наблюдаем...
CPU

Cisco NAT

Дима недавно сообщил, что постоянно путает на Cisco IOS inside/outside и source/destination при настройке NAT. А мне пришлось это использовать ещё и в VRF. Посему, выложу на память несколько полезных ссылок.
  • THE INSIDE AND OUTSIDE OF NAT - здесь объясняется и показывается разница между inside и outside (вкратце, первый маршрутизируется до NAT, второй - после).
  • "Ip nat inside destination" use case - варианты применения
  • NAT with VRF - IOS vs IOS-XE - NAT между VRF. В первом случае, как я понял, закралась ошибка. В ip nat inside source VRF не надо указывать (точнее, здесь используется GRT).
  • Network Address Translation on a Stick - на десерт, NAT on a stick. Два раза на стенде у меня не заработало. Но ещё не всё потеряно...


И ещё какая-то дичь (не читал ещё).
CPU

Хранение Root CA на FreeBSD

Недавно на Хабрах пробегала новость 2020 LDAP channel binding and LDAP signing requirements for Windows. В связи с чем решил провести инвентаризацию LDAP-client ресурсов. На всяких блейдах (типа HPE c7000) эта проблема решилась установкой корневого CA сертификата. А вот с самописными скриптами пришлось повозиться.

PHPшный LDAP-клиент умеет LDAPS через OpenLDAP, разумеется, но надо было понимать, куда класть Root CA серт. Гугление было долгим (указывать в каждом прикладе конкретное место, где лежит серт - не наш метод), посему и решил написать этот пост.
Серт необходимо класть в /etc/ssl/certs по классической OpenSSL'ной схеме (с хэшами, как полагается).

Adding certificate to ca_root_nss
How to install a private CA certificate on FreeBSD
CPU

Яндекс.Диск

На волне импортозамещения повсюду предлагают пользоваться продуктами Яндекса. Яндекс.Браузер на работе использую с первого дня работы (задолбал, но лень съезжать на Оперу). А вот на днях попросили поставить сабж.

Веб-инсталлер (в лучших традициях Яндекса) через прокси работать не умеет. Говорят, что существует автономный инсталлятор, но официальные ссылки на него где-либо (например, в справке Яндекс.Диска или в самом же поисковике Яндекса) отсутствуют. Ну да ладно, ради одной инсталляции можно временно прописать исключения на фаерволле.

Скачали, поставили. Дальше надо как-то заставить его работать через прокси. На удивление, оно умеет (точнее даже делает попытки уметь) работать через прокси. Умеет, это значит есть задизабленная галочка "использовать автоматические настройки", есть поле ввода сервера, порта и (!) даже поля ввода логина с паролем. Прописываем, перезагружаемся...

И тут Яндекс.Диск упорно отказывается аутентифицироваться. Причём, отключить использование прокси больше нельзя. Только после аутентификации, которая, разумеется не работает.

Ну что ж. Берём наш любимый вайршарк и обнаруживаем, что оно коннектится на прокси, но после ответа HTTP/407 тупо падает. Грубо говоря, вообще не умеет аутентификацию прокси. В дальнейшем оказалось, что оно не умеет аутентификацию прокси вообще на любые адреса.

В общем, пришлось на проксике пропустить Яндекс.Диск без аутентификации вообще. Адреса ресурсов для необременительного использования прилагаю:Collapse )

P.S. Понимаю, что использовать прокси в 2019ом году уже немодно. Однако, с Juniper SRX пока небольшой затык.
CPU

Microsoft DHCP server: is network hardcoded?

Иногда бывает. Внедряешь новый Hyper-V кластер, всё идёт прекрасно. Пока... Пока не сталкиваешься с проблемой - коллега говорит: - "А что-то у меня в новом вилане по DHCP адреса не получаются. При этом статика работает прекрасно".
Запускаю старые машины в старом кластере в этом вилане - всё работает. Перетаскиваю старые машины в новый кластер - всё работает. Создаю новую машину - ничего не работает. При этом, сетевой стек наглухо виснет, помогает только перезагрузка машина.
Изучаю сеть, ничего найти не могу.
Создаю новую машину не на Windows Server 2019 (Windows 10), а на Windows 8.1 - всё работает.
Беру полноценный комп с Windows 10, тыкаюсь в этот же вилан - сетевой стек виснет. В других виланах всё прекрасно работает. А-ха, проблема где-то в Win10.
Сравниваю настройки DHCP в разных виланах: на первый взгляд - всё одинаково.
Собираю тестовый стенд, всё замечательно работает. Начинаю снимать дампы.
На первый взгляд, дампы одинаковы. С горя сношу настройки проблемного вилана в DHCP - и, о чудо, всё заработало!
Полез опять сравнивать дампы - и вот она, рыба моей мечты...
Когда-то давно мы с __mixa__ запускали на сети опцию 119 (Domain search list). Эта опция отличается довольно кривой реализацией в продуктах от MS - Windows 7 её не поддерживает от слова совсем. Забить её правильно в консоли DCHP-сервера надо ещё постараться. Но нам она была нужна для никсовых серверов, где она прекрасно выполняла свою роль (в винде мы политиками обошлись).
Оказывается, что в Win10 (и производных - Windows Server 2019 и т.п.) таки реализовали поддержку (или не поддержку, а обработку) и на кривой опции 119 тупо крэшится сетевой стек. А кривость заключалась в ошибочном указании (!) одного байта при переносе опции с одного вилана в другой. В общем, Wireshark + WinHex = наше всё!

P.S. Включение Microsoft DHCP-сервера (отключение авторизации):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters

Name: DisableRogueDetection
Type: REG_DWORD
Data: 0x1
CPU

Запрет доступа к машине по сети локальному администратору через GPO

Понадобилось сделать сабж. NT AUTHORITY\Local account and member of Administrators group мне не подходит, т.к. некоторым локальным админам доступ по сети всё же нужен.
Придумалось два костыля:
1) Добавлять локального администратора скриптом через LGPO в локальные политики.
2) Прописать SeDenyNetworkLogonRight = Administrator,Администратор руками в файл GPO. Однако, раньше у нас так и было (только применительно ко второму пользователю). Через редактор GPO этот финт не работает.
Остановился на втором варианте, понаблюдаем.
CPU

Гипервизоров псто

Небольшой дисклаймер: ниже речь скорее об инфраструктуре, нежели о собственно гипервизоре (но так удобней).

Гипервизор нормального человека:
HTML5-клиент для VMware vSphere выходит этой осенью.

Гипервизор курильщика:
Пришло новое лезвие в блейд. Решили туда воткнуть Windows Server 2016. Ан нет, в MS SC VMM 2012 R2 нельзя включить гипервизор на базе WinServer2k16. Казалось, бы - апгрейдся до VMM 1807 и делов то... Ан нет. Апгрейд до 1807 возможен только с 1801. Но 1801 работает только на MSSQL 2016, а у нас MSSQL 2012, а для 1807 вообще нужен MSSQL 2017.
CPU

Cisco ISR as L2TP/IPSec client

Понадобилось подключиться к сетке одного важного контрагента с помощью Cisco 3845. У контрагента есть только L2TP/IPSec на ZyXEL USG 60.
Попробовал настроить L2TP через VPDN (interface Dialer), по аналогии с PPTP - не взлетело, вторая фаза ISAKMP не проходит (логи ниже). Попробовал настроить L2TP через pseudowire (interface Virtual-PPP) - заработало.

Collapse )
CPU

Microsoft wired keyboard 200

Купили некоторое время назад несколько десятков сабжевых клав (по ТЗ, ну 223-ФЗ все дела).
И начались с ними непонятки: юзвери стали жаловаться, что некоторые клавиши "не нажимаются", и обнаружили, что на некоторых машинах Num Lock мигает. Две клавы сдали по гарантии (их обещались поменять на новые), полдюжины выкинули на помойку.
И тут сегодня задумались... Это ж Microsoft, как так? Полезли искать отзывы, почему Microsoft такой шлак делает, ларчик же открывался просто: это поведение встроенного режима энергосбережения в Win8.1 и выше.

Отключается так:
-> Устройства и принтеры
-> USB Keyboard
-> Щелчок правой кнопкой мыши
-> Свойства
-> Вкладка "Оборудование"
-> Выделить пункт "USB-устройство ввода"
-> Правый нижний угол нажать "Свойства"
-> На первой же вкладке "Общие" внизу "Изменить параметры"
-> Вкладка "Управление электропитанием"
-> Снять верхнюю галочку ("Разрешить отключение этого устройства для экономии энергии") и применить

Microsoft keyboard Turns Off By itself