-Поиск по дневнику

Поиск сообщений в lj_ru_root

 -Подписка по e-mail

 

 -Постоянные читатели

 -Статистика

Статистика LiveInternet.ru: показано количество хитов и посетителей
Создан: 24.06.2007
Записей:
Комментариев:
Написано: 1




Клуб Сисадминов - LiveJournal.com


Добавить любой RSS - источник (включая журнал LiveJournal) в свою ленту друзей вы можете на странице синдикации.

Исходная информация - http://community.livejournal.com/ru_root/.
Данный дневник сформирован из открытого RSS-источника по адресу http://ru-root.livejournal.com/data/rss/, и дополняется в соответствии с дополнением данного источника. Он может не соответствовать содержимому оригинальной страницы. Трансляция создана автоматически по запросу читателей этой RSS ленты.
По всем вопросам о работе данного сервиса обращаться со страницы контактной информации.

[Обновить трансляцию]

logrotate в docker

Среда, 20 Сентября 2017 г. 08:04 + в цитатник
Камрады, недавно столкнулся с такой вещью, как docker
после чего имею вопрос: Как настроить ротацию логов nginx и apache, запущенных в docker
на хосте SLES12.2 с дефолтным docker1.12
гугленье дает отсыл к статьям двухлетней давности с невменяемыми рекомендациями, типа слать логи в stdout контейнера
прошу подсказки, где искать.

https://ru-root.livejournal.com/2899112.html


Облачные DNS

Четверг, 14 Сентября 2017 г. 11:25 + в цитатник
Кто-нибудь ими пользуется?
Которые получше - Amazon, Google, или ещё какие-нибудь?
И есть ли там какие-нибудь проблемы?

https://ru-root.livejournal.com/2898837.html


Метки:  

вакансия: Системный администратор Unix, Обнинск Калужской области

Среда, 13 Сентября 2017 г. 23:21 + в цитатник
Здравствуйте.

UNIX-оиды из регионов(РФ) есть?
Вам вакансия с релокацией в Обнинск: https://hh.ru/vacancy/22480430.

зы. Резюме можно слать и мне в том числе: bpankin@gmail.com

https://ru-root.livejournal.com/2898561.html


Linux и наследование владельцев/прав

Вторник, 12 Сентября 2017 г. 13:28 + в цитатник
Привет.

Камрады, а как белые люди в линуксе решают задачу наследования владельцев/прав на свежесоздаваемые подкаталоги и файлы в определённом каталоге?

У нас есть CMS-ка, которая создаёт сама себе каталоги и файлы. Нужно, чтобы владельцем на них становились apache:somegroup с правами drwx:rwx:--- и rw-:rw-:---

И есть пачка разработчиков, которые ходят по SFTP/SSH и тоже создают файлы в структуре каталогов CMS. И при создании подкаталогов или файлов владельцем на них проставляется developername:somegroup. И тогда апач не может получить доступ к этим каталогам/файлам.

Как по фэншую заставить линукс наследовать владельца-пользователя для всех создаваемых каталогов/папок?

Что уже было предпринято: поставлен SGID на все каталоги и подкаталоги. Поставлены дефолтные ACL для файлов каталогов d:group:somegroup:rw (потому что без этого при создании каталогов/файлов у группы были права r-x:r--. Затем фантазия закончилась :-)

https://ru-root.livejournal.com/2898295.html


firewalld не блокирует порт

Вторник, 05 Сентября 2017 г. 22:34 + в цитатник
Коллеги, чо-та какой-то подземный стук наблюдаю я.

Попросили тут помочь с линухом. Грабля следующего характера -- firewalld не блокирует некий порт. Причём 22-ой, например (если его убрать из списка портов в зоне) блокирует, а этот (8033, на нём веб-интерфейс управления докером висит) продолжает быть доступным. Я так-то в линухе (а тем более в докере) не особо силён, поэтому прошу посильного вспомоществования.

