Изоляция серверов

Перед тем, как переносить сервера куда либо, необходимо позаботиться об их доступности. Если сервера являются частью локальной сети, в большинстве случаев ее структура будет примерно следующей:

При этом на пограничном маршрутизаторе обязательно настроено какое то количество правил, позволяющих использовать из интернета те или иные службы на серверах.

В рассмотренной конкретной ситуации в качестве пограничного маршрутизатора локальной офисной сети используется Mikrotik, а в качестве маршрутизатора для сети серверов DLink DFL-870 с операционной системой NetDefendOS.

Для того, чтобы сеть оказалась готова к миграции ее необходимо привести к следующему виду:

Здесь в качестве адреса WAN интерфейса нового маршрутизатора назначается один из адресов LAN, на нем настраивается NAT, Port Forwarding (SAT в терминах NetDefendOS) и VPN сервер для установления связи с основной LAN в будущем. Имеет смысл сразу определиться с ДНС именем внешнего интерфейса, которое получит после переезда в ДЦ новый маршрутизатор и все манипуляции проводить используя его и настройки локального ДНС. Это позволит после переноса серверов просто настроить зону ДНС в интернете, а не менять IP везде где он используется. В новой серверной LAN необходимо использовать отдельную подсеть IP адресов, отличную от основной сети LAN. На основном маршрутизаторе также понадобится настроить маршрут в новую подсеть.

Перенос правил фаерволла

Для того, чтобы получить с Mikrotik список файлов необходимо выполнить команду ip firewall export file=rules.rules в терминале (подойдет тот, который в вебинтерфейсе) и скачать файл rules.rules из раздела Files в вебинтерфейсе. Главным образом, в этом файле интерес представляет секция с правилами NAT, они имеют примерно следующий вид:

add action=dst-nat chain=dstnat dst-address=1.2.3.4 dst-port=21100-21110 protocol=tcp to-addresses=192.168.0.55 to-ports=21100-21110
add action=dst-nat chain=dstnat dst-address=1.2.3.4 dst-port=9090 protocol=tcp to-addresses=192.168.0.55 to-ports=9090
add action=dst-nat chain=dstnat dst-address=1.2.3.4 dst-port=8080 protocol=tcp to-addresses=192.168.0.81 to-ports=8080
add action=dst-nat chain=dstnat dst-address=1.2.3.4 dst-port=3333 protocol=tcp to-addresses=192.168.0.55 to-ports=3333
add action=dst-nat chain=dstnat dst-address=1.2.3.4 dst-port=11080 protocol=tcp to-addresses=192.168.0.111 to-ports=11080
add action=dst-nat chain=dstnat dst-address=1.2.3.4 dst-port=6142 protocol=tcp to-addresses=192.168.0.99 to-ports=6142
add action=dst-nat chain=dstnat dst-address=1.2.3.4 dst-port=11145 protocol=tcp to-addresses=192.168.0.99 to-ports=11145
add action=dst-nat chain=dstnat dst-address=1.2.3.4 dst-port=990 protocol=tcp to-addresses=192.168.0.21 to-ports=990
add action=dst-nat chain=dstnat dst-address=1.2.3.4 dst-port=65000-65100 protocol=tcp to-addresses=192.168.0.21 to-ports=65000-65100

Команды для конвертации списка правил Mikrotik в список правил для NetDefendOS, добавление правил. Из-за специфики ОС NetDefendOS прежде чем создавать правила, необходимо создать службы (Services), слушающие порты. Это можно сделать так:

cat ./rules_.rsc | grep chain=dstnat | awk -F' ' '{\
dstport = "";
proto = "";
for(i = 1; i <= NF; i++) {\
split($i, a, "=");\
if(a[1] == "dst-port")\
dstport = a[2];\
if(a[1] == "protocol")\
proto = a[2];\
}\
print "add Service ServiceTCPUDP Service_"dstport"_"proto" DestinationPorts="dstport" Type="toupper(proto);\}’

После получения вывода можно выполнить его на маршрутизаторе, подключившись к нему по ssh. Полученный набор команд выглядит примерно следующим образом:

После добавления сервисов можно убедиться, что они появились, зайдя в веб-интерфейс устройства (раздел Services / General / Objects / Device ):

Также существует еще одна особенность — чтобы работала трансляция портов необходимо создавать два правила — первое для создания SAT (Static Address Translation), второе — для разрешения подключения. Команда для генерации выглядит так:

cat ./rules_20191122.rsc | sed 's/10.10.0/172.21.99/g' | grep chain=dstnat | awk -F' ' '{\
dstport = "";\
proto = "";\
toaddr = "";\
toport = "";\
for(i = 1; i <= NF; i++) {\
split($i, a, "=");\
if(a[1] == "dst-port")\
dstport = a[2];\
if(a[1] == "protocol")\
proto = a[2];\
if(a[1] == "to-addresses")\
toaddr = a[2];\
if(a[1] == "to-ports")\
toport = a[2];\
}\
print "add IPRule Action=SAT Service=Service_"dstport""proto" SourceInterface=any SourceNetwork=all-nets DestinationInterface=core DestinationNetwork=all-nets SATTranslate=DestinationIP SATTranslateToIP="toaddr" SATTranslateToPort="topo$ print "add IPRule Action=Allow Service=Service"dstport""proto" SourceInterface=any SourceNetwork=all-nets DestinationInterface=core DestinationNetwork=all-nets Name=Allow"dstport""proto""toport;\
}'

Соответственно, на выходе получается 2 правила для каждого из сервисов. Следует исправить диапазоны портов назначения на первый порт из диапазона, иначе будет ошибка как на скриншоте:

После всех манипуляций изоляция почти выполнена, остается настроить маршрутизацию в новую подсеть с основного маршрутизатора через VPN-тоннель и раздать серверам новый IP адреса. Старые при этом можно оставить на некоторое время.

Переназначение IP адресов

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

Также следует позаботиться о наличии записей узлов с новыми адресами на ДНС сервере, если они не обновляются там динамически.

Финальной частью переназначения адресов должно стать переназначение маршрутизатора и удаление старого адреса. К этому этапу следует приступать после связывания маршрутизаторов тоннелем.

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

Настройка VPN-тоннеля

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

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

В данном случае была применена альтернативная технология, проверенная и активно используемая в работе как на офисном Mikrotik, так и на pfSense. Следует учитывать, что не имея подобной возможности, проблема с запуском основного соединения может оказаться фатальной, поэтому следует заранее позаботиться о ее наличии.

Выбор конкретных технологий для организации тоннелей — дело требований и предпочтений, главное — предусмотреть возможность установить связь альтернативным способом и прибегнуть к ней если что-то пойдет не по плану.

Что в итоге должно получиться

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

После всех проделанных манипуляций, размещения отдельного сервера и физического переноса серверного парка в ДЦ сеть примет вид:

Если настроена зона ДНС и в ней присутствует офисный IP адрес, его необходимо изменить на новый, выделенный ДЦ. С этого момента необходимо также отключить форвардинг теперь уже не нужных портов на офисном маршрутизаторе чтобы не снижать уровень защищенности системы.

Связь с серверами, которые ранее были доступны из интернета, работает благодаря перенесенным правилам, а для клиентов из основной локальной сети, использующих внутренние службы, такие как LDAP и SMB, они продолжают быть доступными благодаря VPN туннелю между сетями.