Ваш облачный VPN по-прежнему зависит от хостинг-провайдера

Вы установили операционную систему, усилили службу и держите ключи, и начинает казаться, что сервер ваш. Он ваш так же, как съёмная квартира ваша: замок под вашим контролем, а здание нет. Гипервизор, сеть перед инстансом и аккаунт, который может всё пересоздать, принадлежат кому-то другому. Именно это различие определяет, что должен покрывать план восстановления, и это та часть, которую самостоятельный хостинг меняет меньше всего.

Аккаунт — настоящая плоскость управления

Аккаунт хостинга управляет виртуальной машиной, её дисками, снимками, публичными адресами и сетевыми правилами. Всё это можно изменить, даже не заходя в гостя, что выводит аккаунт за пределы модели угроз, которую описывает большинство руководств по VPN. Идеальная конфигурация туннеля переживает действие с аккаунтом, заменяющее диск.

Защищайте этот аккаунт как отдельный актив: независимые учётные данные, аппаратные вторые факторы и журнал аудита, который кто-то действительно читает. Общий вход в менеджере паролей с сервисом VPN — та самая ошибка, из-за которой все остальные меры теряют смысл.

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

Инфраструктурные события, которыми вы не управляете

Живая миграция, обслуживание хоста, отказ оборудования на физическом узле и событие ёмкости — всё это провайдер решает по своему графику. Вы можете увидеть перезагрузку, краткую потерю пакетов или смену адреса, но причину не увидите. Проект, который считает инстанс неподвижной точкой, истолкует каждое из этого как сбой VPN. Правильное действие — сделать сервис устойчивым к исчезающему инстансу, а не искать причину, которую вам никогда не покажут.

Резервные копии относятся к этому уровню, а не к туннелю. Храните конфигурацию сервера, идентичности, план адресов и разрешённые маршруты там, где не требуется доступность инстанса, и убедитесь, что копию можно восстановить без исходного диска.

Поведение адреса заслуживает отдельной проверки. Переживёт ли публичный адрес остановку, замену или удаление, зависит от того, как он был выделен, и эти три операции не взаимозаменяемы. Запишите, на какую из них вы рассчитываете, прежде чем инцидент сделает вопрос срочным.

Проверьте, что переживает пересборку

Стройте путь восстановления, пока всё работает. Определите консоль или доступ вне полосы, который предлагает провайдер, убедитесь, что до него можно добраться без туннеля, и храните учётные данные там, откуда сломанный ноутбук или потерянный телефон их не унесёт. Если локальное изменение брандмауэра блокирует туннель, эта консоль — единственный путь назад.

curl -s http://169.254.169.254/latest/meta-data/instance-id
curl -s http://169.254.169.254/latest/meta-data/public-ipv4
cloud-init status --long

Служба метаданных отвечает на вопросы об инстансе, которые гость иначе не видит, а её точные пути различаются между провайдерами и платформами, поэтому сверяйте их с документацией продукта, который вы запускаете. Затем проведите одну контролируемую пересборку тестового инстанса и замерьте время. Процедура восстановления, которую никто не выполнял, — это гипотеза.

Обратите внимание, что пересборка сделала с адресом, ключами хоста, идентичностью диска и всем, что закрепляют клиенты. Клиенты, кэшировавшие ключ хоста, будут жаловаться после пересборки, и эта жалоба — правильное поведение, а не ошибка, которую нужно подавить.

Решите, что действительно меняет самостоятельный хостинг

Запуск собственного VPN переносит доверие с оператора VPN на хостинг-провайдера и вас самих. Это реальное изменение, и оно не равно удалению третьей стороны. Если цель была не дать коммерческому VPN наблюдать за трафиком, провайдер всё ещё может наблюдать за сетью инстанса, его диском и записями об оплате.

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

Запишите ответ как разделение труда: какой уровень отказал, кто может его починить и сколько занимает этот ремонт. Самостоятельный хостинг меняет, кому вы доверяете, и полезная часть упражнения — точно знать, за какой уровень вы доверяете им.