Конфиг файрвола:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
   64  6779 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
  391 43534 INPUT_direct  all  --  *      *       0.0.0.0/0            0.0.0.0/0
  391 43534 INPUT_ZONES_SOURCE  all  --  *      *       0.0.0.0/0            0.0.0.0/0
  391 43534 INPUT_ZONES  all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID LOG flags 0 level 4 prefix "STATE_INVALID_DROP: "
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID
  390 43482 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 4 prefix "FINAL_REJECT: "
  390 43482 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 1524  357K DOCKER-ISOLATION  all  --  *      *       0.0.0.0/0            0.0.0.0/0
  984  148K ACCEPT     all  --  *      docker0  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
   23  2681 DOCKER     all  --  *      docker0  0.0.0.0/0            0.0.0.0/0
  517  206K ACCEPT     all  --  docker0 !docker0  0.0.0.0/0            0.0.0.0/0
   16  2372 ACCEPT     all  --  docker0 docker0  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  *      br-766cd293c639  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 DOCKER     all  --  *      br-766cd293c639  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  br-766cd293c639 !br-766cd293c639  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  br-766cd293c639 br-766cd293c639  0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
    0     0 FORWARD_direct  all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 FORWARD_IN_ZONES_SOURCE  all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 FORWARD_IN_ZONES  all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 FORWARD_OUT_ZONES_SOURCE  all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 FORWARD_OUT_ZONES  all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID LOG flags 0 level 4 prefix "STATE_INVALID_DROP: "
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate INVALID
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 4 prefix "FINAL_REJECT: "
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT 25 packets, 3078 bytes)
 pkts bytes target     prot opt in     out     source               destination
  364 47916 OUTPUT_direct  all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain DOCKER (2 references)
 pkts bytes target     prot opt in     out     source               destination
    7   309 ACCEPT     tcp  --  !docker0 docker0  0.0.0.0/0            172.18.0.5           tcp dpt:9000
    0     0 ACCEPT     tcp  --  !docker0 docker0  0.0.0.0/0            172.18.0.7           tcp dpt:80
    0     0 ACCEPT     tcp  --  !docker0 docker0  0.0.0.0/0            172.18.0.6           tcp dpt:15672
    0     0 ACCEPT     tcp  --  !docker0 docker0  0.0.0.0/0            172.18.0.6           tcp dpt:5672
    0     0 ACCEPT     tcp  --  !docker0 docker0  0.0.0.0/0            172.18.0.8           tcp dpt:8500
    0     0 ACCEPT     tcp  --  !docker0 docker0  0.0.0.0/0            172.18.0.8           tcp dpt:8301
    0     0 ACCEPT     tcp  --  !docker0 docker0  0.0.0.0/0            172.18.0.8           tcp dpt:8300

