Перенос серверов с сохранением существующей IP-адресации на MikroTik

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

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

Разберём эту схему на MikroTik: с действующим SSTP между офисами, одним кабелем до серверной и публикацией веб-сервисов через новый внешний IP. Имена и адреса в примере условные. Переключение серверов выполняется последовательно в согласованное окно работ.

Исходная схема и ограничения

В офисе МСК работает сеть 10.40.8.0/22. Часть серверов нужно перенести в офис СПб, где уже есть своя сеть 10.50.0.0/24. Удалённые сотрудники подключаются по VPN к роутеру офиса МСК.

Параметр	Офис МСК	Офис СПб
Локальная сеть	`10.40.8.0/22`	`10.50.0.0/24`
Действующий LAN адрес роутера	`10.40.9.1/22`	`10.50.0.1/24`
LAN интерфейс в примере	`bridge-lan`	`bridge-lan`
Адрес в SSTP	`10.255.0.1`	`10.255.0.2`
VPN-пользователи	`10.60.0.0/24`	Через офис МСК
Внешний IP	`198.51.100.10`	`203.0.113.10`

Переносим два узла:

Сервер	Сохраняемый адрес	Новый основной шлюз
Файловый	`10.40.9.150/22`	`10.40.9.254`
Веб-сервисы	`10.40.10.45/22`	`10.40.9.254`

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

Считаем, что WAN и SSTP уже работают. На роутере МСК есть маршрут 10.50.0.0/24 через 10.255.0.2. На роутере СПб — маршруты 10.40.8.0/22 и 10.60.0.0/24 через 10.255.0.1. Если их нет, сначала нужно настроить обычную связь между площадками.

Мало просто добавить маршрут на роутере

Компьютер 10.40.9.20/22 считает сервер 10.40.10.45 соседом в своей подсети. Вместо отправки пакета основному шлюзу он ищет MAC сервера через ARP. После переезда сервер больше не отвечает в старом Ethernet-сегменте. Маршрут на роутере не поможет, пока компьютер не передаст ему пакет.

Поэтому на LAN интерфейсе роутера МСК включают Proxy ARP. Роутер отвечает своим MAC на запрос о перенесённом сервере и принимает предназначенный ему трафик. Затем направляет пакет через SSTP по маршруту /32.

Обратная ситуация возникает в офисе СПб: перенесённый сервер с маской /22 также ищет оставшиеся компьютеры офиса МСК через ARP. На эти запросы отвечает роутер СПб. Получается маршрутизируемая связь между двумя физическими сегментами с сохранённой адресацией.

Режим Proxy ARP описан в документации MikroTik и RFC 1027. Здесь нужен proxy-arp: удалённые адреса доступны через другой интерфейс, SSTP. Режим local-proxy-arp предназначен для другого случая — обмена через тот же интерфейс.

Одного кабеля до серверной достаточно

Две IP-подсети могут работать в одном Ethernet-сегменте. Поэтому серверы можно подключить к существующему коммутатору офиса СПб, а дополнительный адрес шлюза назначить действующему мосту bridge-lan.

Выделять отдельный порт MikroTik или прокладывать второй кабель для этого не требуется. Важно, чтобы uplink и серверные порты действительно находились в одном L2 сегменте. На управляемом коммутаторе это зависит от VLAN; на гипервизоре — ещё и от настроек виртуального коммутатора.

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

Подготовка перед переключением

Зафиксируйте адрес, маску, шлюз и DNS каждого сервера, действующие маршруты, правила NAT и публикации приложений. Проверьте резервные копии серверов и доступ к их консолям. Новый шлюз 10.40.9.254 должен быть свободен на обеих площадках; отсутствие ответа на ping этого не доказывает.

На каждом MikroTik сохраните экспорт. Для RouterOS 7:

/export file=before-server-move

Для RouterOS 6 используйте вариант со скрытием чувствительных полей:

/export hide-sensitive file=before-server-move

Дополнительно сохраните бинарную резервную копию:

/system backup save name=before-server-move

Скачайте файлы с роутеров. Бинарная копия содержит чувствительные данные и требует защищённого хранения.

