среда, 6 декабря 2017 г.

Сертификаты подписанные центром в домене .local

Браузер chrome не желает признавать доверенными сертификаты, выданные узлам с адресами <какой то хост>.local

Причина давняя почитать про это можно тут:
https://blog.comodo.com/e-commerce/phase-ssl-certs-internal-names-reserved-ip/
https://casecurity.org/2014/07/18/what-to-do-when-you-rely-on-internal-names-in-tlsssl-certificates/
https://productforums.google.com/forum/#!topic/chrome/zVo3M8CgKzQ;context-place=topicsearchin/chrome/category

Мы рассмотрим ситуацию, когда у вас в инфраструктуре есть корпоративный центр сертификации (Enterprise CA). Обсуждение самой инфраструктуры PKI выходит за замки данного поста, напишу как нибудь в следующий раз.

Сертификат должен быть с расширением SAN (subject alternative name) и подчиненные ему поля должны содержать как минимум FQDN узла, но для удобства можно добавить и IP адрес.

Нам необходимо создать запрос к центру сертификации, на выпуск нам сертификата, с этим расширением.
Будем использовать утилиту openssl на CentOS.
Для начала включим расширения:

nano /etc/pki/tls/openssl.cnf

Ищем закоментированную строку

#req_extensions = v3_req # The extensions to add to a certificate request

убираем #

req_extensions = v3_req # The extensions to add to a certificate request

Теперь создаем файл cert.in, с таким содержимым:

[ req ]
default_bits = 2048
prompt = no
encrypt_key = no
default_md = sha256
distinguished_name = dn
req_extensions = req_ext

[ dn ]
CN = srv-example.mydomain.local
O = CoolCompany
OU = Default
L = Saint-Petersburg
ST = NA
C = RU

[ req_ext ]
subjectAltName = DNS: srv-example.mydomain.local,IP:192.168.0.100

Создаем запрос и за одно сохраняем закрытый ключ:

openssl req -new -config cert.in -keyout cert.key -out cert.crs

По запросу cert.crs наш центр сертификации выпускает для нас сертификат.
Мы его должны сохранить в формате Base 64 в файл cert.cert

Теперь мы можем экспортировать сертификат с закрытым ключом в формате PKCS12:

openssl pkcs12 -inkey cert.key -in cert.cert -export -out cert.cert.pfx

Вводим пароль и файл готов.



пятница, 27 октября 2017 г.

vWLC и старые точки

Возникла небольшая проблема с vWLC 8.0. Не регистрируются точки.
Все манипуляции с разрешением просроченных сертификатов не помогают.
В логах видим вот такой набор сообщений:

*spamApTask0: Oct 27 12:45:30.613: %DTLS-3-HANDSHAKE_FAILURE: openssl_dtls.c:841 Failed to complete DTLS handshake with peer xx.xx.xx.xx

*spamApTask0: Oct 27 12:43:20.515: %LOG-3-Q_IND: spam_lrad.c:1695 Ignoring discovery request received on a wrong VLAN (48) on interface (1) in L3 LWAPP mode from AP xx:xx:xx:xx:xx:xx

*spamApTask0: Oct 27 12:43:10.502: %LWAPP-3-DISC_INTF_ERR2: spam_lrad.c:1695 Ignoring discovery request received on a wrong VLAN (48) on interface (1) in L3 LWAPP mode from AP xx:xx:xx:xx:xx:xx

Нам понадобится обновить ПО на точке.
Для этого прописываем на ПК IP адрес 10.0.0.2 маска 255.0.0.0 шлюз не нужен как и DNS.
Запускаем TFTP сервер

Кладем на него файл: c1250-rcvk9w8-tar.153-3.JA12.tar но его надо переименовать в: c1250-k9w7-tar.default

Затем выключаем питание точке, зажимаем кнопку и включаем. Так ждем секунд 30 потом отпускаем.
Если подключена консоль то проще - там видим сообщение что ожидаем отпускания кнопки.
Точка должна забрать файл, и перезагрузится.

После этого она должна найти контроллер и зарегистрироваться.

Теперь про 2 важных момента установки vWLC на ESXi.
1. Нужно создать виртуальный коммутатор, у которого никуда не подключен порт. И на нем сделать порт-группу к которой подключить Service порт vWLC (это первый порт VM)
2. На порт группе которая будет служить для WiFi доступа нужно разрешить Promiscous mode.

