Неинформативные сообщения strongswan

Потребовалось подключиться по IPSec к новому межсетевому экрану. Решил попробовать strongswan, так как openswan отсутствует в репозитариях debian jessie. Выжимка из того, на чём удалось навернуться.
Основной конфиг /etc/ipsec.conf, общий ключ в /ets/ipsec.secrets. Для применения изменений необходимо выполнить sudo ipsec reload. Но данная команда не отображает никакой информации об ошибках/опечатках в конфигурационном файле в отличие от sudo ipsec restart. Другие команды можно посмотреть здесь.
Для подключения-отключения необходимо выполнить: sudo ipsec up|down <connection name>.
После ее вызова выводится лог подключения.
Пока не указал в явном виде использовать IKE v1 (keyexchange=ikev1) удаленная сторона просто молчала, strongswan повторял попытки установления соединения.
Также потребовалось явно указать список протоколов шифрования для IKE (ike=aes128-sha1-modp1536,aes128-md5-modp1536,3des-md5-modp1024,aes128-sha1-modp1024,aes256-sha-modp1024,3des-md5-modp1024). До этого момента соединение обрывалось на первом шаге с ошибкой NO_PROPOSAL_CHOSEN.
Далее я получил ошибку no shared key found. В конфигурационном файле для подключения должны присутствовать опции left=%any и right=1.2.3.4, соответствующие адресам узлов, участвующих в ассоциации. Опции leftid и rightid в моем случае необязательны, я их не указывал. В файле /etc/ipsec.secrets общий ключ должен быть записан в виде:

%any 1.2.3.4 : PSK "sTrong$ecret"

Слева направо: адреса участников ассоциации, двоеточие (отделенное пробелами), тип записи PSK (общий ключ), собственно, ключ обязательно в кавычках. Без кавычек ключ, кажется, в base64. Подробнее тут.
Далее я снова получил ошибку NO_PROPOSAL_CHOSEN, но уже во второй фазе IKE - Quick Mode. Казалось бы, стороны снова не могут согласовать алгоритмы шифрования, но нет. Помог блог какого-то замечательного человека. Спасибо тебе, огромное!) Оказалось, что нужно указать корректную, с точки зрения межсетевого экрана, rightsubnet=1.2.3.4/32, вместо rightsubnet=0.0.0.0/0, указывающую только на сам межсетевой экран. После чего всё благополучно взлетело, а я пошел ковыряться дальше.
Примерный файл конфигурации:

conn vpn
# Режим работы IPSec - транспортный (туннельный и т.д.)
type=transport
# Алгориты шифрования/аутентификации
ike=aes128-sha1-modp1536,aes128-md5-modp1536,3des-md5-modp1024,aes128-sha1-modp1024,aes256-sha-modp1024,3des-md5-modp1024
ikelifetime=86400s
lifetime=3600s
# Версия протокола IKE v1
keyexchange=ikev1
rekey=yes
forceencaps=yes
# Режим запуска - в момент обращения к защищаемому узлу
auto=route
# Left
# Адрес с интерфейса, через который идет маршрут по-умолчанию
left=%any
# Добавлть разрешающие правила в локальный межсетевой экран
# leftfirewall=yes
# Right
# Адрес узла, с которым необходимо соединиться
right=1.2.3.4
# Подсеть за узлом, которая будет защищаться соединением, фильтр протокола и порт
rightsubnet=1.2.3.4/32[udp/1701]

 Для настройки L2TP поверх IPSec с помощью демона xl2tpd хорошо подходит инструкция от поклонников Арча.
PS. После обновления strongSwan до 5.4 благополучно работавшее соединение снова отказалось подключаться с той же ошибкой NO_PROPOSAL_CHOSEN. Благодаря этому посту и описанию параметра esp = в официальной документации было выяснено, что в 5.4 был изменен алгоритм шифрования по умолчанию:

esp = <cipher suites>

...