При удалённой работе включите Safe Mode сочетанием Ctrl+X. Применяйте изменения небольшими этапами. После проверки повторное Ctrl+X фиксирует их; при аварийном завершении управляющей сессии изменения откатываются. Настройки серверов и физический перенос Safe Mode не отменяет. Подробности — в Configuration Management.

Команды ниже дополняют существующую конфигурацию. Перед каждым add проверяйте, нет ли уже такой записи. Целиком вставлять статью в терминал не нужно.

Шлюз и маршрутизация на новой площадке

На роутере СПб назначьте дополнительный адрес существующему мосту:

/ip address
add address=10.40.9.254/32 network=10.40.9.254 \
    interface=bridge-lan comment="KB-MOVE server gateway"

/interface bridge
set [find where name="bridge-lan"] arp=proxy-arp

На LAN мосту роутера МСК также включите Proxy ARP:

/interface bridge
set [find where name="bridge-lan"] arp=proxy-arp

Если LAN на вашей площадке назначен физическому интерфейсу, настройку ARP меняют на нём через /interface ethernet. Если адрес находится на мосту, настраивать нужно сам мост.

В WinBox настройка расположена в свойствах соответствующего интерфейса: для моста Bridge → нужный мост → ARP → proxy-arp. Ориентируйтесь на интерфейс, которому принадлежит LAN адрес.

Почему на роутере /32, а на сервере /22

/32 — маска 255.255.255.255, один адрес. Здесь она позволяет добавить шлюз, не объявляя всю старую подсеть локально подключённой к роутеру СПб.

Если назначить ему 10.40.9.254/22, появится connected-маршрут 10.40.8.0/22 в локальный мост. Для этого же префикса он получит преимущество перед статическим маршрутом через SSTP, и роутер начнёт искать оставшиеся в офисе МСК узлы локально.

Сервер сохраняет /22, то есть 255.255.252.0, и считает новый шлюз своим соседом. Например, для 10.40.10.45/24 адрес 10.40.9.254 уже находится вне локальной подсети — такая маска не соответствует выбранной схеме.

В WinBox у адреса роутера должны быть Address = 10.40.9.254/32, Network = 10.40.9.254. Поле Network содержит адрес, а не маску. Вписывать туда 255.255.255.255 вместо значения /32 нельзя. Назначение этих полей описано в IP Addressing.

Какие маршруты нужны на обеих площадках

Роутер	Назначение	Куда отправлять
МСК	Каждый перенесённый сервер `/32`	В SSTP, через `10.255.0.2`
МСК	Новый шлюз `10.40.9.254/32`	В SSTP, через `10.255.0.2`
СПб	Каждый перенесённый сервер `/32`	В локальный `bridge-lan`
СПб	Остальная сеть `10.40.8.0/22`	В SSTP, через `10.255.0.1`
СПб	VPN-пользователи `10.60.0.0/24`	В SSTP, через `10.255.0.1`

Подготовьте на роутере МСК отключённые маршруты к серверам:

/ip route
add dst-address=10.40.9.150/32 gateway=10.255.0.2 disabled=yes \
    comment="KB-MOVE file via SPb"
add dst-address=10.40.10.45/32 gateway=10.255.0.2 disabled=yes \
    comment="KB-MOVE web via SPb"
add dst-address=10.40.9.254/32 gateway=10.255.0.2 \
    comment="KB-MOVE gateway via SPb"

На роутере СПб также подготовьте отключённые маршруты:

/ip route
add dst-address=10.40.9.150/32 gateway=bridge-lan \
    pref-src=10.40.9.254 disabled=yes comment="KB-MOVE file local"
add dst-address=10.40.10.45/32 gateway=bridge-lan \
    pref-src=10.40.9.254 disabled=yes comment="KB-MOVE web local"

Здесь gateway=bridge-lan допустим, потому что серверы непосредственно подключены к этому Ethernet-сегменту: роутер сможет узнать их MAC через ARP. Такой способ не подходит для назначения, расположенного за ещё одним роутером.

Маршрут /32 выбирается для конкретного сервера, а /22 продолжает обслуживать остальные адреса. Сначала учитывается длина префикса; меньшая distance у connected /22 не отменяет более точный /32. Эти правила и ограничения для интерфейса в качестве gateway описаны в IP Routing.

