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.

Postfix: milter-reject: END-OF-MESSAGE

В журнале почтового сервера замечены ошибки:
opendkim[15714]: can’t load key from /etc/opendkim/keys/yoursite.ru.private: Permission denied
opendkim[15714]: 853812117BFD: error loading key ‘mail._domainkey.yoursite.ru’
postfix/cleanup[11933]: 853812117BFD: milter-reject: END-OF-MESSAGE from localhost[127.0.0.1]: 4.7.1 Service unavailable — try again later; from= to= proto=ESMTP helo=

Ошибка связана с доступом OpenDKIM к файлу ключа: по умолчанию владелец ключа пользователь root. Для решения проблемы необходимо сменить владельца ключа командой:

sudo chown opendkim:mail /etc/opendkim/keys/selector.private

где selector.private — имя вашего файла ключа.

Также возможно появление ошибок вида:
opendkim[25573]: mail._domainkey.yoursite.ru: key data is not secure: /etc/opendkim/keys/yoursite.ru.private is in group 12 which has multiple users (e.g. «mail»)
opendkim[25573]: B00D22114B3E: error loading key ‘mail._domainkey.yoursite.ru’
postfix/cleanup[28212]: B00D22114B3E: milter-reject: END-OF-MESSAGE from localhost[127.0.0.1]: 4.7.1 Service unavailable — try again later; from= to= proto=ESMTP helo=

В это случае, с файла ключа необходимо убрать доступ для группы владельца файла:

sudo chmod 600 /etc/opendkim/keys/selector.private

где selector.private — имя вашего файла ключа.

connect to Milter service opendkim.sock: Permission denied

В журнале почтового сервера замечена ошибка: postfix/smtpd9137: warning: connect to Milter service unix:/var/run/opendkim/opendkim.sock: Permission denied

Для начала необходимо проверить, запущен ли демон OpenDKIM командой:

ls -l /var/run/opendkim

(путь может быть иным, он задаётся в файле /etc/opendkim.conf).
Если сокет отсутствует, необходимо попытаться запустить демона вручную:

service opendkim start

Если же сокет присутствует, то необходимо проверить наличие прав у почтового сервера для доступа к нему. И, в случае отсутствия оных, выдать их: либо изменив UMask в файле /etc/opendkim.conf, либо добавив пользователя, от имени которого работает почтовый сервер, в группу opendkim.
Возможно также, что почтовый сервер запущен с изменённым корневым каталогом (chroot), тогда в файле /etc/opendkim.conf необходимо изменить путь для сокета, указав директорию, доступную почтовому серверу.

Правильная перепрошивка маршрутизаторов Mikrotik

  1. Скачиваем программу Netinstall и нужную прошивку (npk файл) для вашего маршрутизатора, а также, по необходимости, дополнительные пакеты и Winbox последней версии с сайта http://www.mikrotik.com/download
  2. В корне диска «С:/» создаём папку «Netinstall», копируем и распаковываем в неё всё, что было скачано, чтобы всё оказалось в одной папке, без вложений.
  3. На компьютере, в настройках сетевого интерфейса, выставляем статический IP-адрес, например ‘192.168.100.100’ с маской ‘255.255.255.0’, все остальные поля оставляем пустыми.
  4. Подключаем компьютер к первому (или последнему для моделей серии RB1xxx или CCR) порту маршрутизатора.
  5. Запускаем программу Netinstall от имени администратора, нажимаем на кнопку Net booting, ставим галочку Boot server enabled и прописываем Client IP address из подсети указанной в пункте 3, например ‘192.168.100.101’ и нажимаем OK.
  6. Зажимаем кнопку Reset на маршрутизаторе и подключаем питание. Ждём пока лампочка заморгает и потом погаснет. Отпускаем кнопку Reset и смотрим в окно программы Netinstall. Через несколько секунд должно появиться новое устройство.
  7. Нажимаем на устройство в списке, выбираем какие пакеты нужно установить, отмечая их галочками, затем нажимаем кнопку Install. Дожидаемся окончания процесса, и если появится надпись Waiting reboot, то нажимаем на кнопку Reboot.
  8. После того, как маршрутизатор загрузится, о чём свидетельствует двойной звуковой сигнал (если конечно у маршрутизатора есть, чем его издавать), запускаем программу Winbox, находим там наше устройство и подключаемся, используя логин «admin» без пароля.
  9. Заходим в раздел SystemRouterboard и нажимаем кнопку Upgrade, затем заходим в раздел SystemPackage и отключаем все ненужные пакеты (обычному пользователю для полноценной работы достаточно только следующие пакеты: advanced-tools, dhcp, ppp, security, system, wireless), после чего заходим в SystemReboot и соглашаемся на перезагрузку.
  10. После перезагрузки снова подключаемся к маршрутизатору. Заходим в раздел SystemReset Configuration, отмечаем галочки No Default Configuration и Do Not Backup и нажимаем Reset Configuration.
  11. После перезагрузки снова подключаемся к маршрутизатору и начинаем процедуру его настройки. По окончанию настройки в обязательном порядке выполнить перезагрузку: SystemReboot

