Переезд офиса на нового провайдера: как сохранить доступ к серверным ресурсам

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

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

Сразу о рамках примера. Мы рассматриваем уже работающий VPN: есть VPS с WireGuard и известным адресом, к нему подключается Linux-клиент. Установка VPN с нуля здесь не обсуждается, как и настройка роутера конкретной марки: у каждого производителя свой интерфейс, и выдумывать меню неизвестного устройства мы не будем. Расположение компонентов (CRM за VPS, ноутбук в офисе) — условное допущение примера, а не описание реальной компании.

Что держит схему на месте: VPS как неподвижная точка

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

Это не прихоть, а следствие устройства протокола. По описанию WireGuard, зашифрованные IP-пакеты идут поверх UDP, а в клиент-серверной схеме клиент хранит начальный endpoint сервера. Сервер же узнаёт адрес клиента по тому, откуда пришли корректно аутентифицированные данные. Иными словами, серверу не нужно заранее знать, какой у офиса адрес: он выучит его из первого же подлинного пакета. Поэтому у клиента в конфигурации записан адрес VPS, а у VPS адрес офиса вообще не прописан как обязательный.

Отсюда практический вывод для переезда. Пока адрес VPS не меняется, а ключи остаются теми же, офисной стороне не нужно «заново знакомиться» с сервером. Новый провайдер даст новый внешний адрес, но клиент по-прежнему отправит пакет на старый endpoint, а сервер, получив подлинный пакет с незнакомого адреса, начнёт отвечать туда. Источник подтверждает и более общий механизм: обе стороны используют последний endpoint, с которого успешно расшифровали аутентифицированные пакеты, и это рассчитано на смену IP-адреса peer.

Если же менять придётся сам VPS (например, переезжаете и на другой сервер), задача другая: тогда меняется неподвижная точка, и нужно править endpoint у каждого клиента. Это отдельный переезд, и смешивать его со сменой провайдера офиса не стоит. Чем меньше движущихся частей за один раз, тем проще понять, что сломалось.

Здесь же стоит сказать про ресурсы VPS. Для точки входа в небольшой офис разумной отправной точкой для пробы выглядят младшие конфигурации: например, Ba с 1 vCPU, 2 ГБ RAM и 40 ГБ NVMe или Uab с 2 vCPU и 4 ГБ. Это не обещание ёмкости, а место, с которого можно начать и замерить собственную нагрузку. Шифрование трафика, число одновременных пользователей и размер передаваемых файлов у каждого офиса свои. Если VPS у вас ещё нет, на странице аренды VPS MAATRIX перечислены локации UK, US, RU и FR, а доступ root позволяет самому настроить WireGuard-сервер.

Репетиция на одном ноутбуке

Менять провайдера для всего офиса, не проверив ни разу сам сценарий, значит узнавать о проблемах от недовольных коллег. Гораздо спокойнее взять один Linux-ноутбук с рабочим клиентом WireGuard и воспроизвести на нём главное: подключение из другой внешней сети. Это и есть репетиция.

Как создать «другую сеть», не дожидаясь монтажников нового провайдера? Самый простой способ: подключить ноутбук к мобильной точке доступа телефона. С точки зрения VPS это будет другой внешний адрес и, вероятно, другой NAT, то есть очень похоже на то, что случится после переезда. Важная оговорка: мобильный оператор и будущий провайдер офиса не идентичны, поэтому репетиция проверяет логику, но не заменяет финальную проверку на настоящей линии.

Порядок такой. Сначала фиксируем состояние «до»: туннель поднят в офисной сети, сервисы открываются. Затем переключаем ноутбук на другую сеть и смотрим, что произошло с туннелем. Состояние интерфейса показывает команда wg show; краткое руководство WireGuard называет её способом посмотреть состояние. Нас интересуют две строки у peer: время последнего рукопожатия и счётчики переданных байт. Если рукопожатие свежее, а счётчики растут при обращении к сервису, туннель восстановился.

sudo wg show

На стороне VPS выполняем ту же команду и смотрим на endpoint клиента. Если репетиция удалась, там окажется уже другой адрес, не тот, что был при подключении из офиса. Это и есть роуминг в действии: сервер сам выучил новый адрес, и никто не правил конфигурацию вручную.

Осторожно с выводом конфигурации. По руководству wg(8), команда wg showconf и машинный дамп могут содержать секреты. Поэтому, если вы собираетесь показать вывод коллеге или вставить в заявку, используйте обычный wg show и не копируйте закрытые ключи в чат.

Почему туннель иногда «молчит» и при чём тут keepalive

Бывает, что туннель после переключения сети формально существует, но сервисы не открываются. Первый подозреваемый, о котором стоит подумать, — NAT. Клиент в офисе сидит за NAT нового провайдера, и если он давно ничего не отправлял, запись о соединении в таблице NAT может устареть. Тогда сервер при попытке сам отправить пакет клиенту упрётся в закрытую дверь.