Дополнительный маршрут к 10.40.9.254/32 на роутере МСК нужен для доступа к самому новому шлюзу и для ответов на диагностику с этого адреса. pref-src в локальных маршрутах СПб выбирает адрес для пакетов самого роутера; адреса транзитных клиентов он не подменяет.

Firewall и NAT между офисами

Правильная таблица маршрутизации ещё не означает, что firewall разрешает нужные соединения. На обоих роутерах проверьте цепочку forward: доступ из разрешённых LAN и VPN к серверным сервисам, необходимые подключения в обратном направлении и обработку established,related. На Windows проверьте также область удалённых адресов в правилах брандмауэра: разрешение только для локальной подсети может не включать офис СПб и VPN-пользователей.

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

Если существующий masquerade применяется ко всему трафику, добавьте на обоих роутерах исключение для внутренних сетей выше этих правил:

/ip firewall address-list
add list=KB-INTERNAL address=10.40.8.0/22
add list=KB-INTERNAL address=10.50.0.0/24
add list=KB-INTERNAL address=10.60.0.0/24

/ip firewall nat
add chain=srcnat action=accept src-address-list=KB-INTERNAL \
    dst-address-list=KB-INTERNAL place-before=0 \
    comment="KB-MOVE no NAT internal"

Это исключение из NAT. Оно не разрешает соединения в firewall filter. Если внутренний трафик уже исключён из трансляции или все исходящие правила ограничены WAN, дополнительное исключение может не требоваться.

Переключайте по одному серверу

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

Для файлового сервера порядок такой:

Отключить его сетевое подключение на площадке МСК и перенести на площадку СПб.
Через консоль оставить 10.40.9.150/22, заменить основной шлюз на 10.40.9.254, проверить DNS.
На роутере СПб включить локальный маршрут.
Проверить связь сервера с новым шлюзом, затем включить маршрут на роутере МСК.

Команда на роутере СПб:

/ip route enable [find where comment="KB-MOVE file local"]
/ping 10.40.9.150 src-address=10.40.9.254 count=4

Команда на роутере МСК:

/ip route enable [find where comment="KB-MOVE file via SPb"]

При разрешённом ICMP ожидается ответ от сервера. Если ответа нет, сначала проверяйте локальный участок СПб: подключение к нужному сегменту, IP, маску, шлюз, активность /32 и брандмауэр ОС. До проверки этого участка не стоит менять настройки туннеля.

После проверки файлового сервиса переходите к веб-серверу по тому же порядку, используя его IP и комментарии KB-MOVE web local и KB-MOVE web via SPb. Доменные Windows-серверы должны продолжать использовать DNS своей Active Directory.

Для VPN-пользователей дополнительно проверьте маршрут на клиенте: серверные адреса должны уходить в VPN. На роутере СПб должен быть обратный маршрут к их пулу через МСК. Подключённый VPN без этих маршрутов не обеспечивает доступ к приложениям.

Доступ в интернет для серверов

Чтобы исходящие подключения серверов использовали провайдера СПб, нужны действующий default route, разрешение в forward и подходящий srcnat. Если существующее WAN правило уже охватывает перенесённые адреса, отдельное правило не добавляйте.

Пример для двух серверов на роутере СПб:

/ip firewall address-list
add list=KB-MOVED address=10.40.9.150/32
add list=KB-MOVED address=10.40.10.45/32

/ip firewall nat
add chain=srcnat action=masquerade src-address-list=KB-MOVED \
    out-interface=ether1 comment="KB-MOVE internet via SPb"

В списке указаны отдельные адреса /32, поскольку переносятся конкретные узлы. Объединять их с оставшимися серверами в правило на целую /24 не требуется. Ограничение out-interface=ether1 сохраняет внутренний обмен через SSTP без этого masquerade.

Публикация веб-сервисов после смены DNS

Допустим, имя service.example.net раньше указывало на внешний IP офиса МСК. После переноса его A-запись заменили на 203.0.113.10, адрес роутера СПб. DNS направляет клиента к новой площадке; проброс портов на ней настраивается отдельно.

