Часть 2. VPN к серверу 1С лёг после ядра 7.1.3-arch1-2: что делать

Двухсерверная self-hosted схема из VPN-шлюза и отдельного сервера с Gitea даёт полный контроль над доступом к 1С, но ломается на обновлении ядра: после перехода на 7.1.3-arch1-2 модуль AmneziaWG не загружается и туннель молчит. Лечится запасным ядром LTS, режимом amneziawg-go и сборкой через Gitea.

Речь о корпоративном канале «офис или филиал — сервер 1С». Обход блокировок эта схема не решает, и мы её для этого не описываем.

Как устроена схема: шлюз, Gitea и зачем нужен второй сервер 🧩

Первый сервер, шлюз, стоит в Москве рядом с сервером 1С. На нём работает AmneziaWG, форк WireGuard с изменёнными заголовками пакетов, и больше ничего. Из туннеля сотрудники попадают только на сервер 1С, остальная сеть для них закрыта.

Второй сервер держит Gitea и раннер Gitea Actions. В репозиториях лежат конфиги шлюза, скрипты установки и пайплайн, который собирает amneziawg-go и пакеты под нужное ядро. Компиляторам и заголовкам ядра на боевом шлюзе делать нечего: собирают на втором сервере, шлюз получает готовый артефакт. Если шлюз вышел из строя, новый разворачивается из репозитория за время установки системы.

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

Приватные ключи в репозиторий кладут только зашифрованными, например через sops и age. Узел с Gitea грузит процессор во время сборок, поэтому его берут отдельно, например как выделенный сервер в аренду, и не совмещают со шлюзом.

Оба узла стоят в России. Персональные данные в базе 1С по 152-ФЗ записывают и хранят на серверах в РФ, а шлюз пропускает через себя весь трафик к ним.

Почему возникает сбой на ядре 7.1.3-arch1-2 ⚠️

Понедельник, 8:40. Менеджеры филиала открывают 1С и получают сообщение «не удаётся подключиться к серверу». VPN-клиент жалуется, что рукопожатия нет. Ночью на шлюзе отработало обновление системы, и ядро поднялось до 7.1.3-arch1-2.

Причина в устройстве модуля. AmneziaWG в режиме ядра живёт вне основного дерева Linux и собирается через DKMS отдельно под каждую версию ядра. Arch отдаёт новые ядра сразу, без выдержки. Модуль под 7.1.3-arch1-2 либо не пересобрался, потому что версии заголовков разошлись с ядром, либо не скомпилировался из-за изменений во внутренних интерфейсах ядра. Ядро новое, но модуля под него нет, поэтому интерфейс awg0 не поднимается.

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

Вторая ловушка: Arch не хранит прежнее ядро. Обновление удаляет модули старой версии из каталога /usr/lib/modules, поэтому перезагрузиться на «вчерашнее» ядро нельзя, если рядом не стоит запасное.

К 9:30 склад не проводит отгрузки в базе, менеджеры выставляют счета в таблице и потом сводят их с базой руками, бухгалтер на удалёнке не закрывает день. Тот, кто собирал схему, в отпуске. Пользователь не знает про VPN. Он знает, что 1С не открывается.

Как исправить: порядок диагностики и три пути восстановления 🔧

Заходите на шлюз через консоль хостера. По VPN не получится: он и лежит. Дальше по порядку:

1. ✓Проверьте версию ядра командой uname -r и наличие интерфейса командой ip link show awg0.
2. ✓Выполните dkms status. Если модуль для 7.1.3-arch1-2 не в состоянии installed, откройте лог сборки: файл make.log в каталоге /var/lib/dkms/ внутри папки с версией модуля.
3. ✓Сверьте версии командой pacman -Q linux linux-headers. Они обязаны совпадать до последней цифры.
4. ✓Запустите modprobe amneziawg. Ответ покажет, что модуля для ядра нет вообще или он не подходит.

Параллельно откройте журнал: journalctl -b -u awg-quick@awg0 покажет, на каком шаге сервис остановился.

Быстрый путь: amneziawg-go вместо модуля

Реализация на Go создаёт tun-интерфейс и работает без модуля ядра. Она медленнее модуля, но RDP-сессии и тонкий клиент 1С гоняют мало трафика, поэтому офису и филиалу этого хватает. Туннель возвращается за минуты, а разбор причины переезжает на дневное время.

Откат ядра из кэша pacman

Pacman оставляет скачанные пакеты в каталоге /var/cache/pacman/pkg/. Установите прежние linux и linux-headers командой pacman -U с путями к этим файлам, перезагрузите шлюз и впишите оба пакета в строку IgnorePkg файла /etc/pacman.conf. DKMS соберёт модуль под вернувшееся ядро. Если кэш чистили, остаётся первый путь.

Пересборка модуля

Когда заголовки совпадают, а компиляция падает, дело в коде модуля. Обновите DKMS-пакет модуля до свежей версии или заведите issue в репозитории проекта и приложите make.log. Если нужен срочный патч, держите его в своём форке на Gitea: пайплайн соберёт модуль уже с ним.

Когда туннель поднят, проверьте три вещи: рукопожатие у тестового клиента, доступ к серверу 1С по RDP и список зависших сессий на самом сервере. После обрыва там остаются сессии, которые держат блокировки в базе.

Что делать, если ошибка повторяется 🔁

Туннель вернулся, но через день или после следующего обновления картина та же. Проверьте по списку:

• ✓Рукопожатие есть, пинг идёт, а RDP-сессия виснет. Уменьшите MTU в конфиге интерфейса, например до 1280: обфускация добавляет служебные данные, крупные пакеты теряются.
• ✓После пересборки рукопожатия нет, хотя модуль загружен. Сверьте параметры обфускации (Jc, Jmin, Jmax, S1, S2, H1–H4) на сервере и на клиентах. Они должны совпадать до последней цифры. Хранить их стоит в Gitea рядом с конфигом шлюза.
• ✓Модуль собран, но не загружается. Если включён Secure Boot, ядро отклоняет неподписанные модули. На виртуальном сервере его часто нет, на выделенном стоит проверить в UEFI.
• ✓Сбой возвращается после каждого крупного обновления. Причина в выборе системы: rolling-дистрибутив на боевом шлюзе чувствителен к каждому новому ядру. Переведите шлюз на ядро linux-lts или на Debian либо Ubuntu LTS.

Если туннель в порядке, а 1С всё равно рвёт сессии или тормозит, смотрите на сам сервер: лимиты сессий, лицензии, параметры кластера. Это уже зона настройки сервера 1С.

Как предотвратить: запасное ядро, сборки в Gitea и мониторинг 🛡️

• ✓Поставьте linux-lts и linux-lts-headers рядом с основным ядром и добавьте пункт в загрузчик. Тогда у шлюза всегда есть ядро, на которое можно перезагрузиться.
• ✓Впишите linux и linux-headers в IgnorePkg и обновляйте вручную в окно, которое выбрали сами, а не в ночь перед понедельником.
• ✓Снимайте снимок диска у хостера перед каждым обновлением ядра. Откат из снимка быстрее любой диагностики.
• ✓Сначала обновляйте тестовую копию шлюза. Проверьте, что модуль загружается, awg0 поднимается и тестовый клиент получает рукопожатие.
• ✓Соберите в Gitea Actions пайплайн: сборка модуля или amneziawg-go под целевое ядро, проверка загрузки, публикация пакета. Шлюз ставит только то, что прошло проверку.
• ✓Настройте мониторинг: скрипт раз в минуту смотрит время последнего рукопожатия в выводе awg show и пишет в Telegram, если связи нет.
• ✓Опишите регламент обновления на одной странице в Gitea: кто, когда и по какому списку проверок. Схема, которую знает один человек, не работает в его отпуск.

Своя схема или сервер 1С в аренде: что выбрать малому бизнесу ⚖️

VPN нужен ради одного: чтобы сотрудники работали в 1С. Сравните, сколько работы вы берёте на себя в каждом варианте.

Три часа ночной диагностики при ставке 3800 ₽/час (сопровождение 1С и сисадмин) стоят 11 400 ₽. Это примерно десять пользователь-месяцев на аренде сервера 1С, которая начинается от 1 100 ₽/мес за пользователя. Если в штате нет сисадмина, своя VPN-архитектура превращается во вторую работу для директора или главбуха, которые «немного разбираются».

На арендованном сервере 1С следить за ядрами и обновлениями системы приходится провайдеру, а не вам. Наш сервер 1С стоит в России, доступ сотрудникам настраиваем под вашу схему. Небольшой команде хватает виртуального сервера для 1С, а когда база вырастет, её переносят на выделенный.

Перенос выглядит так: выгрузка базы в файл .dt, развёртывание на арендованном сервере, проверка пользователей и прав, переключение ярлыков. Свой шлюз с Gitea после этого нужен, только если сотрудникам по-прежнему требуется доступ к другим внутренним ресурсам.

Если хотите оставить свою схему, сисадмин по ставке 3800 ₽/час настроит запасное ядро, пайплайн в Gitea и мониторинг с оповещением в Telegram. Если хотите снять вопрос совсем, переносите базу на арендованный сервер: аренда 1С начинается от 1100 руб/мес.

❓ Частые вопросы

Почему AmneziaWG перестаёт работать после обновления ядра?

Модуль AmneziaWG в режиме ядра собирается через DKMS отдельно под каждую версию. Если после обновления ядра заголовки не совпали по версии или код модуля не компилируется под новые интерфейсы, интерфейс awg0 не поднимается. Проверьте dkms status и pacman -Q linux linux-headers, а для срочного восстановления запустите amneziawg-go без модуля.

Как быстро вернуть VPN-туннель к серверу 1С, если шлюз не отвечает?

Зайдите на шлюз через консоль хостера, потому что по VPN не получится. Проверьте версию ядра и состояние модуля, затем запустите amneziawg-go: он работает без модуля ядра и поднимает туннель за минуты. Причину потом разберите без спешки: верните прежнее ядро из кэша pacman или пересоберите модуль.

Зачем в VPN-схеме отдельный сервер с Gitea?

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

Сколько стоит сервер для 1С в аренде и чем он выгоднее своего VPN?

Сервер 1С в аренде стоит от 1 100 ₽ в месяц за пользователя. Обновления системы и ядер делает провайдер, поэтому следить за версиями ядра вам не нужно. Свой VPN требует часов администратора: у внешнего сисадмина час стоит 3800 ₽, и три часа диагностики равны примерно десяти пользователь-месяцам аренды.

Законно ли держать собственный VPN для доступа сотрудников к 1С?

Да, корпоративный VPN между офисом, филиалами и сервером 1С — обычная практика. Схема не нужна для обхода блокировок и не описывается для этого. Учитывайте 152-ФЗ: персональные данные граждан РФ в базе 1С записывают и хранят на серверах в России, поэтому шлюз и сервер 1С размещают в российском ЦОД.