вторник, 3 октября 2017 г.

RSPAN зеркалирование трафика с порта коммутатора, на виртуальную машину для анализа

В целом RSPAN прекрасно работает и с VMWare коммутатором.
Пример настройки.
1. На VMWare коммутаторе создаем VLAN, включаем Promiscuous mode - Accept
в нашем примере VLAN ID 77



2. На виртуальной машине с анализатором трафика, в нашем примере Wireshark, добавляем адаптер подключенный к этому VLAN (никаких настроек IP можно не делать).
Так же требуется включить Promiscuous режим на сетевом адаптере - но Wireshark сделает это за нас.

3. На коммутаторе нам понадобится указать порт с которого будем пересылать трафик:

monitor session 1 source interface Gi0/6

VLAN через который мы будем доставлять этот трафик, сначала создадим VLAN:

vlan 77
 remote-span

и укажем его как VLAN для доставки трафика, снятого с нашего порта:

monitor session 1 destination remote vlan 77

Можно проверить настройки:

Switch#sh monitor
Session 1
---------
Type                   : Remote Source Session
Source Ports           :
    Both               : Gi0/6
Dest RSPAN VLAN        : 77


Switch#sh monitor detail
Session 1
---------
Type                   : Remote Source Session
Description            : -
Source Ports           :
    RX Only            : None
    TX Only            : None
    Both               : Gi0/6
Source VLANs           :
    RX Only            : None
    TX Only            : None
    Both               : None
Source RSPAN VLAN      : None
Destination Ports      : None
Filter VLANs           : None
Dest RSPAN VLAN        : 77

Теперь убедимся, запускаем ping на машине подключенной к порту Gig0/6




вторник, 30 мая 2017 г.

Avaya Session Manager Cisco Call Manager Express связываем по SIP

На CME у нас два dial-peer (входящий и исходящий)

dial-peer voice 10 voip
 destination-pattern 2..
 session protocol sipv2
 session target dns:avaya-sip.sample.local <-- Важно! должно совпадать с SIP доменом на SM
 session transport tcp <-- Можно и UDP но проблем больше будет
 voice-class codec 1
!
dial-peer voice 11 voip
 session protocol sipv2
 session transport tcp
 incoming called-number 6..
 voice-class codec 1

Описывать всякие destination-pattern не буду, кому надо тот найдет документацию.

Далее на Avaya:











вторник, 18 апреля 2017 г.

Cisco ASAv на vMWare vSphere 6.5

Собственно ни как не задеплоить просто так.
Только из ovftool
ovftool.exe -ds=<Имя хранилища> -n=<Имя виртуальной машины> --deploymentOption=ASAv30 --net:"Management0-0"="<Сеть >" --net:"GigabitEthernet0-0"="<Сеть >" --net:"GigabitEthernet0-1"="<Сеть >" --net:"GigabitEthernet0-2"="<Сеть >" --net:"GigabitEthernet0-3"="<Сеть >" --net:"GigabitEthernet0-4"="<Сеть >" --net:"GigabitEthernet0-5"="<Сеть >" --net:"GigabitEthernet0-6"="<Сеть >" --net:"GigabitEthernet0-7"="<Сеть >" --net:"GigabitEthernet0-8"="<Сеть >" c:\asav971-4\asav-vi.ovf vi://<имя пользователя>:<пароль>@<Адрес vSphere>/<Имя датацентра>/host/<Имя хоста>

--deploymentOption=ASAv30 тут выбор типа инсталяции

вторник, 28 марта 2017 г.

Переходим с RSTP и прочего музейного Spanning Three на REP (Resilient Ethernet Protocol)

Когда это можно делать?
Когда у вас кольцевая топология, хотя в общем случае это не совсем так, можно и на сложных топологиях реализовывать REP.
Ну и конечно оборудование в кольце должно быть Cisco.

Зачем это нужно?
1. REP быстрый, восстановление работы кольца при разрыве, менее чем за 200ms
2. Это крайне удобно, одной командой на любом коммутаторе в кольце, вы видите всю топологию кольца:
SW1#sh rep topology
REP Segment 100
BridgeName       PortName   Edge Role
---------------- ---------- ---- ----
SW1       Te1/1/1    Pri  Open
sw2         Gi1/2           Open
sw2        Gi1/1           Open
sw3        Gi1/1           Alt
sw3        Gi1/2           Open
sw4        Gi1/1           Open
sw4        Gi1/2           Open
SW1      Te2/1/1    Sec  Open

