Как я базы 1С в Германии прятал

в 11:13, , рубрики: , ipsec, Блог компании Сервер Молл, выделенный сервер, ит-инфраструктура, Серверное администрирование, Сетевые технологии, хостинг

image alt text

Когда руководство переживает за свои данные (как бы не попали куда не следует), то это или к изучению шифрования, или к покупке кислоты для диска, или к поиску заморских ЦОД. Если выбор пал на перенос сервера подальше из страны, то возникает целый ворох неочевидных проблем с его использованием остальным офисом. В статье будет про сценарий переноса 1С в европейский дата-центр и про настройку "самонаводящегося" IPSec.

Ведь дьявол кроется в деталях.

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

Изучаем пациента

Большая часть пользователей компании работают с тонких клиентов на ферме терминальных серверов, а периметр охраняет роутер с межсетевым экраном D-Link DFL-800 с сотней поднятых туннелей IPsec. Этот же роутер отвечает за резервирование WAN.

Для переноса выбрали несколько баз 1С, конфигурация которых осложняется множеством обменов и обработок, которые используют другие БД и сетевые ресурсы. Написано все это уже неизвестно кем, поэтому спросить совета не получилось. Пользователи авторизуются в 1С с использованием Active Directory, что менять не хотелось бы.

Из-за всего этого сделать еще один терминальный сервер в Германии – не лучшая идея: работа RDP внутри RDP (тонкие клиенты) оставляет желать лучшего, да и банальная печать на перенаправленных принтерах превращается в квест. Неплохим вариантом могла бы стать виртуализация приложений не базе Citrix XenApp, но после долгосрочной аренды выделенного сервера бюджета оставалось не настолько много.

image alt text

Чтобы изменения в СУБД и инфраструктуре стремились к нулю, нужно было делать прозрачный VPN для находящегося в тысяче километров сервера. За основу взяли типовой туннель IPSec на базе Windows и ответной части на D-Link. Это достаточно распространенное решение с минимальными вложениями.

Осталось ответить на три простых вопроса:

  • Как перепрописать пути к базам паре десятков пользователей?

  • Как переключить IPsec в случае сбоя основного WAN-канала в офисе? Механизм IPSec в Windows подобной возможности по умолчанию не предлагает.

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

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

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

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

image alt text

Про настройку Windows и DFL под IPSec написано уже достаточно, но все же оставлю инструкцию под спойлером

В качестве исходных данных, для иллюстрации:

  • IP-адреса основного и резервного провайдера офиса 1.2.3.4 и 1.2.3.5;

  • Локальная сеть офиса 192.168.0.0/24;

  • Внутренний адрес D-Link 192.168.0.1;

  • Внешний адрес сервера 5.4.3.2.

Для установки туннеля нужно выполнить несколько команд на роутере и сервере.

На D-Link:

  1. Добавим алгоритмы IPsec и IKE:

    add IKEAlgorithms Medium DES3Enabled=True SHA1Enabled=True 
    add IPsecAlgorithms Medium  DES3Enabled=True SHA1Enabled=True

  2. Добавим внешний адрес сервера:

    add IP4Address IP_Remote Address=5.4.3.2

  3. Добавим ключ на IPsec:

    add PSK Key_Remote Type=ASCII PSKAscii=MegaSecureKey Comments=MegaSecureKey

  4. Сам туннель:

    add IPsecTunnel Remote_Server LocalNetwork=InterfaceAddresses/lannet RemoteNetwork=IP_Remote RemoteEndpoint=IP_Remote IKEAlgorithms=Medium IPsecAlgorithms=Medium AuthMethod=PSK PSK=Key_Remote AddRouteToRemoteNet=True PFS=PFS NATTraversal=Off KeepAlive=Manual KeepAliveSourceIP=lan_ip KeepAliveDestinationIP=IP_Remote AutoInterfaceNetworkRoute=False

  5. Активируем настройки:

    activate

  6. И подтверждаем их, чтобы умный роутер не откатил изменения:
    commit

На Windows:

  1. Создаем политику, но не назначаем ее:

    netsh ipsec static add policy ipsec assign=no mmpfs=yes mmsec="3DES-SHA1-2"

  2. Добавляем действие фильтра:

    netsh ipsec static add filteraction name=ipsec action=negotiate qmpfs=yes qmsec="ESP[3DES,SHA1]:3600s"

  3. Настраиваем два фильтра, в одну и другую стороны:

    netsh ipsec static add filter filterlist=win2dfl srcaddr=5.4.3.2 dstaddr=192.168.0.0 dstmask=255.255.255.0  mirrored=no

    netsh ipsec static add filter filterlist=dfl2win dstaddr=5.4.3.2 srcaddr=192.168.0.0 srcmask=255.255.255.0  mirrored=no

  4. Создаем два правила политики с для фильтров:

    netsh ipsec static add rule name=win2dfl policy=ipsec filterlist=win2dfl filteraction=ipsec tunnel=1.2.3.4 psk=MegaSecureKey

    netsh ipsec static add rule name=dfl2win policy=ipsec filterlist=dfl2win filteraction=ipsec tunnel=5.4.3.2 psk=MegaSecureKey

  5. Применяем политику:
    
    netsh ipsec static set policy name=ipsec assign=yes

Теперь туннель заработал.

image alt text

Нужно отметить, что при работе с более свежими DFL лучше себя зарекомендовал IPsec средствами брандмауэра Windows. Настройка производится в контексте netsh advfirewall consec.

После поднятия туннеля подготовим сетевые параметры сервера с помощью магии 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 в профиле пользователя. Такому варианту есть и более удачные альтернативы.

Например, удобен штатный механизм 1С + безопасность NTFS.

Предположим, что у нас есть две базы и две группы безопасности — buh и torg. Тогда механизм автоматического подключения выглядит так:

  1. Cоздание двух текстовых файлов в общей папке: buh.v8i и torg.v8i;

  2. Для каждого файла нужно дать доступ на чтение только соответствующей группе безопасности;

  3. Содержание файлов следующее:

buh.v8i:

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

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

ClientConnectionSpeed=Normal

App=ThickClient

WA=1

Version=8.3

torg.v8i:

[Торговля]

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

ClientConnectionSpeed=Normal

App=ThickClient

WA=1

Version=8.3

Всем пользователям нужно прописать пути к обоим этим файлам с помощью файла 1CEStart.cfg. Можно его положить в профиль пользователя групповыми политиками (%appdata%1C1CEStart). При работе всех пользователей на терминальном сервере достаточно положить этот файл в C:ProgramData1C1CEStart. Содержание файла следующее:

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

Теперь пользователи в зависимости от членства в группе безопасности будут иметь определенный набор баз в 1С. При перемещении БД достаточно поменять только содержимое файлов 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.

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

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

Источник

Поделиться

* - обязательные к заполнению поля