Для этого у WireGuard есть параметр PersistentKeepalive. По краткому руководству, он поддерживает состояние NAT, по умолчанию выключен и нужен не каждой конфигурации. Последнее замечание важно: не стоит включать его «на всякий случай» везде. Если ваш клиент всегда сам инициирует трафик (сотрудник открыл CRM, пакеты пошли), запись в NAT создаётся этим же трафиком. Параметр нужен там, где сторона за NAT должна быть достижима для входящих пакетов в паузах между запросами: например, когда с VPS обращаются к офисному устройству.

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

Имена важнее адресов: DNS после подключения новой линии

Вернёмся к бухгалтерии. Ей важно, чтобы адрес CRM остался прежним. Но адрес для человека — это имя, а компьютеру нужно получить по нему IP. И вот здесь смена провайдера может незаметно всё испортить: у нового провайдера свои DNS-серверы, которые офисные устройства получают автоматически. Если внутреннее имя CRM разрешается только через DNS, указанный в настройках туннеля, а система спрашивает у DNS провайдера, имя либо не найдётся, либо приведёт на публичный адрес, которого вы не ожидали.

В конфигурации клиента для этого есть поле DNS. По руководству wg-quick, оно задаёт DNS-серверы интерфейса или поисковые домены, а при поднятии и удалении интерфейса wg-quick вызывает resolvconf. Важное следствие: если в вашей системе нет подходящей интеграции (например, нет resolvconf или systemd-resolved), поле может не сработать так, как вы ожидаете. Поведение на Windows, macOS и разных дистрибутивах Linux нельзя считать одинаковым; здесь описан именно сценарий Linux-ноутбука с systemd-resolved.

Проверять надо не догадкой, а командой. Руководство resolvectl описывает resolvectl status как показ действующих глобальных и интерфейсных настроек DNS, а resolvectl query как разрешение имени с указанием протокола и интерфейса. Вторая часть особенно полезна: в выводе видно, через какой интерфейс пришёл ответ.

resolvectl status
resolvectl query crm.example.internal

Имя здесь условное. Подставьте реальное внутреннее имя вашей CRM. Смотрите на два признака: ответ пришёл с интерфейса туннеля, а не с интерфейса нового провайдера, и полученный адрес совпадает с тем, что был до переезда.

Если после переключения сети результат изменился, есть смысл очистить локальный кеш командой resolvectl flush-caches. Но это инструмент диагностики, а не лекарство: очистка кеша убирает только устаревший локальный ответ. Если запись на сервере неверна или маршрут к адресу не ведёт в туннель, повторный запрос вернёт ту же ошибку. Не принимайте исчезновение симптома за исправление причины.

Маршруты: что именно уходит в туннель

Имя разрешилось в нужный адрес. Теперь вопрос: пойдёт ли трафик к этому адресу через туннель? Это определяется параметром AllowedIPs. По wg(8), он задаёт и допустимые адреса входящего трафика от peer, и направления исходящего; IPv4 и IPv6 при этом перечисляются отдельно. Последнее легко упустить: если сервис доступен и по IPv6, а в списке записаны только IPv4-подсети, часть обращений может пойти мимо туннеля.

Руководство wg-quick добавляет ещё одну тонкость: маршруты выводятся из AllowedIPs, а значения 0.0.0.0/0 и ::/0 означают особую обработку шлюза по умолчанию. Это принципиально отличается от маршрутов только к нужным частным подсетям. Разница для переезда вот в чём. Если офис отправляет через VPS весь трафик, смена провайдера затрагивает всё: выход в интернет, потоковое видео, обновления. Если же через туннель идут только подсети серверных ресурсов, то всё прочее уходит напрямую через нового провайдера, и вам нужно проверять лишь узкую часть.

Для репетиции полезно написать себе короткую таблицу ожиданий. Она занимает пять строк, но экономит час разбирательств.

Одно предупреждение о файле конфигурации. По руководству wg-quick, при SaveConfig=true состояние интерфейса сохраняется в файл при выключении, поэтому ваши ручные правки файла могут быть перезаписаны. Если вы правите конфигурацию в день репетиции, сначала проверьте, включён ли этот параметр, иначе исправление исчезнет после перезапуска туннеля, и вы будете искать причину не там.

Первый запрос и сеанс, который уже идёт

Теперь самое тонкое. Новый запрос и давно открытый сеанс ведут себя по-разному, и путать их нельзя.

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

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

Из этого вытекает организационное решение, а не техническое. Время переключения стоит выбирать там, где нет длинных выгрузок, а сотрудников нужно предупредить: если во время смены канала отчёт завис, перезапустить его — нормально. Это честнее, чем обещание «бесшовности».

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

Когда страница открывается, а данные не идут

Особый класс неприятностей: соединение устанавливается, начальные запросы проходят, а как только пошли крупные ответы, всё замирает. Выглядит это пугающе: сеть вроде бы есть, а CRM «думает» бесконечно. Частая причина — размер пакета, то есть MTU.

