Когда руководство переживает за свои данные (как бы не попали куда не следует), то это или к изучению шифрования, или к покупке кислоты для диска, или к поиску заморских ЦОД. Если выбор пал на перенос сервера подальше из страны, то возникает целый ворох неочевидных проблем с его использованием остальным офисом. В статье будет про сценарий переноса 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 подобной возможности по умолчанию не предлагает.

• Хватит ли роутеру сил для поддержки еще одного довольно нагруженного туннеля?

Начнем по порядку.

Медленно добавляем машину в домен...

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

После поднятия туннеля подготовим сетевые параметры сервера с помощью магии wmi, после чего можно добавлять в домен:

wmic nicconfig where IPEnabled=TRUE call SetDNSServerSearchOrder ("192.168.0.2","192.168.0.3")

wmic nicconfig call SetDNSSuffixSearchOrder (mylocaldomain.com)

Получившийся туннель работал на скорости около 24 Mbps при заявленном потолке для VPN в 60 Mbps. Поскольку потолок нужно делить пополам из-за дуплекса – неплохой результат для приемлемой работы 1С.

Заменить всем пути к базам и не сойти с ума

Автоматическое добавление путей к базам 1С было реализовано чудовищным скриптом, построчно заполняющим файл ibases.v8i в профиле пользователя. Такому варианту есть и более удачные альтернативы.

[Бухгалтерия]

Connect=Srvr="servername";Ref="buh";

ClientConnectionSpeed=Normal

App=ThickClient

WA=1

Version=8.3

[Торговля]

Connect=Srvr="servername";Ref="torg";

ClientConnectionSpeed=Normal

App=ThickClient

WA=1

Version=8.3

CommonInfoBases=\путь_к_общей_папкеbuh.v8i
CommonInfoBases=\путь_к_общей_папкеtorg.v8i

Но в том проекте решили проявить уважение к истории и решить проблему красиво чуть позже. На помощь временно пришел AutoIT с простеньким скриптом:

#include <File.au3>

;Собираем в массив файлы конфигурации 1с
local $aArray = _FileListToArrayRec ("путь к DFS-шаре с профилями пользователей", "ibases.v8i",1,1,0,2)
if @error <> 1 then

;Перебираем массив
for $i=1 to $aArray[0]
  $iLine=0
 While 1
    $iLine += 1
    $sLine = FileReadLine($aArray[$i],$iLine )
    If @error = -1 Then ExitLoop

;если находим в строке конфига нужную нам базу…  
 If StringInStr($sLine, 'Ref="Нужная база ";')  Then
;…То меняем в имя сервера   
 _ReplaceStringInFile($aArray[$i],$sLine,StringReplace($sLine,"Имя старого сервера","Имя нового сервера"))
    EndIf
WEnd
Next
EndIf

Возможно на Powershell вышло бы изящнее – тут на вкус и цвет.

Не отпускай!

Когда принципиально удаленные БД стали доступны для работы, настала очередь "шашечек" резервного WAN-подключения.

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

Нам поможет простой скрипт CMD:

@echo off
Rem задаем адреса IP основного и резервного канала.

Set office1=1.2.3.4
Set office2=4.3.2.1

Rem проверяем туннель пингом локального адреса:
Ping 10.0.0.10 -n 3
Rem если адрес недоступен
if errorlevel 1 (

rem проверяем доступность основного канала интернет
ping %office1% -n 3
rem если и он не доступен – проверяем резервный канал

if errorlevel 1 (
ping %office2% -n 3
rem если уж и он недоступен – значит в офисе проблемы. Пишем в лог

if errorlevel 1 (
echo %date% %time% office down >> check-ipsec.txt

) else (
Rem если же резервный канал доступен – переключаем туннель
echo %date% %time% reset tun office2 >>check-ipsec.txt
netsh ipsec static set rule id=1 policy=ipsec tunnel=%office2%
netsh ipsec static set policy name=ipsec assign=no
netsh ipsec static set policy name=ipsec assign=yes
ping 10.0.0.10 -n 3
)

) else (
Rem если же основной канал в порядке, а туннеля нет 
rem значит нужно переключить туннель обратно, или он просто завис.
echo %date% %time% reset tun office1 >> check-ipsec.txt
netsh ipsec static set rule id=1 policy=ipsec tunnel=%office1%
netsh ipsec static set policy name=ipsec assign=no
netsh ipsec static set policy name=ipsec assign=yes
ping 10.0.0.10 -n 3
)
)

Ставим сценарий в автозапуск каждые пять минут, и вопрос с отказоустойчивым IPSec-подключением на этом решен. Переключение каналов со стороны D-link DFL описывать не буду, там все банально, да и инструкции есть на официальном сайте.

Но бухгалтеры негодуют

Заказчик остался доволен, в отличие от его бухгалтеров. Неторопливая работа 1С из-за недостаточно производительного VPN, конечно, раздражает. Особенно недобрые взгляды отдел ИТ ловил в период сдачи отчетности. Чтобы сделать удаленную 1С более отзывчивой, позже запланирована замена роутера на D-Link DFL-870, в котором обещан гигабитный VPN.

Тем не менее, бюджетный перенос баз за границу можно считать состоявшимся.

Автор: Сервер Молл

Источник