Переносил тут ikev2 на новую машину, решил не морочиться с переносом сертификатов, а выпустить серверу новый — благо Let’sEncrypt никаких ограничений, не накладывает.
Новые сертификаты выпускаются уже не RSA, а ECDSA, так что в ipsec.secrets необходимо поменять тип закрытого ключа сервера с RSA на ECDSA
Иначе ничего не заработает 🙂
И не забывайте, apparmor без настройки не даст стронгсвану прочитать сертификаты из каталогов Let’sEncrypt
# 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
Отмазка: данная статья не предназначена для настройки впн с целью обхода санкций, только для подключения к офисной рабочей сети.
Исторически, мы использовали для подключения удалёнщиков 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, доменной авторизацией
Добавляем в публичный 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 хуки (чтобы сертификат без проблем обновлялся):
После успешного подключения, сначала ограничим доступ:
#systemctl enable sssd
#systemctl start sssd
#realm deny --all # По умолчанию никто не может логиниться
#realm permit -g 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
Актуальный 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> чтобы удостовериться)
И уже только после этого ставить wireguard и настраивать его.
# apt install wireguard
PS Установщик Wireguard внутри панели ISPManager также об этом не знает, по этому он успешно всё поставит, не сообщив ни о какой ошибке, и даже соединение будет устанавливаться, но трафик ходить не будет, пока вы не обновите ядро. Он также тащит wireguard из backports, как и установка вручную.
OpenVPN, который мы бесплатно знаем и любим, на самом деле очень не плохо продаёт свой OpenVPN Access Server — коммерческую версию, которая, в том числе, поддерживает двухфакторную авторизацию при помощи Google Auth или Яндекс.Ключ.
Чтобы подключаться к таким серверам из Linux, пакетов из комплекта операционки недостаточно, и, придётся забыть про ползунок в Network Manager.
Итак, что же делать, чтобы подключиться.
Получить профиль по инструкции или от системного администратора сервера.
Установить openvpn3-cli в свой линукс Для этого, читать и выполнять статью в вики openvpn
Можно подумать, что это роутер, или ещё какая-то сетевая железка, но нет, это микро-сервер на процессоре 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
Понадобилось перенести виртуалки из ESXi в Hyper-v, и интернет притащил решение Starwind V-to-V Converter.
Программа абсолютно бесплатная, но для скачивания надо заполнить регистрационную форму. Одноразовый e-mail вполне прокатил :). Ссылка на скачивание приходит в почту, по этому не закрывайте окно одноразовой почты до скачивания.
Сама софтина — по сути мастер, и умеет конвертировать виртуальные машины не только из ESXi
На втором шаге ввёл адрес хоста с ESXI, логин и пароль рута на хосте
Конвертер немножко подумал и показал список виртуальных машин
Дальше осталось только выбрать куда тащить машину, и всё пошло поехало.
Перенос машины с диском на 1Тб по 10Гб/сек сети занял 4 часа, включая конвертацию файлов дисков
Мне же надо было утащить виртуалку с Debian Linux 11 из ESXi в Hyper-v.
Я проделал это дважды: сначала сделал тестовую конвертацию работающей машины, а потом уже боевую выключенной.
При конвертации работающей машины, обнаружилось, что из fstab после конвертации исчезли все диски кроме системного. Сами тома никуда не делись и нормально сконвертировались, но их пришлось добавить в fstab вручную и перезагрузиться.
При конвертации выключенной, проблемы с fstab не было.
В обоих случаях, после конвертации необходимо сделать следующее:
Изменить имена сетевых адаптеров в /etc/network/interfaces (если у вас не дебиан, возможно используется другой механизм инициализации сети, но всё равно, имена сетевух сменить надо.
После смены имён сетевушек, я перезагрузился. Можно просто переинициализировать сеть.
Удалить open-vm-tools. После удаления, apt может предложить удалить не нужные пакеты. Так делать не надо, удалится что-нибудь нужное.
выполнить apt update && apt full-upgade -y для обновления системы. Даже если ничего не установится (вдруг у вас обновлённая ОС), проблема с autoremove после этого уйдёт.
Перезагрузить виртуальную машину
Проверить, что установлены модули hyperv, командой lsmod | grep hv
Если модулей нет — установить. В Debian 11 есть.
Аптайм машины после миграции после переезда уже две недели. Всё работает. Ни один сервис, а на машине
электронная почта
несколько сайтов на разных движках
ispmanager
strongswan
не сломался. Единственное, для нормальной работы ispmanager необходимо сохранить ip-адрес при первых запусках. После того как всё заработает, можно поменять.
С Debian 10 и примерно соответствующей ей Ubuntu strongswan закрыт аппармором, через это все инструкции типа «создайте ссылки на сертификаты в /etc/letsencrypt/live/yourdomainnamehere» перестали работать.
Решение чертовски простое, хоть и не очевидное. Надо добавить в /etc/apparmor.d/local/usr.lib.ipsec.charon две строчки:
Настраивал себе мультирум из snapcast + mpd… Возился чёртовых два часа — тишина на клиентах и всё тут…
Случайно заметил при выполнении mpc -h localhost
Чего я не замечал, потому что громкость mpd никак не влияет на локальную акустическую систему воткнутую в оптический разъём 🙂
Стоило сделать в приложении вот так:
И всё волшебным образом заиграло с первоначальной настройкой, сделанной в первые 10 минут ковыряния 🙂
в /etc/snapserver.com — всё «по умолчанию» кроме
codec = pcm
В mpd.conf просто добавил (из инструкции):
audio_output {
type "fifo"
name "my pipe"
path "/tmp/snapfifo"
format "48000:16:2"
mixer_type "software"
}
Не смотря на то, что инструкция рекомендует отключить локальное воспроизведение — я его не отключал, ибо оптика и хороший усилитель.
Вместе с мультирумом локальную акустику гонять можно только если не слышишь локальную и сетевую одновременно. Все сетевые отстают примерно на 0.7-1.2 секунды. Между собой все сетевые играют синхронно.