Defaults to aes128-sha256 (aes128-sha1,3des-sha1 before 5.4.0). 

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

Настройка Chromium для использования SPNEGO

Даже скорее не так. Информации на просторах интернета о том, какой параметр - AuthServerWhitelist - за это отвечает - воз и маленькая телега. Официальная документация: https://dev.chromium.org/administrators/policy-list-3#AuthServerWhitelist. В основном на тех самых просторах, правда, предлагают его тулить по старинке флагами при запуске браузера. Но есть отсылки и к политикам. И вот тут закопалась главная свинья - я не умею читать. В инструкции по политикам сказано чёрным по белому:

Set Up Policies

Policy configuration files live under /etc/chromium for Chromium, and under /etc/opt/chrome for Google Chrome.

А я долго и упорно пытался их положить в /etc/opt/chromium и т.д. Для SPNEGO конфигурационный файл должен выглядеть так:

cat /etc/chromium/policies/managed/example-corp.json  

{ "AuthServerWhitelist": "*.domain.local",

"AuthNegotiateDelegateWhitelist": "*.domain.local" }

Второй параметр нужен для указания доменов, для которых включено делегирование учетных данных. В том, что всё успешно применилось можно убедиться открыв chrome://policy/.

Контроллер домена не берёт время с сервера точного времени

На команду

w32tm /resync

отвечает "Синхронизация не выполнена, поскольку нет доступных данных о времени."
Команда

w32tm /monitor

кажет, примерно, следующее:
DC1.domain.local *** PDC ***[[::1]:123]: 
    ICMP: 0ms задержка 
    NTP: +0.0000000s смещение относительно DC1.domain.local 
        RefID: 'LOCL' [0x4C434F4C] 
        Страта: 1 

Т.е. время берётся с локальных часов, сервер присвоил себе страту 1. Хотя тут есть один ньюанс)) Никсовые машины с такого сервера время брать отказываются. То ли в силу того, что источник LOCL, то ли страта отображается как 1, а на деле 16. Ответ нашелся здесь. В групповую политику по умолчанию внесли Включить NTP-клиент Windows. И она применилась к контроллеру домена. Ключи реестра из Policies переопределили стандартные и сервер пытался брать время сам с себя, после чего уходил в себя брать время со своих часов.

Исключить из одного файла строки, присутствующие в другом файле

Всё, как обычно, оказалось тривиально. Прямо как говорила наш преподаватель по мат. анализу=) У команды grep есть подходящий для этой задачи набор флагов:

grep -v -x -f except.txt source.txt, где

• -v  отобрать не совпавшие с шаблоном строки
• -x сравнивать строку целиком
• -f except.txt файл с набором шаблонов для поиска, разделенных переносом строки
• source.txt - исходный файл для поиска и исключения вхождений из файла except.txt (естественно, его можно заменить на подачу через пайп)

 

CIFS с kerberos-авториацией

Решил окучить вопрос подключения windows-шар с использованием билета kerberos. Небезопасно как-то хранить plain-текстом доменные учётные данные, а вводить каждый раз ручками - не наш метод. В принципе, оказалось, что всё, что надо, есть из коробки. Потребуются пакеты:

sudo apt-get update 

sudo apt-get install krb5-user cifs-utils keyutils

 При грамотно настроенном DNS настройка kerberos-клиента сводится к указанию REALM домена windows по-умолчанию (рекомендуется указывать в верхнем регистре, например EXAMPLE.COM), который будет запрошен при установке и может быть изменен в /etc/krb5.conf. Если всё правильно, то с получением билет не должно возникнуть проблем:

kinit vasiliy
Password for vasiliy@EXAMPLE.COM:
klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: vasiliy@EXAMPLE.COM
Valid starting       Expires              Service principal
22.06.2015 21:28:02  23.06.2015 07:28:02  krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until 23.06.2015 21:27:57