При помощи одного SNMP сенсора, вы можете контролировать целостность кольца:
crep segment complete
OID: 1.3.6.1.4.1.9.9.601.1.3.1.1.4
Значения два:
1 - кольцо в порядке.
2 - кольцо разорвано

Собственно настройка заключается в следующем:
Назначаем VLAN в котором будут ходить REP сообщения:

rep admin vlan <нужный VLAN ID>

по умолчанию это VLAN 1

Далее на корневом (например 3750 или 3850 или 4500) коммутаторе, если он поддерживает REP, на портах смотрящих в кольцо, вводим:

rep segment <номер сегмента, например как выше, 100> edge (можно еще много опций, смотрите подробности в документации, но этого уже достаточно)

То есть на корневом коммутаторе у нас должно быть два Edge порта.

На остальных коммутаторах, на интерфейсах в кольце, вводим просто:

rep segment <номер сегмента, например как выше, 100>

Ежели ваш корневой коммутатор не знает про REP - нестрашно, на соседних с ним портах кольцевых коммутаторов, вводим:


rep segment <номер сегмента, например как выше, 100> no-neighbor

Вот так все просто.

Единственное, если у вас уже есть кольцо на STP, делайте так:
1. Сначала убедитесь что у вас целое кольцо, (эх, вот тут то REP удобен, но его в этом случае еще нет :-))
2. Сначала настраиваем один Edge порт, затем переходим к соеду и делаем просто REP порт, вот тут еще не поднимится REP, нужно сделать второй REP порт, и лучше пользоваться reload in 10 :-)

четверг, 16 марта 2017 г.

Syslog RFC5424

В теле сообщения есть в начале значение Priority
Например <13>
Оно высчитывается так:
Facility умножаем на 8 (по сути сдвиг влево на 3 бита << 3)
И прибавляем к этому Severity.
Логично что Severity принимает значения от 0 до 7
А Facility от 0 до 23.
Жесткой привязки значений к какому либо типу сообщения нет однако обычно применяют то, что написано в RFC:

Facility:
0             kernel messages
1             user-level messages
2             mail system
3             system daemons
4             security/authorization messages
5             messages generated internally by syslogd
6             line printer subsystem
7             network news subsystem
8             UUCP subsystem
9             clock daemon
10            security/authorization messages
11            FTP daemon
12            NTP subsystem
13            log audit
14            log alert
15            clock daemon (note 2)
16            local use 0  (local0)
17            local use 1  (local1)
18            local use 2  (local2)
19            local use 3  (local3)
20            local use 4  (local4)
21            local use 5  (local5)
22            local use 6  (local6)
23            local use 7  (local7)

Severity:
0       Emergency: system is unusable
1       Alert: action must be taken immediately
2       Critical: critical conditions
3       Error: error conditions
4       Warning: warning conditions
5       Notice: normal but significant condition
6       Informational: informational messages
7       Debug: debug-level messages

То есть наше 13 получилось из Faclity 1*8 плюс severity 5
то есть это User Notice

понедельник, 30 января 2017 г.

ASA reverse-route

При подключении удаленных пользователей по AnyConnect, в таблицу маршрутизации добавляется статическая запись с адресом клиента и маской /32
Можно в процесс машрутизации добавить редистрибуцию статических маршрутов.
Но мы помним что в статику добавляется /32 поэтому лично я делаю route-map и в ней prefix-list а там permit <адрес пула>/<маска пула> le 32

И еще, если вы используете dynamic map для подключения удаленных клиентов по IPsec (например нативным MAC клиентом) то в dynamic map нужно дать команду set revers-route

среда, 11 января 2017 г.

EEPROM

AT24C01B     01B
AT24C02B     02B
AT24C04B     04B
AT24C08B     08B
AT24C16B     16B
AT24C32C     32C
AT24C64C     64C
AT24C128B    2DB
AT24C256B    2EB
AT24C512B    2FB
AT24C1024B  2GB
AT25C512     5F
AT93C46D     46D
AT93C46E     46E
AT34C02C    34C
AT24HC02B   H2B
AT24HC04B   H4B
AT24C512B   2FB