Як я бази 1С у Німеччині ховав

<img src=«habrastorage.org/files/182/a44/0a1/182a440a12464975bea0de7e4135b549.jpg» alt=«image» alt text"/>
Коли керівництво переживає за свої дані (як би не потрапили куди не слід), то це або вивчення шифрування, або до купівлі кислоти для диска, або до пошуку заморських ЦОД. Якщо вибір припав на перенесення сервера подалі з країни, то виникає цілий оберемок неочевидних проблем з його використанням іншим офісом. У статті про сценарій перенесення 1С в європейський дата-центр і про налаштування "самонаводящегося" IPSec.
Адже диявол криється в деталях.
В одній з організацій мені довелося займатися перенесенням деяких її сервісів на німецький виділений сервер. Чому виділений сервер і саме в Німеччині — не принципово, тому приймемо як даність. Здавалося б, банальний VPN і віддалений доступ до сервісів — що взагалі може піти не так?
Вивчаємо пацієнта
Велика частина користувачів працюють з тонких клієнтів на фермі термінальних серверів, а периметр охороняє роутер з міжмережевим екраном D-Link DFL-800 з сотнею піднятих тунелів IPsec. Цей роутер відповідає за резервування WAN.
Для перенесення вибрали кілька баз 1С, конфігурація яких ускладнюється безліччю обмінів та обробок, які використовують інші БД та мережеві ресурси. Написано все це вже невідомо ким, тому запитати ради не вийшло. Користувачі авторизуйтесь в 1С з використанням Active Directory, що міняти не хотілося б.
З-за всього цього зробити ще один термінальний сервер в Німеччині – не найкраща ідея: робота RDP всередині RDP (тонкі клієнти) залишає бажати кращого, та й банальна друк на перенаправлених принтерах перетворюється в квест. Непоганим варіантом могла б стати віртуалізація додатків на базі Citrix XenApp, але після довгострокової оренди виділеного сервера бюджету залишалося не так багато.
<img src=«habrastorage.org/files/d9f/579/7bd/d9f5797bd9a04109b533b97ac8870e2e.jpg» alt=«image» alt text"/>
Щоб зміни в СУБД і інфраструктурі прагнули до нуля, потрібно було робити прозорий VPN для знаходиться в тисячі кілометрів сервера. За основу взяли типової тунель IPSec на базі Windows і відповідної частини на D-Link. Це досить поширене рішення з мінімальними вкладеннями.
Залишилося відповісти на три простих питання:
  • Як перепрописать шляху до баз парі десятків користувачів?
  • Як перемкнути IPsec у разі збою основного WAN-каналу в офісі? Механізм IPSec в Windows подібної можливості за замовчуванням не пропонує.
  • Вистачить роутеру сил для підтримки ще одного досить навантаженого тунелю?
Почнемо по порядку.
Повільно додаємо машину в домен...
В результаті всіх махінацій сервер повинен стати повноправним членом домену і бачити всю локальну мережу через зашифрований канал. Загальна схема вийшла такою (не оригінально, але для загального уявлення краще намалювати):
<img src=«habrastorage.org/files/3bd/dae/d6b/3bddaed6b92d499c8525e82833d6bfde.jpg» alt=«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
Тепер тунель заробив.
<img src=«habrastorage.org/files/cb4/0aa/c16/cb40aac1617e45e9b3fc77c97d670209.jpg» alt=«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. Створення двох текстових файлів в загальній папці: 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%\1C\1CEStart). При роботі всіх користувачів на термінальному сервері досить покласти цей файл C:\ProgramData\1C\1CEStart. Зміст файлу наступне:
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.
Тим не менш, бюджетний перенесення баз за кордон можна вважати успішною.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.