Шпаргала, всякие настройки сервера с 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, как и установка вручную.