Strogswan и Let’sEncrypt тип сертификата

Переносил тут ikev2 на новую машину, решил не морочиться с переносом сертификатов, а выпустить серверу новый — благо Let’sEncrypt никаких ограничений, не накладывает.

Новые сертификаты выпускаются уже не RSA, а ECDSA, так что в ipsec.secrets необходимо поменять тип закрытого ключа сервера с RSA на ECDSA

Иначе ничего не заработает 🙂

И не забывайте, apparmor без настройки не даст стронгсвану прочитать сертификаты из каталогов Let’sEncrypt

Шпаргала, всякие настройки сервера с Debian 12

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

Поставить ufw и fail2ban

#apt install ufw fail2ban
#systemctl enable --now ufw
#ufw enable
#ufw allow ssh
#echo "backend = systemd" >> /etc/fail2ban/jail.d/defaults-debian.conf 
#systemctl enable --now fail2ban

Для впн-сервера разрешить routed-трафик в UFW по умолчанию (потом запретить обратно, и разрешить только нужное)

#vi /etc/default/ufw
edit
DEFAULT_FORWARD_POLICY="ACCEPT"

Перманентные статические маршруты

Настраиваются в /etc/network/interfaces

# Local network
allow-hotplug eth1
iface eth1 inet static
	address 192.168.0.100/24
	up /sbin/ip route add 192.168.1.0/24 via 192.168.0.1 dev eth1
	up /sbin/ip route add 192.168.2.0/24 via 192.168.0.1 dev eth1
	down /sbin/ip route delete 192.168.1.0/24 via 192.168.0.1 dev eth1
	down /sbin/ip route delete 192.168.2.0/24 via 192.168.0.1 dev eth1

Openconnect-vpn с AD-авторизацией в Debian 12

Отмазка: данная статья не предназначена для настройки впн с целью обхода санкций, только для подключения к офисной рабочей сети.

Исторически, мы использовали для подключения удалёнщиков OpenVPN — просто, удобно, надёжно, хотя и медленно. Когда начались всякие сложности. добавили ikev2 как резерв, и WG, в качестве site-to-site, между офисами.

Последнее время OpenVPN чаще не работает, чем работает, ikev2 — в принципе не работает через мобильные сети, да и стабильность соединение так себе. Как его не готовь, всё равно, обрывы соединения будут.
WG как способ подключения пользователей вообще не катит — никакой авторизации кроме ключей, маршрутизации нет как класс (а у нас сложная сетка в офисе) и т.д. и т.п. Ну и пользователя в одном месте не удалишь — всё остальное с доменной авторизацией работает.

В итоге, принял решение развернуть Openconnect — свободную реализацию Cisco SSL VPN.

Почему?

  • Есть клиенты подовсё 🙂 Если нет опенсёрсного клиента, есть cisco anyconnect
  • Это ssl-vpn, т.е., по сути — https, хрена заблокируешь.
  • Вполне приемлемая производительность. Нам так-то сильно много не надо, но пусть будет.
  • Авторизация в домене. Т.е. я заблокировал пользователя в одном месте, всё, он никуда не ходит.

Погнали ставить.

Отмазка два: в рамках данной статьи, только базовый функционал, тонкости и нюансы дальше

Дано: сервер, две сетевые карты: eth0 — внешняя, eth1 — локальная. Сервер не является основным шлюзом для локальной сети.
На сервере уже установлены и чуть-чуть настроены:
— ssh
— ufw (мы запретили всё лишнее, разрешили https и routed-трафик)
— fail2ban (чтобы к нам в ssh не ломились сомнительные личности)
— в /etc/network/interfaces добавлены статические маршруты к подсетям ЦО и филиалов, или настроена любимая динамическая маршрутизация.
— уже установлен мой любимый vim
— в качестве серверов dns используются серверы, обслуживающие локальный домен

Будем делать openconnect с сертификатом Let’Encrypt, доменной авторизацией

Ставим пакеты

# apt install -y ocserv realmd sssd oddjob oddjob-mkhomedir adcli samba-common krb5-user sssd-tools libnss-sss libpam-sss certbot

Обретаем сертификат

Добавляем в публичный DNS запись вида vpn.mydomain.ru A %IP-адрес-сервера-VPN%

#ufw allow http #для работы сертбота
#certbot certonly --standalone --preferred-challenges http --agree-tos --email mail@mydomain.ru -d vpn.mydomain.ru
#ufw deny http #после получения сертификата, зачем нам открытый 80-ый порт?

