iscsiadm: No portals found

Iscsi клиент с адреса 10.5.252.5 пытается соединиться с сервером 10.5.4.58 но упорно не видит target который со стороны сервера является вторым target (первый таргет работает с другим клиентом).

Забегая вперёд поясню – проблема в правах доступа.
Одиночный IPv4 адрес в ACL нужно записывать без префикса подсетки /32

Для тех кто хочет понять процесс поиска проблемы опишу немного деталей:

1) selinux временно переключён в Permissive.

[root@localhost server]# setenforce 0
[root@localhost server]# getenforce 
Permissive

2) iptables принимает входящие соединения на tcp порт 3260

[root@localhost server]# iptables -nvL INPUT | grep 3260
   91 46412 ISCSI      tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:3260 

[root@localhost server]# iptables -nvL ISCSI
Chain ISCSI (1 references)
 pkts bytes target     prot opt in     out     source               destination         
   77  4484 ACCEPT     all  --  bond0  *       10.5.0.0/16          0.0.0.0/0           
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           LOG flags 0 level 4 prefix `ISCSI ' 
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited 

3) и iscsi сервер tdtd слушает все нужные адреса и интерфейсы

[root@localhost server]# netstat -nlptu | grep tgt
tcp        0      0 0.0.0.0:3260                0.0.0.0:*                   LISTEN      2555/tgtd           
tcp        0      0 :::3260                     :::*                        LISTEN      2555/tgtd           

4) разумеется, между клиентом и сервером есть сетевая связность на уровне tcp и порта 3260.

[root@localhost client]# tcping 10.5.4.58 3260
10.5.4.58 port 3260 open.

Вот что показывает клиент при попытке получить список target с сервера

[root@localhost client]# iscsiadm --mode discoverydb --type sendtargets --portal 10.5.4.58 --discover
iscsiadm: No portals found

А вот настройка ACL со стороны сервера на втором target

[root@localhost server]# tgtadm --op show --mode target
...
...
...
    ACL information:
        10.5.252.5/32

И кажется что всё ок так как tcpdump показывает двухстороннюю коммуникацию между клиентом и сервером.
Но клиент упорно не видит target.
Запускаем tcpdump на сервере (можно и на клиенте) и после этого на клиенте запускаем команду discover:

[root@localhost server]# tcpdump -nn -i bond0 port 3260
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bond0, link-type EN10MB (Ethernet), capture size 65535 bytes
06:42:45.595466 IP 10.5.252.5.34770 > 10.5.4.58.3260: Flags [S], seq 1277547255, win 64240, options [mss 1366,sackOK,TS val 2794562310 ecr 0,nop,wscale 7], length 0
06:42:45.595500 IP 10.5.4.58.3260 > 10.5.252.5.34770: Flags [S.], seq 2558380001, ack 1277547256, win 18280, options [mss 9152,sackOK,TS val 2387301250 ecr 2794562310,nop,wscale 7], length 0
06:42:45.613325 IP 10.5.252.5.34770 > 10.5.4.58.3260: Flags [.], ack 1, win 502, options [nop,nop,TS val 2794562328 ecr 2387301250], length 0
06:42:45.614251 IP 10.5.252.5.34770 > 10.5.4.58.3260: Flags [P.], seq 1:49, ack 1, win 502, options [nop,nop,TS val 2794562328 ecr 2387301250], length 48
06:42:45.614274 IP 10.5.4.58.3260 > 10.5.252.5.34770: Flags [.], ack 49, win 143, options [nop,nop,TS val 2387301269 ecr 2794562328], length 0
06:42:45.616822 IP 10.5.252.5.34770 > 10.5.4.58.3260: Flags [P.], seq 49:309, ack 1, win 502, options [nop,nop,TS val 2794562329 ecr 2387301250], length 260
06:42:45.616845 IP 10.5.4.58.3260 > 10.5.252.5.34770: Flags [.], ack 309, win 152, options [nop,nop,TS val 2387301271 ecr 2794562329], length 0
06:42:45.616973 IP 10.5.4.58.3260 > 10.5.252.5.34770: Flags [P.], seq 1:193, ack 309, win 152, options [nop,nop,TS val 2387301271 ecr 2794562329], length 192
06:42:45.635230 IP 10.5.252.5.34770 > 10.5.4.58.3260: Flags [.], ack 193, win 501, options [nop,nop,TS val 2794562349 ecr 2387301271], length 0
06:42:45.637398 IP 10.5.252.5.34770 > 10.5.4.58.3260: Flags [P.], seq 309:357, ack 193, win 501, options [nop,nop,TS val 2794562350 ecr 2387301271], length 48
06:42:45.637889 IP 10.5.252.5.34770 > 10.5.4.58.3260: Flags [P.], seq 357:373, ack 193, win 501, options [nop,nop,TS val 2794562350 ecr 2387301271], length 16
06:42:45.637955 IP 10.5.4.58.3260 > 10.5.252.5.34770: Flags [.], ack 373, win 152, options [nop,nop,TS val 2387301292 ecr 2794562350], length 0
06:42:45.638005 IP 10.5.4.58.3260 > 10.5.252.5.34770: Flags [P.], seq 193:241, ack 373, win 152, options [nop,nop,TS val 2387301292 ecr 2794562350], length 48
06:42:45.659009 IP 10.5.252.5.34770 > 10.5.4.58.3260: Flags [.], ack 241, win 501, options [nop,nop,TS val 2794562371 ecr 2387301292], length 0
06:42:45.661256 IP 10.5.252.5.34770 > 10.5.4.58.3260: Flags [R.], seq 373, ack 241, win 501, options [nop,nop,TS val 2794562372 ecr 2387301292], length 0
^C
15 packets captured
15 packets received by filter
0 packets dropped by kernel

Заглянув внутрь пакетов видно что спрашивает клиент и что ему отвечает сервер.

[root@localhost server]# tcpdump -nn -xX -i bond0 port 3260

Из увиденного понятно, что сервер не посылает клиенту списка target.
На другом рабочем target в содержимом одного из последних пакетов видно открытым текстом имя target переданного сервером:

09:45:42.163005 IP 10.5.4.58.3260 > 10.5.252.5.38630: Flags [P.], seq 193:317, ack 373, win 152, options [nop,nop,TS val 2398277817 ecr 2805538873], length 124
	0x0000:  4500 00b0 8ee5 4000 4006 9719 0a05 043a  E.....@.@......:
	0x0010:  0a05 fc05 0cbc 96e6 5bc2 5f01 eb86 52a3  ........[._...R.
	0x0020:  8018 0098 14ec 0000 0101 080a 8ef2 d0b9  ................
	0x0030:  a739 2039 2480 0000 0000 0049 0000 0000  .9.9$......I....
	0x0040:  0000 0000 0000 0001 ffff ffff 0000 0001  ................
	0x0050:  0000 0002 0000 0002 0000 0000 0000 0000  ................
	0x0060:  0000 0000 5461 7267 6574 4e61 6d65 3d69  ....TargetName=i
	0x0070:  716e 2e32 3031 352d 3132 2e63 6f6d 2e76  qn.2015-12.com.v
	0x0080:  6473 3a69 7363 7369 6469 736b 3200 5461  ds:iscsidisk2.Ta
	0x0090:  7267 6574 4164 6472 6573 733d 3130 2e35  rgetAddress=10.5
	0x00a0:  2e34 2e35 383a 3332 3630 2c31 0000 0000  .4.58:3260,1....

Из этого можно предположить что сервер не считает клиента авторизованным для какой либо информации о target

Для дебага на втором target, который не появляется на клиенте, добавляем в ACL все адреса:

[root@localhost server]# tgtadm --lld iscsi --mode target --op bind --tid 2 --initiator-address=ALL

Клиент увидел второй target!

[root@localhost client]# iscsiadm --mode discoverydb --type sendtargets --portal 10.5.4.58 --discover
10.5.4.58:3260,1 iqn.2015-12.com.vds:iscsidisk2

Убираем доступ со всех адресов из ACL. Убираем и адрес с префиксом. И добавляем только адрес одного клиента без префикса.

[root@localhost server]# tgtadm --lld iscsi --mode target --op unbind --tid 2 --initiator-address=ALL
[root@localhost server]# tgtadm --lld iscsi --mode target --op unbind --tid 2 --initiator-address=10.5.252.5/32
[root@localhost server]# tgtadm --lld iscsi --mode target --op unbind --tid 2 --initiator-address=10.5.252.5
[root@localhost server]# tgtadm --op show --mode target
...
...
...
    ACL information:
        10.5.252.5

Готово.

raspberry pi и обратный ssh туннель – или как добраться до своей малинки за файрволом

Для доступа к “малинке” которая находится за файрволом потребуется сервер в интернете с публичным адресом
Адрес сервера в интернете: 123.123.123.321
На этом же адресе 123.123.123.321 откроем порт 2222 который будет “проброшен” на малинку на порт 22
На сервере в интернете создадим пользователя и каталог для ключа аутентификации

ssh root@123.123.123.321
useradd reverse-tunnel
mkdir -m700 /home/reverse-tunnel/.ssh

Continue reading raspberry pi и обратный ssh туннель – или как добраться до своей малинки за файрволом

Отключение wpa_supplicant на VDS или десктопе где нет WiFi

Установка NetworkManager тянет за собой кучу ненужных зависимостей которые часто не нужны и которые нельзя удалить но хочется заблокировать. Одна из них wpa_supplicant.

  663 ?        Ss     2:29 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
  666 ?        S      0:03 /usr/sbin/chronyd
  706 ?        Ss     0:16 /usr/sbin/crond -n
  716 tty1     Ss+    0:00 /sbin/agetty --noclear tty1 linux
  749 ?        Ss     0:00 /usr/sbin/wpa_supplicant -u -f /var/log/wpa_supplicant.log -c /etc/wpa_supplicant/wpa_supplicant.conf -u -f /var/log/wpa_supplicant

Остановить
Запретить
И “слить” в /dev/null

systemctl stop wpa_supplicant
systemctl disable wpa_supplicant
systemctl mask wpa_supplicant.service

iptables в RHEL 7 / Centos 7

Centos 7 как вернуть iptables вместо firewalld

Я считал, считаю и буду считать, что iptables в его старом чистом виде больше подходит для серверов чем новомодный firewalld который сначала запихнули в дистрибутивы федоры начиная с 18-й, а теперь ещё и в RHEL7 и Centos 7. Во-первых потому, что firewalld генерирует большое количество бессмысленных правил которые излишне тормозят работу iptables. Я пробежался по цепочке INPUT пустого настроенного по умолчанию firewalld и насчитал там 14!!! пустых переходов! Возможно это гениальное приложение с очень продуманной архитектурой, но вот однозначно ему не место в высоконагруженных системах. Во-вторых читать и понимаеть вывод iptables -nvL без обработки практически невозможно.
В-третьих на серверах нет нужды динамически управлять iptables, а fail2ban при небольших доработках конфигов прекрасно справляется со своей работой.

Поэтому если я устанавливаю сервер на Centos 7, то первым делом я возвращаю iptables.
Continue reading iptables в RHEL 7 / Centos 7

Centos. Unable to create bridge virbr1 Package not installed.

При отключённом ipv6 в centos 6.7 (Final) столкнулся с тем что не запускается сеть и не создаётся бридж.

[root@fileserver ~]# virsh net-start routed
error: Failed to start network routed
error: Unable to create bridge virbr1: Package not installed

В логе

Apr 13 13:41:35 fileserver kernel: bridge: Unknown symbol ipv6_dev_get_saddr

Для исправления нужно в файле disable-ipv6.conf прописать правильную опцию

cat /etc/modprobe.d/disable-ipv6.conf
#install ipv6 /bin/true
options ipv6 disable_ipv6=1

И убрать ipv6 и net-pf-10 если они были добавлены в файл /etc/modprobe.d/blacklist.conf

[root@fileserver modprobe.d]# virsh net-start routed
Network routed started
[root@fileserver modprobe.d]# virsh net-list --all
Name                 State      Autostart     Persistent
--------------------------------------------------
default              inactive   no            yes
routed               active     no            yes
Apr 13 13:46:26 fileserver kernel: NET: Registered protocol family 10
Apr 13 13:46:26 fileserver kernel: lo: Disabled Privacy Extensions
Apr 13 13:46:26 fileserver kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready
Apr 13 13:46:26 fileserver kernel: tun0: Disabled Privacy Extensions
Apr 13 13:46:26 fileserver kernel: Bridge firewalling registered
Apr 13 13:46:26 fileserver kernel: device virbr1-nic entered promiscuous mode
Apr 13 13:46:26 fileserver kernel: virbr1: starting userspace STP failed, starting kernel STP

OpenVPN как не принять предложение сервера о настройке интерфейсов

В повседневной работе я пользуюсь десятками включённых VPN клиентов. Эти клиенты соединяются с разными серверами, а серверы имеют разные настройки. Так например у меня возникала ситуация когда нужный мне роут пробрасывался через TUN интерфейс который PUSH-ился с сервера. Если бы сервер использовал только я стоило бы перенастроить только сервер чтобы это исправить. Однако сервером пользуются и другие люди и там этот PUSH необходим. Сначала я руками переписывал роут и забывал до следующего переподключения. Но последнее время часто приходилось переподключаться и вечное переписывание роута стало раздражать. В документации к OpenVPN написано что в настройках с недавнего времени появился ключ который поможет клиенту отвергнуть то что ему предлагает сервер.
Continue reading OpenVPN как не принять предложение сервера о настройке интерфейсов

Расширение знаний о крипторграфии

Когда разбираюсь с гуглоаналитикой я давно наблюдаю поисковые запросы касающиеся протокола SSLv3. Со временем частота этих запросов и их разнообразие увеличивается. Выходит, что обыватели которые не смогли попасть на свои уютные жежешечки или вконтактики не по своей воле но всё чаще спрашивают у всезнающего гуглина о том что же такое SSLv3.

Вот топ вопросов:

как включить поддержку протокола sslv3
как в амиго включить протокол ssl3
как включить протокол sslv3
как подключить протокол sslv3 на facebook
sslv3 как включить видео
sslv3 как включить chrome

Иногда вопросы тянут на сочинение

как исправить ошибку в вконтакте клиент и сервер поддерживают разные версии протокола ssl или шифров. скорее всего, серверу требуется поддержка протокола sslv3, однако она была отключена.

Но мне особенно понравился вопрос

скачать протокол sslv3
sslv3 скачать

Теперь я понимаю почему мы все до сих пор получаем “Нигери́йские пи́сьма“, почему до сих пор работает “развод” пользователя на то чтобы заставить его скачать и поставить утилиту какую нибуть г.в.утилиту.

Хочется всем таким искателям приключений сказать: SSLv3 умер. Не нужно его “откапывать” скачивать и включать!

Windows 10 BestCrypt BSOD и перезагрузка при размонтировании криптодиска

При размонтировании шифрованного диска выдавалось сообщение о том, что с диска открыты какие-то файлы и его размонтирование может привести к потере несохранённых данных открытых файлов. После согласия пользователя с размонтированием система входила в долгое ожидание и через минуту уходила в BSOD (синий экран смерти) и перезагружалась в соответствии с настройками. Ситуация повторялась в 9-ти случаях из 10-ти. Windows 10 работала в виртуальной машине KVM. Другие аналогичные инсталяции работали под VMWare и проблем не создавали.
Continue reading Windows 10 BestCrypt BSOD и перезагрузка при размонтировании криптодиска

Обновление ssh и очередное отключение устаревших алгоритмов

Время идёт и постепенно старые алгоритмы шифрования становятся небезопасными. Разрабочики софта конечно же постепенно их отключают. Но для админа-то обычно это просиходит внезапно и ой как не вовремя и становится чертовски неприятным сюрпризом, особенно если обновления накатываются атоматически. Так обновление на Fedora 23 подарило мне пару незабываемых часов когда я не мог достучаться на большую часть серверов которыми управляю. Казалось бы что обновление openssl, openssh в любом виде должно стать красной тряпкой, но пока что стереотип поведения не сложился. И последнее обновление openssh.i686 7.2p1-2.fc23, openssh-server.i686 7.2p1-2.fc23, openssh-clients.i686 7.2p1-2.fc23 снова подарило неожиданный сюрприз в виде невозможности залогиниться на клиентский mikrotik.

[user001@localhost ~]$ ssh root@192.168.88.1
ssh_dispatch_run_fatal: Connection to 192.168.88.1 port 22: DH GEX group out of range

И как обычно бывает в свежих случаях гугл и яндекс не показали ничего интересного.
— Упс, сказал я и полез в мануал.
Continue reading Обновление ssh и очередное отключение устаревших алгоритмов

sudoers: проверка синтаксиса

Когда вы редактируете файл /etc/sudoers или создаёте подключаемые к нему файлы в каталоге /etc/sudoers.d/* то неплохо бы сразу проверить синтаксис. Если вы редактируете sudoers в его редакторе visudo то он автоматически проверит синтаксис при сохранении. А если как я больше пользуетесь mcedit то после редактирования sudoers можно выполнить проверку указав ключ:

[root@d01 sudoers.d]# visudo -c
/etc/sudoers: parsed OK
/etc/sudoers.d/zabbix_sudo: parsed OK

Как видите синтаксис проверился вместе со вложением /etc/sudoers.d/zabbix_sudo.

Но на боевом сервере, где sudo активно используется системой мониторинга или каким либо скриптом из crontab, не стоит проводить правку файла по-живому. Для этого его можно скопировать в другое место и там редактировать. А после редактирования проверить всё той же командой но с дополнительным ключом:

[root@d01 sudoers.d]# visudo -cf /root/sudoers.new
/root/sudoers.new: parsed OK

После этого его можно смело копировать на место боевого файла. Не забудтре однако правильно поставить права 440 для владелеца и группы root:root.