Mikrotik: router does not support secure connection

При подключении к маршрутизатору Микротик с прошивкой младше версии 6.43, может отобразиться ошибка: router does not support secure connection, please enable Legacy Mode if you want to connect anyway.
В программе Winbox старше версии 3.22 имеется возможность включения устаревшего режима, для подключения к маршрутизатору незащищенным методом. Для включения этого режима, на вкладке Tools программы Winbox, выберите Legacy mode.

NginX — установка бесплатных SSL-сертификатов для нескольких сайтов

  1. Создаем пользователя letsencrypt и необходимые директории:

  2. adduser —home /var/www/challenges \
    —shell /bin/sh \
    —disabled-password \
    —disabled-login \
    letsencrypt
    mkdir -p /etc/letsencrypt/domains

  3. Создаём основные приватные ключи:

  4. cd /etc/letsencrypt/
    openssl dhparam -out dhparam.pem 2048
    openssl genrsa 4096 > account.key

  5. Скачиваем клиент acme_tiny.py:

  6. cd /var/www/challenges
    wget https://raw.githubusercontent.com/diafygi/acme-tiny/master/acme_tiny.py

  7. Создаем сценарий /var/www/challenges/acme-tiny.sh, для автоматизации. Изменив значение переменной DOMAINS, указываем имена доменов, для которых необходимо получить сертификаты:
  8. DOMAINS=( site1.ru site2.com )
    DOMAIN_ROOT=/etc/letsencrypt/domains
    ACCOUNT_KEY=/etc/letsencrypt/account.key
    ACME_DIR=/var/www/challenges
    ACME_TINY=${ACME_DIR}/acme_tiny.py
    
    [ -d ${DOMAIN_ROOT} ] || { echo "ERROR: DOMAIN_ROOT dir does not exists"; exit 1; }
    [ -f ${ACCOUNT_KEY} ] || { echo "ERROR: ACCOUNT_KEY not found."; exit 1; }
    [ -d ${ACME_DIR} ] || { echo "ERROR: ACME_DIR dir does not exists"; exit 1; }
    [ -f "$ACME_TINY" ] || { echo "ERROR: ACME_TINY not found."; exit 1; }
    
    wget -O - https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.pem > ${DOMAIN_ROOT}/intermediate.pem
    
    for DOMAIN in "${DOMAINS[@]}"
    do
      if [ ! -f "${DOMAIN_ROOT}/${DOMAIN}.key" ]; then
        echo "INFO: Generation private key for $DOMAIN";
        openssl genrsa 4096 > ${DOMAIN_ROOT}/${DOMAIN}.key
        openssl req -new -sha256 -key ${DOMAIN_ROOT}/${DOMAIN}.key -subj "/CN=${DOMAIN}" > ${DOMAIN_ROOT}/${DOMAIN}.csr
      fi
    
      echo "INFO: Generation cert for $DOMAIN";
      python ${ACME_TINY} --account-key ${ACCOUNT_KEY} --csr ${DOMAIN_ROOT}/${DOMAIN}.csr --acme-dir ${ACME_DIR} > ${DOMAIN_ROOT}/${DOMAIN}.crt || exit 1
      cat ${DOMAIN_ROOT}/${DOMAIN}.crt ${DOMAIN_ROOT}/intermediate.pem > ${DOMAIN_ROOT}/${DOMAIN}.pem
    done
    
    sudo service nginx reload
    
  9. Меняем права на директории:

  10. chmod 755 /etc/letsencrypt
    chown -R letsencrypt: /etc/letsencrypt /var/www/challenges

  11. Создаём файл /etc/nginx/acme:
  12. location ^~ /.well-known/acme-challenge/ {
        alias /var/www/challenges/;
        try_files $uri =404;
        allow all;
    }
    
  13. В конфигурационный файл nginx каждого сайта, в блок server, добавляем строку:

  14. include /etc/nginx/acme;

  15. Запускаем скрипт:

  16. /bin/bash /var/www/challenges/acme-tiny.sh

  17. Включаем шифрование, добавив в конфигурационные файлы nginx каждого сайта:
  18. server {
        server_name site1.ru www.site1.ru;
        listen 80;
    
        include acme;
        # включим переадресацию на https-версию сайта
        location / {
            return 301 https://$host$request_uri;
        }
    }
    
    server {
            server_name site1.ru www.site1.ru;
            listen 443 ssl;
    
            # включим шифрование
            ssl on;
            ssl_certificate /etc/letsencrypt/domains/alluborka.ru.pem;
            ssl_certificate_key /etc/letsencrypt/domains/alluborka.ru.key;
            ssl_dhparam /etc/letsencrypt/dhparam.pem;
    
            ssl_stapling on;
            ssl_stapling_verify on;
    
            # исключим возврат на http-версию сайта
            add_header Strict-Transport-Security "max-age=31536000";
    
            # явно "сломаем" все картинки с http://
            add_header Content-Security-Policy "img-src https: data:; upgrade-insecure-requests";
    
        ...
    }
    
  19. Для автоматического продления сертификатов, создадим файл /etc/cron.d/letsencrypt:
  20. SHELL=/bin/sh
    PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
    0 0 1 * * letsencrypt /bin/bash /var/www/challenges/acme-tiny.sh >> /var/log/acme_tiny.log
    
  21. Создадим файлы журналов:

  22. sudo touch /var/log/acme_tiny.log
    sudo chown letsencrypt: /var/log/acme_tiny.log

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