Сначала проверьте реальные привязки IIS или другого веб-сервера. На Windows список TCP-соединений и слушающих портов показывает команда:

netstat -ano -p tcp

Найдите нужные локальные порты в состоянии LISTENING. В нашем примере внутренние и внешние порты совпадают:

Внешний адрес и TCP-порт	Внутренний адрес и TCP-порт
`203.0.113.10:4000`	`10.40.10.45:4000`
`203.0.113.10:4001`	`10.40.10.45:4001`
`203.0.113.10:5000`	`10.40.10.45:5000`
`203.0.113.10:5001`	`10.40.10.45:5001`

Если приложение слушает 4000, перенаправление на 80 или 443 приведёт к другому сервису либо к отказу соединения. Два проброса одного внешнего порта с одинаковыми условиями также не распределяют запросы между сайтами: срабатывает первое совпавшее завершающее правило.

На роутере СПб проверьте действующие записи:

/ip firewall nat print detail where chain=dstnat

Отключите только конфликтующие правила для публикуемых адреса и портов, предварительно сохранив их параметры. Затем добавьте один DNAT для всей четвёрки:

/ip firewall nat
add chain=dstnat action=dst-nat in-interface=ether1 \
    dst-address=203.0.113.10 protocol=tcp \
    dst-port=4000,4001,5000,5001 to-addresses=10.40.10.45 \
    place-before=0 comment="KB-MOVE public web"

Без to-ports номера портов сохраняются. Если внутренние порты отличаются от внешних, создайте отдельные правила с соответствующими значениями to-ports. Примеры трансляции приведены в документации NAT в RouterOS.

Для разрешения публикации в filter используйте правило, ограниченное сервером и нужными портами:

/ip firewall filter
add chain=forward action=accept in-interface=ether1 \
    connection-nat-state=dstnat protocol=tcp \
    dst-address=10.40.10.45 dst-port=4000,4001,5000,5001 \
    comment="KB-MOVE allow public web"

После добавления разместите его перед правилами forward, которые блокируют этот доступ, с учётом действующей политики защиты. Простое добавление в конец после запрета не поможет. Также обеспечьте пропуск ответного трафика established,related.

Для публикации серверного сервиса используется forward; цепочка input относится к самому роутеру. Подробнее — в документации по firewall filter.

Новый DNAT работает, если запросы действительно приходят на WAN СПб, сервер доступен локально и его ответы возвращаются через роутер СПб. Основной шлюз 10.40.9.254 обеспечивает этот путь в рассматриваемой схеме. Дополнительный srcnat для обычных внешних входящих соединений не нужен.

Если нужно оставить прежний внешний IP

Тогда DNAT остаётся на роутере МСК, а трафик к серверу идёт через SSTP. Потребуется обеспечить и возврат через МСК: специальной маршрутизацией ответов либо узким srcnat для этих опубликованных соединений в адрес стороны МСК в туннеле. Требование согласованного пути через NAT для пакетов одной сессии рассматривается в RFC 3022.

Вариант со srcnat проще, но сервер перестаёт видеть исходные адреса внешних клиентов. Поэтому сохранение старого публичного IP — отдельная схема публикации. После перевода DNS на внешний IP СПб обычный внешний доступ уже не требует прохождения через роутер МСК.

Если снаружи работает, а из офиса СПб — нет

Правило выше ограничено in-interface=ether1, поэтому обращения из местной LAN к публичному адресу под него не попадут. Для сотрудников можно настроить внутренний DNS, возвращающий для service.example.net адрес 10.40.10.45. Порты и имя в URL сохранятся.

Если требуется именно доступ через публичный IP из LAN, настраивают Hairpin NAT: соответствующий DNAT для внутренних запросов и, при необходимости, srcnat для симметричного ответа. Добавлять только masquerade недостаточно. Пример Hairpin NAT приведён у MikroTik.

Проверка по направлениям и приложениям

Ping полезен для диагностики IP-связности, но не подтверждает работу приложения. Звёздочки в traceroute также не доказывают, что транзитный трафик остановился: промежуточный узел может не отвечать на диагностические пакеты.

