xl2tpd после подключения наглухо вешает систему

Вот так вот внезапно. Жили, не тужили, пользовались VPNкой, а тут здравствуйте: подключаемся, секунд 15 и полное зависание системы без сообщений о ошибках. За это время я успевал по привычке открыть remmina и попытаться подключиться. А так как собирал я ее из исходников, первой под горячую руку напрасно попала именно она - мол, что-то после обновлений сломалось. Почесав за ухом и убедившись, что все валится именно после поднятия подключения L2TP, а не ipsec задумался. Было бы еще над чем. В логах было пусто. Решил попробовать подключиться из консоли без Иксов. Что-то повалилось. Что-то содержало сообщение:

BUG: soft lockup - CPU#1 stuck for 23s! [pppd:<PID>]

Отсюда гуглится ВОТ ЭТО. Опять Арчеводы)) Оказывается, линь убивается выстрелом петлей в таблице маршрутизации. Поднялась ipsec-ассоциация до узла 1.2.3.4, поднялся l2tp-тунель до 1.2.3.4, создался маршрут до 1.2.3.4 через ppp0. Пакеты, идущие в тонель, после инкапсуляции заворачивались ядром в ipsec, а его пакеты, желая попасть на 1.2.3.4 попадали опять в тунель. Тут-то и капец ужику.
Решается убиением в скрипте ip-up маршрута до шлюза через ppp0 после установления соединения.
Пока для меня остался вопрос, что именно поменялось после обновления. Начал добавляться этот маршрут, которого раньше не было, что как-то сомнительно. Также сомнительно, что пакеты ipsec при наличии такого маршрута до этого его игнорировали, а тут начали учитывать. Хотя, помнится, я настраивал где-то strongSwan на игнор интерфейса ppp0, но к маршрутизации в Линукс это вряд ли имеет отношение. Так что, откуда-то всплыл этот бессмысленный маршрут, похоже...

Неинформативные сообщения 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 (естественно, его можно заменить на подачу через пайп)