Mikrotik — проблемы с RDP

При попытке подключения из локальной сети к рабочему столу удалённого сервера, по VPN-туннелю между маршрутизатором Mikrotik и удалённым сервером, процесс подключения надолго зацикливается на двух этапах:
Настройка удалённого сеанса…
Защита удалённого подключения…

Данная проблема наблюдается при активном правиле fasttrack connection фильтра фаервола. Причём, даже, если это правило расположено в таблице ниже правил, касающихся маршрутизации VPN трафика. Отключение этого правила, способствует восстановлению правильной маршрутизации пакетов и установлению RDP-подключений.

HiveOS: CUDA Error : Insufficient CUDA driver 9010

После очередного обновления ОС Hive, майнер Ethermine не запускается, miner log содержит записи:
CUDA Error : Insufficient CUDA driver 9010
Error: No usable mining devices found

Такое случается, когда майнер требует наличия более свежей версии CUDA. Для её обновления, необходимо выполнить команду nvidia-driver-update на воркере. После чего перезапустить майнер.

SFTP — установка umask

Имеются пользователи, которые подключаются к системе только по SFTP и не имеют файла профиля оболочки. Требуется установить маску режима создания пользовательских файлов, непосредственно в конфигурационном файле sshd.

umask можно задать как для отдельного пользователя, так и для группы пользователей, для этого, достаточно в файле /etc/ssh/sshd_config указать директивы:

Match Group имя_группы
ForceCommand internal-sftp -u маска

где маска указывается в десятичной системе (например, маска «002» указывается как «2»)
При этом, должна быть задействована подсистема internal-sftp:

Subsystem sftp internal-sftp

PfSense: arpresolve: can’t allocate llinfo

При использовании PfSense в качестве маршрутизатора с несколькими IP-адресами, из разных подсетей, на одном интерфейсе, может возникнуть ситуация, когда пакеты с одного IP не отправляются, а в журнале отображаются ошибки: arpresolve: can’t allocate llinfo.
В этом случае необходимо убедиться, что у шлюза, используемого для данного IP, включена опция Use non-local gateway в расширенных настройках.