Вывод команды klist отобразит информацию о полученном билете. Чтобы монтировать сетевую шару без необходимости прав root внесем в /etc/fstab следующую строку:

//host.example.com/development /home/vasiliy/Dev cifs rw,user,noauto,sec=krb5,username=vasiliy,domain=EXAMPLE.COM 0 0

Точку монтирования /home/vasiliy/Dev, естественно, надо создать. Также хочу указать на необходимость указания  настроек подключения cifs именно в fstab - с командой строки они браться не будут. Если не указывать username и domain, то будут использоваться из хранилища ключей (?). Т.е. строку можно будет использовать любому пользователю станции. Монтируем и отмонтируем командами, соответственно:

mount /home/vasiliy/Dev
umount /home/vasiliy/Dev

ЗЫ. Ошибка вида:

mount error(128): Key has been revoked 

Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) 

решается полным завершением сеанса оболочки и повторным логином. Такое ощущение, что mount не может найти, где лежит keytab... Нужно проверять.

О дырявых роутерах...

Звонит мне, значится, сегодня друг и говорит.

Что-то с Контактом какая-то фигня. Работает-работает, бах, сваливается на страницу авторизации. А на этой странице кроме кнопки войти всё остальное не работает и выдаёт ошибку. Вчера весь день комп на предмет вирусной дряни шмонал - ничего. А сегодня заметил, что и телефон при работе через wi-fi вытворяет то же самое. Сейчас подключил напрямую Интернет без роутера - вроде бы всё нормально. Может быть проблема в роутере?

Ну тут мне вспомнился давешний пост на OpenNet. Роутер Asus RT-N10R. Попросил сделать вывод nslookup:

Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Users\User>nslookup vk.com Server: UnKnown Address: 178.208.81.126 Name: vk.com Address: 178.208.81.126

А должно быть как-то так:

C:\Users\User>nslookup vk.com
Server: router.asus.com
Address: 192.168.1.1 

Non-authoritative answer:
Name: vk.com
Addresses: 2a00:bdc0:3:103:1:0:403:901
2a00:bdc0:3:103:1:0:403:902
2a00:bdc0:3:103:1:0:403:903
87.240.131.99
87.240.131.97
87.240.131.120

Т.е. роутер отдавал клиентам сети в качестве dns-сервера 178.208.81.126 - адрес злоумышленника. При обращении к этому адресу 178.208.81.126 вылезла страничка "типа, одноклассников". В коде страницы честно присутствует:

<!DOCTYPE html>

<!-- saved from url=(0013)http://ok.ru/ -->

<html class=" an

Если запросить vk.com - вылезет страничка входа Контактика. Сброс роутера проблему временно решил. Обновили до последней прошивки. При возможности дополню.
PS. Будьте внимательны, используйте двухфакторную аутентификацию.
PS2. Аналогичный случай

squid3 и неожиданно помирающая доменная авторизация

Однажды в понедельник неожиданно умерла корпоративная прокси на squid. У пользователей она съезжала на basic авторизацию, вместо доменной. В cache.log на каждый запрос сыпалось:

authenticateNegotiateHandleReply: Error validating user via Negotiate. Error returned 'BH gss_acquire_cred() failed: Unspecified GSS failure.  Minor code may provide more information. '

 Что сбило с толку, так это то, что перезапуск сервиса на какое-то время решал проблему. Минут на 10-15. И потом всё повторялось снова и снова. В какой-то момент sudoedit руганулся на недостаток памяти, хотя df -h радовал свободным пространством. Тут-то коллега и нашёл ЭТО. У нас исчерпались inodЫ. Вывод df -i это подтвердил. И причина была та же самая. SARG, который бесконтрольно плодил свои отчёты каждый день, неделю и месяц. Найти врага можно командой:

for i in /*; do echo $i; find $i | wc -l; done

 которая покажет, в каком каталоге больше всего израсходовано inodes. Файлов было не такое количество, чтобы возникли проблемы с их удалением.