У RAM-only VPN довольно удачное название и довольно неудачная репутация. По рекламе легко решить, что перед нами какой-то особенно защищённый VPN-протокол. На практике WireGuard, OpenVPN или IPsec работают как раньше. Меняется сервер. Рабочая система и изменяемые данные живут в оперативной памяти, а после перезапуска сервер получает чистое состояние вместо продолжения жизни с содержимым прежнего диска.
Поднять такую схему самостоятельно можно. Но обычный VPS с WireGuard и логами в tmpfs я бы не называл полноценным RAM-only сервером. Настоящая diskless-архитектура начинается там, где VPN-узел способен стартовать без записываемого системного диска, получает ОС из доверенного образа, разворачивает её в RAM, а конфигурацию и секреты получает заново. Разница кажется небольшой, пока не появляется вопрос, что останется после компрометации или изъятия сервера.
Что RAM-only меняет на самом деле
У обычного Linux-сервера есть постоянное состояние. На SSD или виртуальном диске находятся ОС, конфигурация, пакеты, системные журналы, кэш, дампы, временные файлы и часто приватные ключи. Даже если администратор сознательно не ведёт журнал VPN-соединений, программы способны оставить массу побочных следов.
RAM-only меняет прежде всего модель хранения.
загрузка
|
v
проверенный образ ОС
|
v
оперативная память
|
+--- VPN-процесс
+--- конфигурация
+--- временные файлы
+--- рабочие ключи
+--- volatile-логи
|
v
перезапуск
|
v
чистое рабочее состояние
Хороший реальный пример даёт Mullvad. Компания сначала перевела часть инфраструктуры на собственный загрузчик stboot, а затем перевела VPN-серверы на diskless-схему. Сервер получает подписанный пакет ОС от provisioning-системы, проверяет подпись и загружает систему без рабочего диска. Инфраструктуру после перехода проверяли внешние аудиторы.
У подхода есть два практических плюса. Первый связан с минимизацией следов. Случайно записанный временный файл не останется лежать на SSD годами. Второй связан с воспроизводимостью. Каждый перезапуск может возвращать сервер к одному известному образу вместо накопления изменений после сотен обновлений и ручных правок.
Но фраза «всё работает из RAM» ещё не означает «сервер ничего не записывает». Процесс может вести журнал в памяти, отправлять события на удалённый syslog, передавать NetFlow другому серверу или выгружать метрики в облачную систему. RAM-only и no-logs решают разные задачи.
Есть ещё одна тонкость. Linux tmpfs хранит данные в виртуальной памяти, но при обычной конфигурации ядро способно выгружать страницы tmpfs в swap. Поэтому файл в tmpfs не обязательно всю жизнь находился только в физических модулях RAM. Для чувствительных данных swap нужно отключить либо использовать tmpfs с параметром noswap, если работающая версия ядра его поддерживает.
sudo swapoff -a swapon --show
Вторая команда должна вернуть пустой результат, если дискового swap действительно нет.
Что можно сделать на обычном VPS
Начать проще всего с промежуточной схемы. ОС продолжает находиться на виртуальном диске, но журналы, временные данные и рабочие копии ключей уходят в RAM. Полноценным diskless VPN такой сервер не станет, зато риск случайно оставить чувствительные данные на гостевом диске заметно снижается.
На Debian или Ubuntu можно перевести systemd-journald в volatile-режим.
sudo install -d -m 0755 /etc/systemd/journald.conf.d printf '[Journal]
Storage=volatile
RuntimeMaxUse=100M
' | sudo tee /etc/systemd/journald.conf.d/volatile.conf sudo systemctl restart systemd-journald
При Storage=volatile journald использует /run/log/journal. После перезагрузки такой журнал не сохраняется. Но нужно проверить, не работает ли параллельно rsyslog, сторонний агент мониторинга или сервис облачного провайдера, который забирает события наружу.
Для особо чувствительных файлов можно создать отдельный tmpfs.
sudo mkdir -p /run/wg-secrets sudo mount -t tmpfs -o size=16M,noswap,mode=0700 tmpfs /run/wg-secrets
Теперь WireGuard может читать приватный ключ оттуда.
sudo wg set wg0 private-key /run/wg-secrets/server.key
Сам механизм WireGuard от RAM-only никак не меняется. Протокол использует постоянную пару ключей узла и временные сеансовые ключи, а маршрутизация, NAT, DNS и firewall остаются отдельной задачей администратора. Устройство протокола и обычную настройку сервера я подробно разбирал в материале про WireGuard.
Тут возникает проблема, которую часто пропускают инструкции про «VPN целиком в RAM». Если после каждого старта генерировать новый приватный ключ сервера, изменится и публичный ключ. Старые конфигурации клиентов перестанут подходить.
wg genkey > /run/wg-secrets/server.key wg pubkey < /run/wg-secrets/server.key
Для лаборатории новая пара после каждого старта допустима. Для постоянного сервера нужен стабильный приватный ключ. Значит, секрет всё равно должен где-то храниться.
Нормальная архитектура переносит постоянный секрет за пределы VPN-узла.
хранилище секретов
|
v
защищённая выдача ключа
|
v
/run/wg-secrets/server.key
|
v
WireGuard
VPN-сервер получает ключ после загрузки и держит рабочую копию в RAM. Постоянная копия может находиться в отдельном vault, HSM, системе управления конфигурацией или на администраторском компьютере. Для домашнего сервера вполне годится ручная передача ключа после старта. Не так красиво, зато схема понятна и не создаёт ложного ощущения, что постоянное хранение секрета каким-то образом исчезло.
На обычном VPS остаётся ещё одна граница доверия. Оператор гипервизора контролирует физическую машину. Перенос файлов гостевой системы в RAM не защищает память виртуальной машины от инфраструктуры хостера так, как это делают специальные Confidential VM с аппаратным шифрованием памяти. Поэтому «RAM-only VPS» защищает прежде всего от сохранения данных внутри гостевого диска, а не от самого владельца виртуализационной платформы.
Как собрать настоящий diskless WireGuard
Для полноценного варианта я бы взял bare metal или виртуальную машину, которая умеет загружаться с ISO, PXE или другого контролируемого источника без постоянного системного диска. Удобная основа для эксперимента есть у Alpine Linux. В Diskless Mode Alpine загружает ОС и приложения в RAM и работает оттуда.
На уже запущенном Alpine WireGuard ставится обычными пакетами.
apk add wireguard-tools wireguard-tools-wg-quick
Дальше поднимается стандартный туннель. Например, минимальная серверная конфигурация выглядит так.
[Interface] Address = 10.20.0.1/24 ListenPort = 51820 PrivateKey = SERVER_PRIVATE_KEY [Peer] PublicKey = CLIENT_PUBLIC_KEY AllowedIPs = 10.20.0.2/32
Приватный ключ в реальной RAM-only схеме я бы не вписывал в неизменяемый общий образ. Серверу лучше получить секрет после проверки загруженной системы и положить его во временный каталог.
Также потребуется включить IP forwarding и настроить маршрутизацию или NAT.
sysctl -w net.ipv4.ip_forward=1
Дальнейшая конфигурация firewall ничем не отличается от обычного WireGuard. RAM-only относится к жизненному циклу сервера, а не к прохождению пакетов через туннель.
У Alpine есть ловушка. Diskless Mode поддерживает lbu, который позволяет сохранять изменения между загрузками в Alpine local backup. Очень удобная функция легко ломает строгую модель RAM-only. Если записать туда конфигурацию WireGuard вместе с приватным ключом, секрет снова появится на постоянном носителе. Поэтому нужно заранее решить, какие данные разрешено сохранять, а какие сервер обязан получать извне после каждого запуска.
Проверять результат лучше не по названию технологии, а по фактическому состоянию машины.
findmnt -T / findmnt /run swapon --show lsblk wg show
Нужно убедиться, что корневая система не использует записываемый постоянный диск, swap отсутствует, секреты находятся на volatile-файловой системе, а WireGuard действительно получил нужный ключ и поднял интерфейс.
Полезен и простой тест.
echo test > /run/ram-only-test reboot
После загрузки файла /run/ram-only-test быть не должно. Проверка сама по себе не доказывает diskless-архитектуру, но быстро обнаруживает грубую ошибку, когда предполагаемый временный каталог неожиданно оказался постоянным.
Следующий уровень уже ближе к коммерческой инфраструктуре. Загрузочный образ делают неизменяемым, проверяют криптографическую подпись перед запуском и отделяют систему выдачи секретов от самого VPN-узла. Тогда злоумышленнику недостаточно изменить работающий сервер в RAM. После перезапуска изменения исчезнут, если атакующий не получил доступ к загрузочному образу или provisioning-системе.
Материал предназначен для легального администрирования и защиты собственных сетей. При работе с VPN нужно учитывать законодательство страны использования, включая требования законодательства России. Инструкции нельзя применять для несанкционированного доступа, слежки, взлома, нарушения правил сервисов или незаконного обхода установленных ограничений.
Почему RAM-only не надо превращать в культ
Самый интересный контраргумент приходит из той же VPN-индустрии. Proton VPN сознательно не использует RAM-only для основной серверной инфраструктуры и считает, что правильно настроенное полнодисковое шифрование вместе с политикой no-logs может обеспечить сопоставимую защиту данных выключенного сервера. Независимый аудит инфраструктуры Proton подтверждал отсутствие механизмов, способных сохранять пользовательскую активность и идентифицирующие метаданные.
Я бы не делал из спора вывод, что RAM-only бесполезен. Скорее наоборот. Спор хорошо показывает, где заканчивается технология и начинается маркетинг. Если работающий сервер уже взломан и атакующий получил root, RAM не спасает. Злоумышленник может читать память, менять процессы, перехватывать пакеты и отправлять данные наружу. С зашифрованным диском ситуация работающей машины похожая, поскольку ОС уже имеет доступ к расшифрованным данным.
RAM-only сильнее проявляет себя в другой ситуации. Сервер перезапустили, диск изъяли или машину вернули к исходному образу. Рабочие файлы предыдущего запуска не лежат на локальном SSD и не превращаются в забытые артефакты для последующего анализа.
Даже здесь есть физическая оговорка. DRAM не превращается в нули буквально в момент пропадания питания. Исследования cold boot показали эффект остаточного хранения данных в оперативной памяти. Для удалённого VPS такой сценарий почти всегда находится далеко за пределами обычной модели угроз, но утверждение «RAM физически невозможно прочитать после отключения» технически слишком сильное.
| Архитектура | Что остаётся после перезапуска | Что даёт на практике |
|---|---|---|
| Обычный VPS | ОС, конфигурация, ключи и возможные журналы | Простота управления |
| VPS с volatile-логами и tmpfs | ОС и постоянная часть конфигурации | Меньше случайных следов на гостевом диске |
| Diskless Linux | Только данные внешней управляющей инфраструктуры | Чистое состояние после каждого старта |
| Diskless сервер с подписанным образом и внешними секретами | VPN-узел не хранит своё рабочее состояние постоянно | Наиболее полноценная RAM-only модель |
Поэтому для одного собственного VPN я бы двигался постепенно. Сначала убрать дисковый swap, перевести журналы в volatile-режим, проверить сторонние агенты логирования и держать рабочие секреты в RAM. Такой вариант легко построить на существующем VPS и легко проверить.
Если задача состоит именно в том, чтобы сервер ничего не наследовал от предыдущего запуска, нужен уже diskless Linux, неизменяемый загрузочный образ и отдельная выдача секретов. Для домашней лаборатории Alpine подходит очень хорошо. Для серьёзной инфраструктуры я бы дополнительно смотрел на Secure Boot, проверяемую загрузку, управление ключами и границу доверия гипервизора. Именно вместе эти механизмы превращают RAM-only из рекламной наклейки в осмысленную архитектуру.
