Когда руководство переживает за свои данные (как бы не попали куда не следует), то это или к изучению шифрования, или к покупке кислоты для диска, или к поиску заморских ЦОД. Если выбор пал на перенос сервера подальше из страны, то возникает целый ворох неочевидных проблем с его использованием остальным офисом. В статье будет про сценарий переноса 1С в европейский дата-центр и про настройку "самонаводящегося" IPSec. Ведь дьявол кроется в деталях. В одной из организаций мне довелось заниматься переносом некоторых ее сервисов на немецкий выделенный сервер. Почему выделенный сервер и именно в Германии — не принципиально, поэтому примем как данность. Казалось бы, банальный VPN и удаленный доступ к сервисам — что вообще может пойти не так?  Большая часть пользователей компании работают с тонких клиентов на ферме терминальных серверов, а периметр охраняет роутер с межсетевым экраном D-Link DFL-800 с сотней поднятых туннелей IPsec. Этот же роутер отвечает за резервирование WAN. Для переноса выбрали несколько баз 1С, конфигурация которых осложняется множеством обменов и обработок, которые используют другие БД и сетевые ресурсы. Написано все это уже неизвестно кем, поэтому спросить совета не получилось. Пользователи авторизуются в 1С с использованием Active Directory, что менять не хотелось бы. Из-за всего этого сделать еще один терминальный сервер в Германии – не лучшая идея: работа RDP внутри RDP (тонкие клиенты) оставляет желать лучшего, да и банальная печать на перенаправленных принтерах превращается в квест. Неплохим вариантом могла бы стать виртуализация приложений не базе Citrix XenApp, но после долгосрочной аренды выделенного сервера бюджета оставалось не настолько много.   Чтобы изменения в СУБД и инфраструктуре стремились к нулю, нужно было делать прозрачный VPN для находящегося в тысяче километров сервера. За основу взяли типовой туннель IPSec на базе Windows и ответной части на D-Link. Это достаточно распространенное решение с минимальными вложениями. Осталось ответить на три простых вопроса:  Как перепрописать пути к базам паре десятков пользователей? Как переключить IPsec в случае сбоя основного WAN-канала в офисе? Механизм IPSec в Windows подобной возможности по умолчанию не предлагает. Начнем по порядку. В результате всех махинаций сервер должен стать полноправным членом домена и видеть всю локальную сеть через зашифрованный канал. Общая схема получилась такой (не оригинально, но для общего представления лучше нарисовать):  В качестве исходных данных, для иллюстрации: IP-адреса основного и резервного провайдера офиса 1.2.3.4 и 1.2.3.5; Локальная сеть офиса 192.168.0.0/24; Внутренний адрес D-Link 192.168.0.1; Для установки туннеля нужно выполнить несколько команд на роутере и сервере. На D-Link: Добавим алгоритмы IPsec и IKE: Добавим внешний адрес сервера: Добавим ключ на IPsec: Сам туннель: Активируем настройки: На Windows: Создаем политику, но не назначаем ее: Добавляем действие фильтра: Настраиваем два фильтра, в одну и другую стороны: Создаем два правила политики с для фильтров: Теперь туннель заработал.  Нужно отметить, что при работе с более свежими DFL лучше себя зарекомендовал IPsec средствами брандмауэра Windows. Настройка производится в контексте netsh advfirewall consec. После поднятия туннеля подготовим сетевые параметры сервера с помощью магии wmi, после чего можно добавлять в домен: Получившийся туннель работал на скорости около 24 Mbps при заявленном потолке для VPN в 60 Mbps. Поскольку потолок нужно делить пополам из-за дуплекса – неплохой результат для приемлемой работы 1С. Автоматическое добавление путей к базам 1С было реализовано чудовищным скриптом, построчно заполняющим файл ibases.v8i в профиле пользователя. Такому варианту есть и более удачные альтернативы. Предположим, что у нас есть две базы и две группы безопасности — buh и torg. Тогда механизм автоматического подключения выглядит так: Cоздание двух текстовых файлов в общей папке: buh.v8i и torg.v8i; Для каждого файла нужно дать доступ на чтение только соответствующей группе безопасности; buh.v8i: torg.v8i: Всем пользователям нужно прописать пути к обоим этим файлам с помощью файла 1CEStart.cfg. Можно его положить в профиль пользователя групповыми политиками (%appdata%\1C\1CEStart). При работе всех пользователей на терминальном сервере достаточно положить этот файл в C:\ProgramData\1C\1CEStart. Содержание файла следующее: Теперь пользователи в зависимости от членства в группе безопасности будут иметь определенный набор баз в 1С. При перемещении БД достаточно поменять только содержимое файлов v8i. Но в том проекте решили проявить уважение к истории и решить проблему красиво чуть позже. На помощь временно пришел AutoIT с простеньким скриптом: Возможно на Powershell вышло бы изящнее – тут на вкус и цвет. Когда принципиально удаленные БД стали доступны для работы, настала очередь "шашечек" резервного WAN-подключения. Конечно, можно настроить два туннеля через разных провайдеров, но не хотелось лишний раз нагружать и без того уставшую железку. Нужно было лишь научить IPSec подключаться по другому адресу в случае недоступности основного. Нам поможет простой скрипт CMD: Ставим сценарий в автозапуск каждые пять минут, и вопрос с отказоустойчивым IPSec-подключением на этом решен. Переключение каналов со стороны D-link DFL описывать не буду, там все банально, да и инструкции есть на официальном сайте. Заказчик остался доволен, в отличие от его бухгалтеров. Неторопливая работа 1С из-за недостаточно производительного VPN, конечно, раздражает. Особенно недобрые взгляды отдел ИТ ловил в период сдачи отчетности. Чтобы сделать удаленную 1С более отзывчивой, позже запланирована замена роутера на D-Link DFL-870, в котором обещан гигабитный VPN. Тем не менее, бюджетный перенос баз за границу можно считать состоявшимся. Реактивист-разработчик Android