Windows 11: Попытка L2TP-подключения не удалась из-за ошибки, произошедшей на уровне безопасности во время согласований с удаленным компьютером

У одного из L2TP-клиентов сервера VPN, поднятого на Mikrotik, неожиданно перестало устанавливаться соединение, выдавая ошибку: Попытка L2TP-подключения не удалась из-за ошибки, произошедшей на уровне безопасности во время согласований с удаленным компьютером.
На стороне Микротика, в журнале присутствуют записи:
no suitable proposal found.
188.xxx.235.5 failed to get valid proposal.
188.xxx.235.5 failed to pre-process ph1 packet (side: 1, status 1).
188.xxx.235.5 phase1 negotiation failed.

Проблема заключается в том, что стороны не могут согласовать алгоритм шифрования. По какой причине Windows перестал нравится прежний набор алгоритмов неизвестно. Но теперь, ОС требуется обязательного наличия алгоритма aes-256. Данный алгоритм нужно задействовать в настройках Микротика: раздел IPIPsec → вкладка Profiles → профиль по умолчанию default → блок Encryption Algorithm.

Микротик — Туннель IPsec не пропускает трафик

Имеется проблема при настройке IPsec туннеля на маршрутизаторе Mikrotik: туннель поднимается, пакеты из удаленной сети приходят и даже возвращаются ICMP ответы, однако, из сети со стороны Микротика, пакеты предназначенные в удалённую сеть, в туннель не перенаправляются.
Для начала следует понять пропускает ли Микротик вообще эти пакеты, и если да, то куда перенаправляет. Если их не блокирует фаервол, то скорее всего они уходят в интернет, через шлюз по умолчанию. Проверить это можно встроенной программой сниффера: ToolsPacket Sniffer.
Если пакеты уходят в интернет, то скорее всего обрабатываются правилом по умолчанию (маскарада). Соответственно, нужно перед ним добавить правило, исключающее обработку пакетов, предназначенных для IPsec туннеля:

  • переходим во вкладку IPFirewallNAT;
  • добавляем правило Chain: srcnat;
  • указываем Src. Address сети за Микротиком и Dst. Address удаленной сети;
  • указываем Action: Accept и нажимаем кнопку Ok;
  • перетягиваем созданное правило на самый верх, чтобы оно было с номером 0.

https://superuserdo.info/?p=928

bxSiteFiles::bx_dbconn: Cannot open dbconn.php

Не выполняется создание резервной копии по расписанию. При попытке запустить сценарий bx_backup.sh вручную отображается ошибка:

bxSiteFiles::bx_dbconn: Cannot open /home/bitrix/site.ru/bitrix/php_interface/dbconn.php: Permission denied at /opt/webdir/lib/bxSiteFiles.pm line 273

Данный сайт был создан через меню управления окружением, запущенным от имени root. Поэтому владельцем директории с ядром Битрикса стал root. Исправить это можно сменив владельца директории на bitrix командой:

chown -R bitrix:bitrix /home/bitrix/site.ru

BitrixVM — не работает почта

В журнале msmtp_site.ru.log присутствуют записи вида:
msmtp: cannot connect to 127.0.0.1, port 25: Connection refused
msmtp: could not send mail (account default from /etc/msmtprc)

Скорее всего в этом случает не установлен почтовый агент (MTA), проверить это можно командой:

echo -e «test message» | /usr/bin/msmtp —debug -t -i admin@mail.ru

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

yum install sendmail
systemctl start sendmail.service

После чего добавить в автозагрузку:

systemctl enable sendmail.service

Proxmox и ZFS — значительное потребление памяти

При использовании ProxmoxVE с ZFS, при работе виртуальных машин, память на хосте постепенно расходуется до полного исчерпания, результатом чего может стать выключение виртуальных машин:

kernel: [1123659.062155] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/qemu.slice/104.scope,task=kvm,pid=1045923,uid=0
kernel: [1123659.062203] Out of memory: Killed process 1045923 (kvm) total-vm:10639204kB, anon-rss:8332420kB, file-rss:2320kB, shmem-rss:4kB, UID:0 pgtables:17172kB oom_score_adj:0
kernel: [1123660.010306] oom_reaper: reaped process 1045923 (kvm), now anon-rss:0kB, file-rss:68kB, shmem-rss:4kB
systemd1: 104.scope: A process of this unit has been killed by the OOM killer.