Откуда проверять	Что проверить	Критерий
Консоль перенесённого сервера	Новый шлюз и маршруты ОС	Шлюз достижим, default route соответствует плану
Компьютер офиса МСК	Файловый и веб-сервисы	Открывается ресурс, выполняется рабочая операция
Компьютер офиса СПб	Те же сервисы	Работает прямой доступ к серверным IP
VPN-пользователь	Маршрут и приложение	Приложение работает через VPN
Внешний канал, например мобильный интернет	DNS и все четыре веб-порта	Ответ нужного сервиса по прежнему имени

На современном Windows-клиенте можно отдельно проверить TCP:

Test-NetConnection 10.40.9.150 -Port 445
Test-NetConnection 10.40.10.45 -Port 4000

Первый тест относится к файловому сервису SMB. Для внешнего доступа проверьте каждый порт, заменив адрес на реальный:

4000,4001,5000,5001 | ForEach-Object {
    Test-NetConnection 203.0.113.10 -Port $_
}

TcpTestSucceeded: True подтверждает TCP-соединение. Описание команды и результатов доступно в документации Microsoft. После теста нужно открыть приложение по имени, с правильным HTTP или HTTPS, портом и путём. Для HTTPS проверьте сертификат и привязки сайта: NAT их не исправляет.

На роутере СПб смотрите счётчики публикации:

/ip firewall nat print stats where comment="KB-MOVE public web"
/ip firewall filter print stats where comment="KB-MOVE allow public web"

Рост счётчика NAT показывает совпадение новых соединений с правилом, но не получение корректного ответа приложения. После изменений NAT проверяйте новыми соединениями: существующие записи connection tracking сохраняют прежнюю трансляцию. Полностью очищать таблицу ради проверки не нужно — это оборвёт посторонние рабочие сеансы.

Ошибки, которые похожи на проблему VPN

Симптом	Что проверить первым
Сервер не видит новый шлюз	IP, маску, правильный мост или VLAN, включённый локальный `/32` на СПб, ARP
С роутера МСК сервер доступен, с компьютера МСК — нет	Proxy ARP на LAN МСК; ping роутера и клиентский запрос могут идти разными путями
Доступ работает только в одну сторону	Обратные маршруты, Proxy ARP на СПб и firewall обеих площадок
VPN подключён, сервер недоступен	Маршрут клиента к серверу и маршрут СПб к VPN-пулу
По IP работает, по имени — нет	Ответ DNS, его кэш и DNS-настройки клиента
TCP проходит, веб-сервис отвечает ошибкой	Привязки IIS, имя хоста, протокол, порт, сертификат и само приложение
Внешние запросы не увеличивают счётчик DNAT	DNS, WAN адрес, входной интерфейс, условия и порядок NAT правил

Получение сервером адреса по DHCP может восстановить доступ к обычной LAN офиса СПб. Это полезная проверка подключения, но она не проверяет правильность сохранённого статического IP и его маршрутов.

Откат и дальнейшая схема сети

Если сервис не прошёл проверку, отключите маршруты /32 к этому серверу на обоих роутерах, верните сервер на площадку МСК и восстановите прежний шлюз. Например, для файлового сервера:

На роутере МСК:

/ip route disable [find where comment="KB-MOVE file via SPb"]

На роутере СПб:

/ip route disable [find where comment="KB-MOVE file local"]

Общие настройки для остальных уже перенесённых серверов оставляйте до их собственного отката. Для веб-сервиса отдельно восстанавливаются прежняя публикация и DNS; возврат DNS также требует учитывать кэши клиентов. До обратного подключения убедитесь, что копия сервера на площадке СПб выключена.

Сохранение старых IP уменьшает объём изменений приложений во время переезда, но добавляет зависимость от Proxy ARP и индивидуальных маршрутов. Для каждого следующего перенесённого узла понадобятся записи на обеих площадках. Общие широковещательные механизмы при этом не переносятся через обычный маршрутизируемый SSTP.

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

Смежный разбор на fedkin.pro: миграция серверной инфраструктуры. Если нужна подготовка переноса с проверкой зависимостей, публикаций и плана отката, опишите текущую схему и задачу.

Документация

Технические ссылки проверены 18 октября 2026 года.

Перенос серверов на другую площадку с сохранением существующей адресации