Если сертификат успешно получен (99% случаев), добавляем в /etc/letsencrypt/renewal/vpn.mydomain.ru.conf хуки (чтобы сертификат без проблем обновлялся):

pre_hook = ufw allow http
post_hook = ufw deny http

Цепляемся к локальному домену

#realm join mylocaldomain.local -U mydomainadmin --install=/

После успешного подключения, сначала ограничим доступ:

#systemctl enable sssd
#systemctl start sssd
#realm deny --all # По умолчанию никто не может логиниться
#realm permit -g myvpnaccessgroup@mydomain.local

Потом поправим /ect/sssd/sssd.conf (

[sssd]
domains = mydomain.local
config_file_version = 2
services = nss, pam
default_domain_suffix = mydomain.local

[domain/KVOLITEK.local]
default_shell = /bin/bash
krb5_store_password_if_offline = True
cache_credentials = True
krb5_realm = mydomain.local
realmd_tags = manages-system joined-with-adcli 
id_provider = ad
fallback_homedir = /home/%u@%d
ad_domain = mydomain.local
use_fully_qualified_names = True
ldap_id_mapping = True
access_provider = simple
simple_allow_groups = myvpnaccessgroup@mydomain.local

И перезагрузим конфигурацию sssd #systemctl restart sssd

Теперь дело за малым, сам openconnect

Он уже установлен. Настраиваем минимум конфигурации (можно больше, но для старта хватит). Файл конфигурации отлично документирован, поможет в дальнейшем. Ниже, только изменённые строки, остальное на старте просто оставляем по умолчанию:

auth = "pam" # авторизация в домене через PAM
listen-host = %realipon_eth0%
server-cert = /etc/letsencrypt/live/vpn.mydomain.ru/fullchain.pem
server-key = /etc/letsencrypt/live/vpn.mydomain.ru/privkey.pem
max-clients = 25 # по числу сотрудников компании + 5 на случай подвисших :)
max-same-clients = 1 # иначе будет хаос и анархия
default-domain = vpn.mydomain.ru
ipv4-network = xxx.xxx.xxx.xxx/xx # диапазон, который вы решили выдать впн-клиентам
tunnel-all-dns = true # чтобы всем прилетал корпоративный ДНС
dns = xxx.xxx.xxx.xxx # адрес локального днс-1
dns = xxx.xxx.xxx.xxx # адрес локального днс-2
nbns = xxx.xxx.xxx.xxx # адрес локального wins (если надо зачем-то)
route = xxx.xxx.xxx.xxx/xx # подсети в офисе/цоде/филиалах. По одной на строку. Все, куда будут ходить впн-клиенты

Перезапускаем службу

#systemctl restart ocserv

Маршрутизация в локальной сети

Обязательно настраиваем в динамической маршрутизации или статический маршрут на каждом своём сервере в подсеть VPN (Если VPN-сервер у вас не основной шлюз)

Всё, можно пускать пользователей.

Клиентское ПО

Linux — openconnect, network-manager-openconnect, network-manager-openconnect-gnome

Windows Openconnect-gui с гитлаба

Android/IOS — Cisco AnyConnect из соответствующего магазина приложений.

Настраиваются все одинаково, понадобится только:

  • Ссылка на сервер, вида https://vpn.mydomain.ru
  • Логин
  • Пароль

wireguard и debian 10 в 2024 году

Актуальный Wireguard в Debian 10 сейчас ставиться из backports-репозитория, но все инструкции забывают, что, кроме wirguard, надо из backports поставить и актуальное ядро, потому что модуль wirguard собран именно для него.

По этому, актуальная инструкция выглядит так:

  • Добавить backports-репозитории, например вот так
# sh -c "echo 'deb http://archive.debian.org/debian buster-backports main contrib non-free' > /etc/apt/sources.list.d/buster-backports.list"
  • Установить актуальное ядро, актуальные заголовки ядра. В моём случае вот так (в вашем — может отличаться, используйте <# apt search linux-image-5> чтобы удостовериться)
# apt install linux-image-5.10-amd64 linux-headers-5.10-amd64
  • И уже только после этого ставить wireguard и настраивать его.
# apt install wireguard

PS Установщик Wireguard внутри панели ISPManager также об этом не знает, по этому он успешно всё поставит, не сообщив ни о какой ошибке, и даже соединение будет устанавливаться, но трафик ходить не будет, пока вы не обновите ядро. Он также тащит wireguard из backports, как и установка вручную.

Linux и OpenVPN с 2FA (openvpn3)

OpenVPN, который мы бесплатно знаем и любим, на самом деле очень не плохо продаёт свой OpenVPN Access Server — коммерческую версию, которая, в том числе, поддерживает двухфакторную авторизацию при помощи Google Auth или Яндекс.Ключ.

Чтобы подключаться к таким серверам из Linux, пакетов из комплекта операционки недостаточно, и, придётся забыть про ползунок в Network Manager.

Итак, что же делать, чтобы подключиться.

  1. Получить профиль по инструкции или от системного администратора сервера.
  2. Установить openvpn3-cli в свой линукс
    Для этого, читать и выполнять статью в вики openvpn
  3. Подключиться и работать.

Для подключения выполнить команду

openvpn3 session-start --config %путь_к_файлу_профиля%

Ввести логин, пароль, 2FA

Для отключения, выполнить команду

openvpn3 session-manage -D -c %путь_к_файлу_профиля%

Подробнее про управление подключениями тут

Установка принтера TSC TPP-244Plus в Debian 12

Вообще, TSC, молодцы, по этому просто перешёл по ссылке, выбрал принтер из списка, скачал х64-драйвер для линукс.

Внутри архива pdf с инструкцией, по ней просто поставил принтер.

Есть нюанс: мой принтер в режиме «термотрансферный», но драйвер для линукс это игнорирует, и не подматывает копирку, по этому, я перешёл в управление cups, по ссылке https://localhost:631/ перешёл в принтеры, выбрал принтер и провалился в него.

После этого, в администрирование выбрал «установить параметры по умолчанию

И на вкладке Media Settings, жёстко установил Thermal Transfer

Также, установил размер страницы, равный размеру установленных этикеток

Сохранил параметры, создал этикетку в gLabels (да, пришлось добавить пользовательский шаблон, по ширине и высоте установленной этикетки) и проверил печать

Русский — сразу русский, шрифт печатается как надо. TSC — молодцы 🙂

Ещё раз про pfsense на Silicom Versa-110

Ко мне приехал ещё один такой сервер, но на этот раз ревизии R106 (предыдущие были R107, т.е. более поздние)

По внешнему виду, отличия есть — более ранняя выгляит дороже, смотрите сами:

Крепление БП с резьбовой муфтой, отдельная кнопка питания, быстрый доступ к сим-карте… Крч, как обычно, чем новее, тем дешевле… Не только москвич этим занимался, все занимаются 🙂

Но я не об этом. Главное отличие 106 и 107 ревизий, это то, что консоль в 106 висит на COM1, по этому для установки pfsense на него, образ надо скачивать вот так:

То есть, для R106, нужен обычный образ AMD64, для флешки, с Serial-консолью на COM1, дальше всё как обычно.

Установка pfsense на Silicom Versa-110 ревизии R107

Для начала готовим флешку с установщиков pfsense.

Для этого идём в загрузки pfesense community, скачиваем образ pfsense для архитектуры Netgate ADI

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

Далее, аналогично предыдущей статье, подключаем железку к любому компьютеру, вставляем флешку в usb-порт железки, и подаём питание

Выбираем терминал по умолчанию (vt100)

Всё, стартует установка pfsense, без каких-либо особых заморочек. Единственное — я настоятельно рекомендую выбирать ZFS в качестве файловой системы. По опыту, она сильно легче переживает перезагрузки по отказу питания

и я всегда делаю раздел swap равным объёму оперативной памяти

Всё, дальше выбираем диск для zfs, чуть ждём, перезагрузка и всё готово

Порты сетевушек распределяются почти (ibg0 — порт 1, igb1 — порт 0, дальше подряд) порядку:

У меня снова патч-корд в 6-м порту, по этому я выбираю в качестве LAN-интерфеса igb5, назначаю ему ip-адрес и всё

pfsense установлен, можно настраивать.

И первое, что надо сделать, это заставить pf запомнить, что консоль на COM2, иначе, после отключения питания, консоль будет недоступна.

так что сразу, как только попал в браузер, возвращаюсь в консоль, где:

# vi /boot/loader.conf.local
comconsole_port="0x2f8"

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

Новая игрушка Silicom Versa-110 (установка ОС)

Обрёл прикольную штуку

Можно подумать, что это роутер, или ещё какая-то сетевая железка, но нет, это микро-сервер на процессоре Intel Atom C2558@2.40GHz с 8Gb оперативки и eMMC на 64Gb

У микро-сервера вообще нет видеокарты, всё локальное управление строго через консоль, которая сделана в виде rs232-USB моста, и выведена как miniUSB-порт.

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

По умолчанию там уже установлен какой-то Linux, но логин и пароль из документаций, не смотря на то, что железка вроде как новая не подошёл. Ну что ж, переустановим всё.

Сначала подготовим совершенно стандартный дистрибутив Debian 12 на флешке.

Потом, подключим микро-сервер к компьютеру кабелем USB-microUSB, и дождёмся установки драйвера. Windows 7 драйвер нашла автоматом, но если понадобится то он есть у производителя моста. Если COM-порт не определяется, замените кабель. Сервер оказался требователен к качеству кабеля, у меня завелось со вторым.

Запустим putty (важно, никакой kitty — kitty не умеет в консоль по человечески), установим com-порт, который получил мост в дистпетчере устройств, и скорость 115200

Нажмём Open, увидим чёрный экран, и один раз нажём Enter. Ура, мы вошли

Просто вставляем флешку в любой USB-порт и перезагружаемся. BIOS сервера настроен на приоритет загрузки с USB, ничего больше делать не надо.

Перезагружаемся и видим установщик, но просто запустить не выйдет, видюхи-то нет.

В консоли запускается установщик, выбираем пункт Install, нажимаем Tab один раз, и в конец строки параметров запуска добавляем console=ttyS1,115200n8

Нажимаем Enter и просто ждём, порядка минуты, пока запустится установщик

Это обычный текстовый установщик Debian, ничего не обычного в нём нет. Единственное, что важно — правильно выбрать сетевуху. Всего в сервере 6 сетевых портов. Точно не понятно, что это, потому что документация пишет, что там Marvel 88E1543 с 4 гигабитными портами, и две отдельных Intel i211 (тоже по гигабиту на порт), но дебиан определяет Intel i354 и две Intel i211, причём про 354 пишет, что просто Ethernet. Собственно, к чему это всё.

Вот это, порты с 4 по 6 на железке

А это, первый и второй:

У меня патч-корд вставлен в 6 порт

и в списке выбора, это она:

Дальше, выбираем нужные пакеты, устанавливаем Debian и перезагружаемся. Что клёво, что установщик сам добавит консоль в интерфейсы вывода, руками делать ничего не надо.

Надо не забывать устанавливать ssh-сервер, потому что иначе доступ будет только через консоль 🙂

Сразу получаем вот такой набор ошибок

Интернет утверждает, что это проблема перехода процессора в энергосберегающий режим. По этому, отключаем энергосбережение. Для этого в файле /etc/default/grub меняем строку GRUB_CMDLINE_LINUX_DEFAULT=

В конец строки добавляем consoleblank=0 intel_idle.max_cstate=1

У меня итоговая строка получилась

GRUB_CMDLINE_LINUX_DEFAULT="systemd.unified_cgroup_hierarchy=false quiet consoleblank=0 intel_idle.max_cstate=1"

После этого выполняем

#grub-update 

И перезагружаемся. Всё, система установлена.

Роутеры Keentic и разделённая локальная сеть

Дано:

Сеть вида:

В сети два сегмента разделённых маршрутизатором (цели различные), и единый выход в интернет через роутер кинетик

  • Адрес кинетика 192.168.1.1, сеть 192.168.1.0/24, непосредственно подключена к его коммутатору
  • Сеть 192.168.2.0/24 отделена маршрутизатором от сети 192.168.1.0/24
  • Для сети 192.168.2.0/24, шлюз по умолчанию 192.168.2.1
  • Для сети 192.168.1.0/24, шлюз по умолчанию 192.168.1.1
  • В сети 192.168.1.0/24 есть маршруты в сеть 192.168.2.0/24 и компьютеры видят друг-друга и могут взаимодействовать
  • На кинетике 192.168.1.1 включен NAT (по умолчанию) и раздаётся интернет.

Задача:

Сделать так, чтобы интернет работал не только на компьютерах в сети непосредственно подключенной к кинетику, но и в сети за промежуточным маршрутизатором

Решение:

  • Добавить на кинетик маршрут в сеть 192.168.2.0/24 (для простых сетей достаточно статического маршрута)
  • Выполнить на кинетике команды (через telnet или ssh):
ip nat 192.168.2.0 255.255.255.0
system configuration save

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