Следует понимать, что ZFS требовательна к памяти сервера и по умолчанию использует 50% установленной памяти для ARC (Adaptive Replacement Cache). Текущие минимальные и максимальные пределы можно посмотреть командой:

cat /proc/spl/kstat/zfs/arcstats

где c_min и c_max являются таковыми.

Изменить используемые в настоящее время лимиты можно, установив значения в байтах в файлах /sys/module/zfs/parameters/zfs_arc_min и /sys/module/zfs/parameters/zfs_arc_max соответственно, например командой:

echo «$[10 * 1024*1024*1024]» >/sys/module/zfs/parameters/zfs_arc_max

где 10 — максимальный предел выделяемой памяти в ГБ.

Чтобы изменить максимальный предел ARC навсегда, необходимо добавить в файл /etc/modprobe.d/zfs.conf опцию:

options zfs zfs_arc_max=8589934592

где 8589934592 — устанавливаемый предел в 8 ГБ ОЗУ.

Если корневая файловая система также на ZFS, то после изменения лимитов, необходимо обновить образ initramfs:

update-initramfs -u

После чего требуется перезагрузить сервер.

Proxmox: no device with valid iso found

При попытке установки ProxmoxVE с USB-флэшки, отображается ошибка: no device with valid iso found, please check your intallation medium.
Проблему решает запись флэшки программой Rufus в режиме DD-образа.

Битрикс: Работа с сокетами — Ошибка! Не работает

При использовании BitrixEnv внутри виртуальной среды, с выходом в интернет через NAT (IP-адрес сетевого интерфейса машины с Битриксом отличается от IP в A-записи домена сайта), со стандартными настройками Битрикса, проверка системы будет выдавать ошибку: Работа с сокетами (check_socket): Fail
Для устранения проблемы, в файле /etc/hosts необходимо добавить доменное имя сайта адресу внутренней петли (чтобы сценарий проверки сайта пытался проверить сокет не на шлюзе, а на локальном хосте), по типу:

127.0.0.1 localhost.localdomain localhost site.ru

failed to execute mkfs.vfat: no such file or directory

При попытке форматирования съёмного flash диска (флэшки) командой «mkfs -t vfat 32 -F /dev/sdc1″, отображается ошибка: failed to execute mkfs.vfat: no such file or directory.
В этом случае необходимо установить в систему пакет dosfstools.

Yum: Peer cert cannot be verified or peer cert invalid

При попытке обновления корневых сертификатов в устаревшем CentOS 6.8, пакетный менеджер не может скачать из репозиториев пакеты, выдавая ошибки:
http://vault.centos.org/6.10/updates/x86_64/Packages/ca-certificates-2020.2.41-65.1.el6_10.noarch.rpm: [Errno 14] Peer cert cannot be verified or peer cert invalid
failure: Packages/ca-certificates-2020.2.41-65.1.el6_10.noarch.rpm from C6.10-updates: [Errno 256] No more mirrors to try.

В этом случае пакет можно скачать и установить вручную командами:

wget https://vault.centos.org/6.10/updates/x86_64/Packages/ca-certificates-2020.2.41-65.1.el6_10.noarch.rpm —no-check-certificate
rpm -iU ca-certificates-2020.2.41-65.1.el6_10.noarch.rpm

Mikrotik: failed to pre-process ph2 packet

При попытке установить второй IPsec туннель с маршрутизатора Микротик с прошивкой 6.42.1 до PfSense с прошивкой 2.4.4, не устанавливается соединение на второй фазе. При этом в журнале Микротка появляются записи: failed to pre-process ph2 packet. В записях журнала PfSense может быть: received ATTRIBUTES_NOT_SUPPORTED error notify.

Проблема устранена после выполнения двух условий:

  1. обновления прошивки Микротика до версии 6.47.1;
  2. отключения в PfSense опции Responder Only.