Chain DOCKER-ISOLATION (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all  --  br-766cd293c639 docker0  0.0.0.0/0            0.0.0.0/0
    0     0 DROP       all  --  docker0 br-766cd293c639  0.0.0.0/0            0.0.0.0/0
 1524  357K RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain FORWARD_IN_ZONES (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 FWDI_public  all  --  ens192 *       0.0.0.0/0            0.0.0.0/0           [goto]
    0     0 FWDI_public  all  --  +      *       0.0.0.0/0            0.0.0.0/0           [goto]

Chain FORWARD_IN_ZONES_SOURCE (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD_OUT_ZONES (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 FWDO_public  all  --  *      ens192  0.0.0.0/0            0.0.0.0/0           [goto]
    0     0 FWDO_public  all  --  *      +       0.0.0.0/0            0.0.0.0/0           [goto]

Chain FORWARD_OUT_ZONES_SOURCE (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD_direct (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain FWDI_public (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 FWDI_public_log  all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 FWDI_public_deny  all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 FWDI_public_allow  all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0

Chain FWDI_public_allow (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain FWDI_public_deny (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain FWDI_public_log (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain FWDO_public (2 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 FWDO_public_log  all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 FWDO_public_deny  all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 FWDO_public_allow  all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain FWDO_public_allow (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain FWDO_public_deny (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain FWDO_public_log (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain INPUT_ZONES (1 references)
 pkts bytes target     prot opt in     out     source               destination
   10   401 IN_public  all  --  ens192 *       0.0.0.0/0            0.0.0.0/0           [goto]
  381 43133 IN_public  all  --  +      *       0.0.0.0/0            0.0.0.0/0           [goto]

Chain INPUT_ZONES_SOURCE (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain INPUT_direct (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain IN_public (2 references)
 pkts bytes target     prot opt in     out     source               destination
  391 43534 IN_public_log  all  --  *      *       0.0.0.0/0            0.0.0.0/0
  391 43534 IN_public_deny  all  --  *      *       0.0.0.0/0            0.0.0.0/0
  391 43534 IN_public_allow  all  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0

Chain IN_public_allow (1 references)
 pkts bytes target     prot opt in     out     source               destination
    1    52 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22 ctstate NEW

Chain IN_public_deny (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain IN_public_log (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT_direct (1 references)
 pkts bytes target     prot opt in     out     source               destination



Куда ещё можно посмотреть, чтобы понять, как так-то? Обращение идёт точно к этой машине (виртуалка, Centos 7), tcpdump не даст соврать.

https://ru-root.livejournal.com/2897989.html


Отчего может быть проблема с ресолвингом в curl ?

Четверг, 31 Августа 2017 г. 13:19 + в цитатник
Есть некая программа (бинарная, не скрипт), использующая для связи с внешними сайтами libcurl.so .
И у неё время от времени случается такая фигня: 'Curl Error 6 : 'couldn't resolve host name' - многие сотни таких ошибок про один и тот же хост за полторы-две минуты, потом всё налаживается. А потом опять такая же фигня случается, обычно 4-5 раз в день.

При этом host и dig все эти хосты всегда успешно ресолвят. На всякий случай проверил авторитетные сервера доменов, с которыми это случается, все нормально работают. И через указанные в /etc/resolv.conf один местный и два гугловых сервера тоже всё успешно ресолвится.

Гуглить пробовал, единственная найденная идея - поменять в nsswitch.com порядок поиска со стандартного hosts: files dns на hosts: dns files. Поменял, не помогло.

Похоже, проблема где-то внутри curl'овой библиотеки. Есть какие-нибудь идеи, отчего такое может быть, и как это можно исправить?

https://ru-root.livejournal.com/2897748.html


Метки:  

Локальный репозиторий CentOS

Среда, 30 Августа 2017 г. 17:30 + в цитатник
Коллеги, а внесите, пожалуйста, среди меня ясность по следующему вопросу.

Правильно ли я понимаю, что репозиторий в центоси -- это просто каталожек с RPM-пакетами и каталожек repodata, в котором лежит некоторая мета-информация о том, какие пакеты и каких версий есть в наличии? И repodata можно подготовить с помощью утили createrepo.

И потом всё это хозяйство можно просто презентовать по HTTP, прописать в yum.repos.d/myrepo.conf и дальше центось сможет беспалевно тянуть оттуда пакеты?

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

Как по фэншую вообще решается задача организации локальной репы? Можно просто отсинкать все RPM-ы откуда-нибудь (скажем, из http://mirror.centos.org/centos/7/os/x86_64/Packages/) в локальный каталог /opt/myrepo01, потом сказать creterepo /opt/myrepo01, и раздать это с http?

А как проверять актуальность/свежесть репы? Как отследить ситуацию, что в какой-то момент синк по-тихому сломался, и никаких новых версий пакетов уже не затягивается? Это как-то отражается в данных, которые генерятся с помощью createrepo? Я попробовал на одном каталоге несколько раз вызвать createrepo, без изменений в составе или версиях RPM, и оно каждый раз разные timestamp'ы в repomd.xml проставляет. Это баг или фича? Или я просто не туда смотрю?

https://ru-root.livejournal.com/2897587.html


Специалист по Zabbix на разовый проект.

Среда, 23 Августа 2017 г. 12:46 + в цитатник
Уважаемые коллеги, нужен спец по заббиксу, что бы поднять и настроить заббикс в нашей компании.

70 серверов (включая виртуальные) плюс порядка 25 единиц активного сетевого оборудования (преимущественно Cisco).

Необходимо контролировать нехватку места на дисках, избыточную загрузку процессора, оперативной памяти, сетевого интерфейса, интенсивность работы RAID (и состояние массива - grade/degrade), перегрев ну и, собственно, сам факт работоспособности каждого сервера и каждого сетевого активного устройства.

Плюс, возможно, мониторинг печатающих устройств - но это уже надо обсуждать.

Ищем человека, который может потянуть этот проект.

Писать на elyssov собака гымейл, если возможно, то с предварительной финансовой оценкой проекта.

За подробностями - можно и в камменты.

https://ru-root.livejournal.com/2897281.html


Специалист по Zabbix на разовый проект.

Среда, 23 Августа 2017 г. 12:46 + в цитатник
Уважаемые коллеги, нужен спец по заббиксу, что бы поднять и настроить заббикс в нашей компании.

70 серверов (включая виртуальные) плюс порядка 25 единиц активного сетевого оборудования (преимущественно Cisco).

Необходимо контролировать нехватку места на дисках, избыточную загрузку процессора, оперативной памяти, сетевого интерфейса, интенсивность работы RAID (и состояние массива - grade/degrade), перегрев ну и, собственно, сам факт работоспособности каждого сервера и каждого сетевого активного устройства.

Плюс, возможно, мониторинг печатающих устройств - но это уже надо обсуждать.

Ищем человека, который может потянуть этот проект.

Писать на elyssov собака гымейл, если возможно, то с предварительной финансовой оценкой проекта.

За подробностями - можно и в камменты.

http://ru-root.livejournal.com/2897281.html


Выбор распределенной ФС

Понедельник, 21 Августа 2017 г. 09:51 + в цитатник
Доброе утро, Коллеги!

У меня пятничный вопрос про выбор отказоустойчивого файлового хранилища (в пятницу на прошлой неделе написать неуспел).

Необходимо отказоустойчивое хранилище для файлов. Серверы располагаются в двух ДЦ. С каждого из серверов необходимо чтение и запись файлов. Файлы в основном до 0,5-1Мб. При отказе связи между ДЦ, необходимо продолжить работу на другом ДЦ.

Думаю про:
1) CephFS
2) LeoFS
3) DRBD + раздача по NFS на локальные серверы в каждом из ДЦ

Может посоветуете что-то ещё? Что из этого проще и надежнее в эксплуатации?

https://ru-root.livejournal.com/2897028.html


Метки:  

Выбор распределенной ФС

Понедельник, 21 Августа 2017 г. 09:51 + в цитатник
Доброе утро, Коллеги!

У меня пятничный вопрос про выбор отказоустойчивого файлового хранилища (в пятницу на прошлой неделе написать неуспел).

Необходимо отказоустойчивое хранилище для файлов. Серверы располагаются в двух ДЦ. С каждого из серверов необходимо чтение и запись файлов. Файлы в основном до 0,5-1Мб. При отказе связи между ДЦ, необходимо продолжить работу на другом ДЦ.

Думаю про:
1) CephFS
2) LeoFS
3) DRBD + раздача по NFS на локальные серверы в каждом из ДЦ

Может посоветуете что-то ещё? Что из этого проще и надежнее в эксплуатации?

http://ru-root.livejournal.com/2897028.html


Метки:  

CARPовые адреса

Среда, 16 Августа 2017 г. 16:07 + в цитатник
В одной сетке установлены два маршрутизатора (pfsense), имеющие несколько общих адресов через CARP.
У одного, который сейчас MASTER, на LAN-интерфейсе так:
: ifconfig em1
em1: flags=8943 metric 0 mtu 1500
	options=9b
	ether 00:50:56:aa:ad:7d
	inet 10.20.1.2 netmask 0xffffff00 broadcast 10.40.1.255 
	inet 10.20.1.1 netmask 0xffffff00 broadcast 10.40.1.255 vhid 255
	nd6 options=21
	media: Ethernet autoselect (1000baseT )
	status: active
	carp: MASTER vhid 255 advbase 1 advskew 0


У другого, который BACKUP:
: ifconfig em1
em1: flags=8943 metric 0 mtu 1500
	options=9b
	ether 00:50:56:aa:a0:d5
	inet 10.20.1.3 netmask 0xffffff00 broadcast 10.40.1.255 
	inet 10.20.1.1 netmask 0xffffff00 broadcast 10.40.1.255 vhid 255
	nd6 options=21
	media: Ethernet autoselect (1000baseT )
	status: active
	carp: BACKUP vhid 255 advbase 1 advskew 100


.2 и .3 - это их личные адреса, а .1 - общий, который как раз CARP'ом обрабатывается, и он почему-то одновременно видится на обоих маршрутизаторах.
И на WAN-интерфейсе картина точно такая же, все общие адреса одновременно подняты на обоих.

Это нормально, что на BACKUP'ном сервере все адреса сразу есть, когда он ещё даже не собирается переключаться в MASTER?

https://ru-root.livejournal.com/2896806.html


Метки:  

CARPовые адреса

Среда, 16 Августа 2017 г. 16:07 + в цитатник
В одной сетке установлены два маршрутизатора (pfsense), имеющие несколько общих адресов через CARP.
У одного, который сейчас MASTER, на LAN-интерфейсе так:
: ifconfig em1
em1: flags=8943 metric 0 mtu 1500
	options=9b
	ether 00:50:56:aa:ad:7d
	inet 10.20.1.2 netmask 0xffffff00 broadcast 10.40.1.255 
	inet 10.20.1.1 netmask 0xffffff00 broadcast 10.40.1.255 vhid 255
	nd6 options=21
	media: Ethernet autoselect (1000baseT )
	status: active
	carp: MASTER vhid 255 advbase 1 advskew 0


У другого, который BACKUP:
: ifconfig em1
em1: flags=8943 metric 0 mtu 1500
	options=9b
	ether 00:50:56:aa:a0:d5
	inet 10.20.1.3 netmask 0xffffff00 broadcast 10.40.1.255 
	inet 10.20.1.1 netmask 0xffffff00 broadcast 10.40.1.255 vhid 255
	nd6 options=21
	media: Ethernet autoselect (1000baseT )
	status: active
	carp: BACKUP vhid 255 advbase 1 advskew 100


.2 и .3 - это их личные адреса, а .1 - общий, который как раз CARP'ом обрабатывается, и он почему-то одновременно видится на обоих маршрутизаторах.
И на WAN-интерфейсе картина точно такая же, все общие адреса одновременно подняты на обоих.

Это нормально, что на BACKUP'ном сервере все адреса сразу есть, когда он ещё даже не собирается переключаться в MASTER?

http://ru-root.livejournal.com/2896806.html


Метки:  

[SOLVED] IPsec между CentOS 7 и Windows 2012 R2

Четверг, 10 Августа 2017 г. 17:23 + в цитатник
Как писали в былые времена: "Приветствую, всемогущий All!"

Не выходит что-то секурный каменный цветок. В теории, как известно, теория и практика совпадают, а на практике нет.

Долбаюсь с настройкой IPsec между виндой (10.1.1.10) и центосью (10.1.2.26). Винда отвечает на ike ident, и на этом всё:

12:09:36.117723 IP (tos 0x0, ttl 64, id 29646, offset 0, flags [DF], proto UDP (17), length 204)
    10.1.2.26.isakmp > 10.1.1.10.isakmp: [udp sum ok] isakmp 1.0 msgid 00000000 cookie e6d44de9c8641db7->0000000000000000: phase 1 I ident:
    (sa: doi=ipsec situation=identity
        (p: #0 protoid=isakmp transform=1
            (t: #1 id=ike (type=enc value=3des)(type=hash value=sha1)(type=group desc value=modp2048)(type=auth value=preshared)(type=lifetype value=sec)(type=lifeduration value=2a30))))
    (vid: len=8)
    (vid: len=16)
    (vid: len=20)
    (vid: len=16)
    (vid: len=16)
12:09:36.118423 IP (tos 0x0, ttl 128, id 19867, offset 0, flags [none], proto UDP (17), length 236)
    10.1.1.10.isakmp > 10.1.2.26.isakmp: [udp sum ok] isakmp 1.0 msgid 00000000 cookie e6d44de9c8641db7->b2c0c64ce5211438: phase 1 R ident:
    (sa: doi=ipsec situation=identity
        (p: #0 protoid=isakmp transform=1
            (t: #1 id=ike (type=enc value=3des)(type=hash value=sha1)(type=group desc value=modp2048)(type=auth value=preshared)(type=lifetype value=sec)(type=lifeduration len=4 value=00002a30))))
    (vid: len=20)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)



И так по кругу. Возникает закономерный вопрос -- почему на ответ винды никакой реакции у центоси не возникает?


Конфиг strongswan:
config setup
        strictcrlpolicy=no
        uniqueids = yes

conn %default
    authby=secret
    keyexchange=ikev1
    mobike=no

conn host01
    left=10.1.2.26
    right=10.1.1.10
    type=transport
    auto=route
    pfs=no
    ike=3des-sha1-modp2048!
    esp=aes128-sha1



Логи ipsec:
Aug 10 17:31:29 03[MGR] checkin IKE_SA dc01[3]
Aug 10 17:31:29 03[MGR] checkin of IKE_SA successful
Aug 10 17:31:29 16[NET] sending packet: from 10.1.2.26[500] to 10.1.1.10[500]
Aug 10 17:31:33 09[MGR] checkout IKEv1 SA with SPIs bf2f04e4730454f7_i 0000000000000000_r
Aug 10 17:31:33 09[MGR] IKE_SA dc01[3] successfully checked out
Aug 10 17:31:33 09[IKE] sending retransmit 1 of request message ID 0, seq 1
Aug 10 17:31:33 09[NET] sending packet: from 10.1.2.26[500] to 10.1.1.10[500] (176 bytes)
Aug 10 17:31:33 09[MGR] checkin IKE_SA dc01[3]
Aug 10 17:31:33 09[MGR] checkin of IKE_SA successful
Aug 10 17:31:33 16[NET] sending packet: from 10.1.2.26[500] to 10.1.1.10[500]
Aug 10 17:31:40 10[MGR] checkout IKEv1 SA with SPIs bf2f04e4730454f7_i 0000000000000000_r
Aug 10 17:31:40 10[MGR] IKE_SA dc01[3] successfully checked out
Aug 10 17:31:40 10[IKE] sending retransmit 2 of request message ID 0, seq 1
Aug 10 17:31:40 10[NET] sending packet: from 10.1.2.26[500] to 10.1.1.10[500] (176 bytes)
Aug 10 17:31:40 10[MGR] checkin IKE_SA dc01[3]
Aug 10 17:31:40 10[MGR] checkin of IKE_SA successful
Aug 10 17:31:40 16[NET] sending packet: from 10.1.2.26[500] to 10.1.1.10[500]
Aug 10 17:31:53 03[MGR] checkout IKEv1 SA with SPIs bf2f04e4730454f7_i 0000000000000000_r
Aug 10 17:31:53 03[MGR] IKE_SA dc01[3] successfully checked out
Aug 10 17:31:53 03[IKE] sending retransmit 3 of request message ID 0, seq 1
Aug 10 17:31:53 03[NET] sending packet: from 10.1.2.26[500] to 10.1.1.10[500] (176 bytes)
Aug 10 17:31:53 03[MGR] checkin IKE_SA dc01[3]
Aug 10 17:31:53 03[MGR] checkin of IKE_SA successful
Aug 10 17:31:53 16[NET] sending packet: from 10.1.2.26[500] to 10.1.1.10[500]
Aug 10 17:32:17 07[MGR] checkout IKEv1 SA with SPIs bf2f04e4730454f7_i 0000000000000000_r
Aug 10 17:32:17 07[MGR] IKE_SA dc01[3] successfully checked out
Aug 10 17:32:17 07[IKE] sending retransmit 4 of request message ID 0, seq 1
Aug 10 17:32:17 07[NET] sending packet: from 10.1.2.26[500] to 10.1.1.10[500] (176 bytes)
Aug 10 17:32:17 07[MGR] checkin IKE_SA dc01[3]
Aug 10 17:32:17 07[MGR] checkin of IKE_SA successful
Aug 10 17:32:17 16[NET] sending packet: from 10.1.2.26[500] to 10.1.1.10[500]
Aug 10 17:32:59 07[MGR] checkout IKEv1 SA with SPIs bf2f04e4730454f7_i 0000000000000000_r
Aug 10 17:32:59 07[MGR] IKE_SA dc01[3] successfully checked out
Aug 10 17:32:59 07[IKE] sending retransmit 5 of request message ID 0, seq 1
Aug 10 17:32:59 07[NET] sending packet: from 10.1.2.26[500] to 10.1.1.10[500] (176 bytes)
Aug 10 17:32:59 07[MGR] checkin IKE_SA dc01[3]
Aug 10 17:32:59 07[MGR] checkin of IKE_SA successful


Даже не знаю, куда дальше копнуть.

UPD: отключил checksum offload, чтобы это не смущало. дамп трафика обновил на дамп после отключения оффлоада. Никаких изменений нет.

SOLVED. Как показало курение документации, в strongswan теперь есть две схемы настройки -- старая, через ipsec.conf, и новая -- через swanctl.conf. Так вот старая, похоже, в центоси сломана. Я с помощью гугла и такой-то матери перенёс конфиг в swanctl.conf, и оно заработало сразу. Вот пример конфига, кому интересно:

connections {
    dc01 {
        version = 1
        local_addrs = 10.1.2.26
        remote_addrs = 10.1.1.10
        aggressive = no
        unique = no
        proposals = 3des-sha1-modp2048
        reauth_time = 30m
        local {
            auth = psk
            id = 10.1.2.26
        }
        remote {
            auth = psk
            id = 10.1.1.10
        }
        children {
            dc01 {
                mode = transport
                esp_proposals = aes128-sha1
            }
        }
    }
}
secrets {
    ike02 {
        id = 10.1.1.10
        secret = $uperP@$$
    }
}

https://ru-root.livejournal.com/2896625.html


[SOLVED] IPsec между CentOS 7 и Windows 2012 R2

Четверг, 10 Августа 2017 г. 17:23 + в цитатник
Как писали в былые времена: "Приветствую, всемогущий All!"

Не выходит что-то секурный каменный цветок. В теории, как известно, теория и практика совпадают, а на практике нет.

Долбаюсь с настройкой IPsec между виндой (10.1.1.10) и центосью (10.1.2.26). Винда отвечает на ike ident, и на этом всё:

12:09:36.117723 IP (tos 0x0, ttl 64, id 29646, offset 0, flags [DF], proto UDP (17), length 204)
    10.1.2.26.isakmp > 10.1.1.10.isakmp: [udp sum ok] isakmp 1.0 msgid 00000000 cookie e6d44de9c8641db7->0000000000000000: phase 1 I ident:
    (sa: doi=ipsec situation=identity
        (p: #0 protoid=isakmp transform=1
            (t: #1 id=ike (type=enc value=3des)(type=hash value=sha1)(type=group desc value=modp2048)(type=auth value=preshared)(type=lifetype value=sec)(type=lifeduration value=2a30))))
    (vid: len=8)
    (vid: len=16)
    (vid: len=20)
    (vid: len=16)
    (vid: len=16)
12:09:36.118423 IP (tos 0x0, ttl 128, id 19867, offset 0, flags [none], proto UDP (17), length 236)
    10.1.1.10.isakmp > 10.1.2.26.isakmp: [udp sum ok] isakmp 1.0 msgid 00000000 cookie e6d44de9c8641db7->b2c0c64ce5211438: phase 1 R ident:
    (sa: doi=ipsec situation=identity
        (p: #0 protoid=isakmp transform=1
            (t: #1 id=ike (type=enc value=3des)(type=hash value=sha1)(type=group desc value=modp2048)(type=auth value=preshared)(type=lifetype value=sec)(type=lifeduration len=4 value=00002a30))))
    (vid: len=20)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)



И так по кругу. Возникает закономерный вопрос -- почему на ответ винды никакой реакции у центоси не возникает?


Конфиг strongswan:
config setup
        strictcrlpolicy=no
        uniqueids = yes

conn %default
    authby=secret
    keyexchange=ikev1
    mobike=no

conn host01
    left=10.1.2.26
    right=10.1.1.10
    type=transport
    auto=route
    pfs=no
    ike=3des-sha1-modp2048!
    esp=aes128-sha1



Логи ipsec:
Aug 10 17:31:29 03[MGR] checkin IKE_SA dc01[3]
Aug 10 17:31:29 03[MGR] checkin of IKE_SA successful
Aug 10 17:31:29 16[NET] sending packet: from 10.1.2.26[500] to 10.1.1.10[500]
Aug 10 17:31:33 09[MGR] checkout IKEv1 SA with SPIs bf2f04e4730454f7_i 0000000000000000_r
Aug 10 17:31:33 09[MGR] IKE_SA dc01[3] successfully checked out
Aug 10 17:31:33 09[IKE] sending retransmit 1 of request message ID 0, seq 1
Aug 10 17:31:33 09[NET] sending packet: from 10.1.2.26[500] to 10.1.1.10[500] (176 bytes)
Aug 10 17:31:33 09[MGR] checkin IKE_SA dc01[3]
Aug 10 17:31:33 09[MGR] checkin of IKE_SA successful
Aug 10 17:31:33 16[NET] sending packet: from 10.1.2.26[500] to 10.1.1.10[500]
Aug 10 17:31:40 10[MGR] checkout IKEv1 SA with SPIs bf2f04e4730454f7_i 0000000000000000_r
Aug 10 17:31:40 10[MGR] IKE_SA dc01[3] successfully checked out
Aug 10 17:31:40 10[IKE] sending retransmit 2 of request message ID 0, seq 1
Aug 10 17:31:40 10[NET] sending packet: from 10.1.2.26[500] to 10.1.1.10[500] (176 bytes)
Aug 10 17:31:40 10[MGR] checkin IKE_SA dc01[3]
Aug 10 17:31:40 10[MGR] checkin of IKE_SA successful
Aug 10 17:31:40 16[NET] sending packet: from 10.1.2.26[500] to 10.1.1.10[500]
Aug 10 17:31:53 03[MGR] checkout IKEv1 SA with SPIs bf2f04e4730454f7_i 0000000000000000_r
Aug 10 17:31:53 03[MGR] IKE_SA dc01[3] successfully checked out
Aug 10 17:31:53 03[IKE] sending retransmit 3 of request message ID 0, seq 1
Aug 10 17:31:53 03[NET] sending packet: from 10.1.2.26[500] to 10.1.1.10[500] (176 bytes)
Aug 10 17:31:53 03[MGR] checkin IKE_SA dc01[3]
Aug 10 17:31:53 03[MGR] checkin of IKE_SA successful
Aug 10 17:31:53 16[NET] sending packet: from 10.1.2.26[500] to 10.1.1.10[500]
Aug 10 17:32:17 07[MGR] checkout IKEv1 SA with SPIs bf2f04e4730454f7_i 0000000000000000_r
Aug 10 17:32:17 07[MGR] IKE_SA dc01[3] successfully checked out
Aug 10 17:32:17 07[IKE] sending retransmit 4 of request message ID 0, seq 1
Aug 10 17:32:17 07[NET] sending packet: from 10.1.2.26[500] to 10.1.1.10[500] (176 bytes)
Aug 10 17:32:17 07[MGR] checkin IKE_SA dc01[3]
Aug 10 17:32:17 07[MGR] checkin of IKE_SA successful
Aug 10 17:32:17 16[NET] sending packet: from 10.1.2.26[500] to 10.1.1.10[500]
Aug 10 17:32:59 07[MGR] checkout IKEv1 SA with SPIs bf2f04e4730454f7_i 0000000000000000_r
Aug 10 17:32:59 07[MGR] IKE_SA dc01[3] successfully checked out
Aug 10 17:32:59 07[IKE] sending retransmit 5 of request message ID 0, seq 1
Aug 10 17:32:59 07[NET] sending packet: from 10.1.2.26[500] to 10.1.1.10[500] (176 bytes)
Aug 10 17:32:59 07[MGR] checkin IKE_SA dc01[3]
Aug 10 17:32:59 07[MGR] checkin of IKE_SA successful


Даже не знаю, куда дальше копнуть.

UPD: отключил checksum offload, чтобы это не смущало. дамп трафика обновил на дамп после отключения оффлоада. Никаких изменений нет.

SOLVED. Как показало курение документации, в strongswan теперь есть две схемы настройки -- старая, через ipsec.conf, и новая -- через swanctl.conf. Так вот старая, похоже, в центоси сломана. Я с помощью гугла и такой-то матери перенёс конфиг в swanctl.conf, и оно заработало сразу. Вот пример конфига, кому интересно:

connections {
    dc01 {
        version = 1
        local_addrs = 10.1.2.26
        remote_addrs = 10.1.1.10
        aggressive = no
        unique = no
        proposals = 3des-sha1-modp2048
        reauth_time = 30m
        local {
            auth = psk
            id = 10.1.2.26
        }
        remote {
            auth = psk
            id = 10.1.1.10
        }
        children {
            dc01 {
                mode = transport
                esp_proposals = aes128-sha1
            }
        }
    }
}
secrets {
    ike02 {
        id = 10.1.1.10
        secret = $uperP@$$
    }
}

http://ru-root.livejournal.com/2896625.html


Микротик

Вторник, 08 Августа 2017 г. 13:38 + в цитатник
Стоит Микротик 951Ui-2HnD, раздает инет, в конфиге ничего особенного нет все в общем-то стандартно, с год работало все без проблем, конфиг не менялся - микротик начал выпадать из сети, когда на 20 секунд, когда на пару минут, затем сам возвращается. Может целый день нормально работать, может 3-5 раз в день отваливаться. (отваливания бывают в том числе и ночью когда никто не работает и большая часть сети выключена) В это время соответственно не работает инет, сетка - работает.

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

Все оборудование подключено через ИБП, в серверной не жарко.

Микротику пробовал обновить RoS до 6,40 - не помогло, откатывал конфиг на сохраненный в начале года то же самое. Когда Микротик делает вид что не в сети и не пингуется по айпи, винбокс на него легко заходит по маку, в логах микротика - никакого криминала нет.

Куда можно глядеть?
Если нужна доп. инфа - напишите что, предоставлю. Спасибо за ответы.

По ссылке файл из wireshark во время когда микротик(192.168.1.100) перестает пинговаться с 192.168.1.200

UPD: Всем большое спасибо за помощь, проблема похоже решена дело оказалось в Микротиковской Neighbors, выключил ее на большинстве интерфейсов - разрывы стали меньшими по времени и более редкими, отрубил на всех интерфейсах - пропали вовсе. Почти сутки ни единого разрыва)) если пост больше не обновится значит проблема решена.

https://ru-root.livejournal.com/2896338.html


Микротик

Вторник, 08 Августа 2017 г. 13:38 + в цитатник
Стоит Микротик 951Ui-2HnD, раздает инет, в конфиге ничего особенного нет все в общем-то стандартно, с год работало все без проблем, конфиг не менялся - микротик начал выпадать из сети, когда на 20 секунд, когда на пару минут, затем сам возвращается. Может целый день нормально работать, может 3-5 раз в день отваливаться. (отваливания бывают в том числе и ночью когда никто не работает и большая часть сети выключена) В это время соответственно не работает инет, сетка - работает.

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

Все оборудование подключено через ИБП, в серверной не жарко.

Микротику пробовал обновить RoS до 6,40 - не помогло, откатывал конфиг на сохраненный в начале года то же самое. Когда Микротик делает вид что не в сети и не пингуется по айпи, винбокс на него легко заходит по маку, в логах микротика - никакого криминала нет.

Куда можно глядеть?
Если нужна доп. инфа - напишите что, предоставлю. Спасибо за ответы.

По ссылке файл из wireshark во время когда микротик(192.168.1.100) перестает пинговаться с 192.168.1.200

http://ru-root.livejournal.com/2896338.html


Solved: Как заглянуть в VPN?

Вторник, 08 Августа 2017 г. 13:18 + в цитатник
Имеется IPsec'овый VPN. С моей стороны на pfsense, с другой - не знаю. С обеих сторон хосты, которые должны соединяться через этот VPN, используют приватные IP, а в VPN'е они NAT'ятся в публичные, которые и указаны во 2 фазе IPsec.

С моей стороны через этот VPN успешно работают и ping, и traceroute, и TCP-соединения.
А вот с той стороны почему-то ничего не работает. При этом оттуда какие-то пакеты вроде как приходят: на WAN-интерфейсе в pfsense виднеются входящие ESP-пакеты, но в enc0 (это в pfsense виртуальный интерфейс, в котором можно следить за пакетами, передаваемыми через VPNы) ничего не видно. То есть, те приходящие пакеты почему-то не расшифровываются. Pfsens'овым firewall'ом они с тамошних IP-адресов однозначно разрешены.

Вопрос: куда можно посмотреть, чтоб понять, отчего такое происходит, и как его исправить?
В ipsec.log и filter.log про это ничего не видно.

Upd:
Гм.. запустивши tcpdump на enc0 с указанием приватных адресов, таки удалось увидеть там все приходящие пакеты в расшифрованном виде.
И тут обнаружилось, что они приходят с приватных адресов, не будучи преобразованными в публичные. Потому они и игнорировались pfsense'ом.
Сервер на той стороне оказался Juniper SRX, но вот как он умудряется посылать в VPN-туннель пакеты с адресов, которые вовсе не входят в security domain - ваще не понимаю :(

https://ru-root.livejournal.com/2895958.html


Метки:  

призрачный tcp estab

Пятница, 28 Июля 2017 г. 11:11 + в цитатник
Всех с праздником!

В этот святой день обнаружился странный глюк, который я пытаюсь понять.

есть сервер1, на нем запущен процесс, который обращается по хттп к серверу2. И вот этот процесс висит уже дней 5+ и ничего оттуда не получает..но и не завершается

Смотрим на процесс на сервере1:

server1# strace -ff -p 3647
Process 3647 attached
restart_syscall(<... resuming interrupted call ...>) = 0
poll([{fd=4, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 0) = 0 (Timeout)
poll([{fd=4, events=POLLIN}], 1, 1000) = 0 (Timeout)
poll([{fd=4, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 0) = 0 (Timeout)
poll([{fd=4, events=POLLIN}], 1, 1000) = 0 (Timeout)
poll([{fd=4, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 1, 0) = 0 (Timeout)
poll([{fd=4, events=POLLIN}], 1, 1000) = 0 (Timeout)

Читать он пытается из сокета:

server1# lsof -p 3647
process 3647 root 4u IPv4 3524382088 0t0 TCP server1.com:42468->server2.com:http (ESTABLISHED)

Который создан дней так 10 назад:

server1# ls -la /proc/3647/fd
total 0
dr-x------ 2 root root 0 Jul 18 10:39 .
dr-xr-xr-x 9 root root 0 Jul 3 11:34 ..
lr-x------ 1 root root 64 Jul 18 10:39 0 -> pipe:[3524326282]
l-wx------ 1 root root 64 Jul 18 10:39 1 -> pipe:[3524326283]
l-wx------ 1 root root 64 Jul 18 10:39 2 -> pipe:[3524326283]
lrwx------ 1 root root 64 Jul 18 10:39 3 -> socket:[3524337348]
lrwx------ 1 root root 64 Jul 18 10:39 4 -> socket:[3524382088]

Соединение установлено
server1# ss |grep 42468
tcp ESTAB 0 0 server1:42468 server2:http

И все бы ничего..но сервер2 так не думает..

server2 # ss |grep 42468
server2 #

При завершении процесса на server1 он как положено, шлет FIN+ACK на server2, а тот в изумлении шлет обратно RST, т.к. ничего не знает об этом соединении.

Повторить описанный глюк ручным запуском не удается.

Возникают вопросы:
- что это может быть за глюк ?
- почему соединение не прибивается по таймауту ? (keepaliv'ы должны слаться каждые 2 часа:
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_time = 7200, но я их не наблюдаю в tcpdump'е)


P.S. firewall не используется, conntrack не используется, sysctl стандартный, на обоих серверах белые ip, server1 - 3.10.0-514.16.1.el7.x86_64, server2 - 2.6.32-696.el6.x86_64

https://ru-root.livejournal.com/2895678.html


Метки:  

Поиск сообщений в lj_ru_root
Страницы: 48 ... 42 41 [40] 39 38 ..
.. 1 Календарь