У туннеля есть накладные расходы, и пакет внутри него должен быть меньше обычного. Если путь через сети нового провайдера оказывается уже, чем ожидалось, слишком крупные пакеты перестают проходить. В норме отправитель узнаёт об этом из служебных сообщений. По RFC 1191 для IPv4 маршрутизатор, которому не помещается пакет с флагом DF, отбрасывает его и присылает ICMP-сообщение «fragmentation needed», после чего отправитель уменьшает оценку. Там же сказано, что PMTU может меняться вслед за маршрутом и относится к пути, а не только к MTU локального Ethernet-интерфейса. Это ключевой момент для переезда: новый провайдер означает новый путь, а значит, прежняя оценка может оказаться неверной.

Для IPv6 механизм аналогичен: RFC 8201 описывает использование ICMPv6 Packet Too Big. Там же честно отмечено, что если фильтрация мешает этим сообщениям дойти, отправитель может не узнать реальный PMTU, и тогда TCP-рукопожатие проходит, а передача данных зависает. Это ровно тот симптом, что мы описали.

Отсюда два вывода. Первый: не отключайте файрвол целиком в попытке «починить сеть». Нужно различать служебные сообщения, необходимые протоколу, и открытие произвольного доступа. Если вы управляете фильтрацией на VPS, разберитесь, какие ICMP-сообщения пропускаются; про логику закрытия лишнего без потери доступа есть отдельный материал: firewall на выделенном сервере.

Второй вывод касается самого значения MTU. Универсального числа, подходящего любому провайдеру, не существует. По руководству wg-quick, если MTU не задан, он определяется по адресам endpoint или маршруту по умолчанию, а явное поле MTU переопределяет этот выбор. Значит, по умолчанию система уже подстраивается под текущий маршрут при поднятии интерфейса. Это хорошо: после смены провайдера достаточно перезапустить туннель, и выбор пересчитается под новые условия. Но автоматика смотрит на то, что видит локально, а не гарантирует чистоту всего пути.

Если на репетиции симптом «зависает на больших ответах» воспроизвёлся, действуйте как экспериментатор, а не как гадалка:

1. Запомните текущее значение MTU интерфейса и поведение: на каком действии зависает.
2. Добавьте в конфигурацию клиента явное поле MTU с немного меньшим значением, чем было. Это обратимый эксперимент: строку можно убрать.
3. Перезапустите туннель и повторите то же действие.
4. Если зависание ушло, зафиксируйте значение и условия, при которых оно помогло. Если нет, верните прежнее состояние и ищите причину в другом месте: в DNS, маршрутах или фильтрации.

Значение, найденное таким замером, годится именно для этой пары «клиент — сеть». Для другого провайдера его придётся подтверждать заново.

Запасной путь: что проверить, пока старая линия ещё жива

Лучшее время для репетиции — период, когда у офиса работают сразу обе линии, или хотя бы когда старый выход ещё не отключён. Тогда у вас есть запасной путь: если на новой линии что-то не так, ноутбук можно вернуть на прежнюю сеть и продолжать работу. Если одновременной работы линий не будет, запасным путём становится мобильная точка доступа телефона: она позволит хотя бы подключиться к VPS и посмотреть состояние сервера, не завися от нового провайдера.

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

Отдельно подумайте о доступе администратора. Если вы управляете сервером только через туннель, а туннель после смены линии не поднялся, у вас не останется входа. Поэтому до переезда убедитесь, что к VPS можно попасть и другим способом, например по SSH напрямую с мобильной сети или через консоль управления, доступную у провайдера хостинга. Какой именно способ доступен, зависит от вашей конфигурации сервера; проверьте его заранее, а не в момент, когда он понадобится.

Если в ходе репетиции вы решили убрать или заменить peer, помните, что по руководству wg(8) peer идентифицируется открытым ключом и удаляется командой wg set ... peer ... remove. Также руководство разделяет изменение работающего интерфейса и изменение конфигурационного файла: это разные действия, а syncconf применяет различия без пересоздания всех peer. Практический смысл: правка на живом интерфейсе не попадёт в файл сама, и наоборот. Запишите, что именно вы поменяли и где, чтобы после перезагрузки сервера не получить сюрприз.

Как выглядит удачная репетиция

Соберём всё в один проход, как он мог бы выглядеть на практике. Условия те же: Linux-ноутбук, прежний endpoint VPS, внутренние имена остаются прежними.

Вы подключаетесь из офисной сети, открываете CRM, фиксируете вывод wg show и ответ resolvectl query. Затем переводите ноутбук на мобильную точку доступа. Через несколько секунд после первого обращения в wg show появляется свежее рукопожатие, а на VPS у клиента виден уже другой endpoint. Имя CRM разрешается в тот же адрес через интерфейс туннеля. Страница открывается. Вы запускаете большую выгрузку и убеждаетесь, что крупные ответы идут, а не замирают. Если где-то на этом пути запнулись, вы знаете, к какому разделу этой статьи вернуться: к NAT и keepalive, к DNS, к маршрутам или к MTU.

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

Если же точка входа пока не определена или вы хотите вынести её на отдельный сервер, под такую роль можно развернуть небольшой VPS и проверить на нём нагрузку своих пользователей. Конфигурации вроде Uab или Heka — это отправная точка для замера, а не готовый ответ о том, сколько человек выдержит туннель; число клиентов, объём передаваемых файлов и шифрование покажут сами измерения.

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