Сетевая интеграция Windows Server с Azure и AWS: практическое руководство по VPN, маршрутизации и гибридной архитектуре

Интеграция локальной инфраструктуры на Windows Server с облачными платформами Azure и AWS решает конкретные бизнес-задачи: расширение мощностей для 1С:Предприятие, создание аварийного восстановления (DR) и размещение веб-сервисов ближе к пользователям. Просто поднять сервер в облаке недостаточно. Нужна безопасная и управляемая сеть, которая обеспечивает предсказуемую производительность и высокий аптайм. Эта статья содержит проверенные инструкции по выбору технологии подключения, настройке VPN-туннелей, конфигурации маршрутизации и устранению типичных ошибок.

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

Зачем интегрировать Windows Server с облаком: сценарии и требования

Гибридная инфраструктура соединяет локальные ресурсы с облачными сервисами, создавая единую рабочую среду. Это решение подходит не для всех задач. Его внедрение оправдано при наличии конкретных бизнес-потребностей и требований к инфраструктуре.

Сценарии использования: от расширения 1С до аварийного восстановления

Основные сценарии, требующие сетевой интеграции:

• Развертывание тестовых или дополнительных серверов 1С:Предприятие в облаке. Это позволяет разгрузить локальные мощности и обеспечить доступ к системе из разных географических точек.
• Создание аварийного восстановления (Site Recovery, DR) для критичных локальных сервисов. Облако становится площадкой для быстрого развертывания резервных копий приложений и данных в случае сбоя основного ЦОД.
• Разработка гибридных приложений. Например, веб-фронтенд работает в облаке для масштабируемости и глобальной доступности, а база данных остается на локальном Windows Server из соображений безопасности или требований регуляторов.
• Увеличение вычислительной мощности для пиковых нагрузок (burst). Локальная инфраструктура работает в штатном режиме, а в периоды высокой нагрузки часть задач перераспределяется в облако через настроенное сетевое подключение.

Эти сценарии напрямую связаны с технической реализацией: выбором типа подключения, настройкой маршрутизации и обеспечением безопасности.

Базовые требования: аптайм, производительность и SLA

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

• Аптайм. Для бизнес-критичных систем, таких как 1С:Предприятие, доступность сервера (аптайм) – ключевой показатель. При выборе облачного провайдера или хостинг-компании для локального шлюза необходимо изучать SLA. Ищите провайдеров, которые включают финансовую ответственность за недоступность в свое соглашение об уровне обслуживания. Это гарантия, а не просто обещание.
• Производительность. Для сетевого шлюза и облачных инстансов важны не только CPU и RAM. Низкая задержка сети (latency) критична для отзывчивости приложений. Скорость дисковых операций напрямую влияет на производительность баз данных. Для многопользовательских систем, таких как 1С, предпочтительны диски NVMe SSD, а не HDD. Они обеспечивают высокую скорость ввода-вывода, что снижает время отклика.
• Надежность дата-центра. Уровень надежности (Tier) дата-центра, где размещены ваши локальные серверы или облачной точки присутствия, влияет на доступность гибридного подключения. Дата-центры уровня Tier III и выше обеспечивают резервирование систем электропитания и охлаждения, что минимизирует риски простоев.

Реклама

Без учета этих требований даже технически правильно настроенное подключение может не выполнять свои бизнес-функции из-за низкой производительности или частых простоев.

Выбор технологии подключения: Site-to-Site VPN, ExpressRoute или Direct Connect

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

Site-to-Site VPN: быстро, дешево, зависит от интернета

Site-to-Site VPN создает зашифрованный туннель IPSec/IKE между локальным шлюзом (например, Windows Server с ролью Remote Access) и виртуальным шлюзом в облаке (Azure Virtual Network Gateway или AWS Virtual Private Gateway). Трафик проходит через публичный интернет.

Преимущества:

• Низкая стоимость. В Azure и AWS плата взимается только за время работы шлюза и исходящий трафик. Локальная часть требует лишь сервера с Windows Server.
• Быстрое развертывание. Настройка занимает несколько часов.

Недостатки:

• Переменная задержка и джиттер. Качество соединения зависит от загруженности интернет-каналов.
• Ограниченная пропускная способность. Пропускная способность туннеля ограничена производительностью шлюза и интернет-каналом. Максимум для одного туннеля обычно составляет около 1.25 Гбит/с.
• Отсутствие SLA на сквозное соединение. Облачные провайдеры дают SLA на работу своего шлюза, но не гарантируют доступность и качество вашего интернет-канала.

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

Azure ExpressRoute и AWS Direct Connect: выделенный канал с гарантиями

ExpressRoute (Azure) и Direct Connect (AWS) предоставляют выделенное физическое соединение из вашего ЦОД или локации до точки присутствия облачного провайдера. Трафик не проходит через публичный интернет.

Ключевые преимущества:

• Предсказуемая производительность и низкая задержка. Вы получаете гарантированную пропускную способность (от 50 Мбит/с до 100 Гбит/с) и стабильную задержку.
• Изоляция от публичного интернета. Это повышает безопасность, так как канал не подвержен атакам, сканирующим публичные IP-адреса.
• Высокий уровень SLA. Провайдеры предоставляют SLA на доступность соединения, часто на уровне 99.95% или выше, с финансовыми компенсациями за нарушение.

Сценарии применения: высоконагруженные продакшн-системы (1С:Предприятие с большим числом пользователей), регулярная передача больших объемов данных (бэкапы, синхронизация), соблюдение требований регуляторов к изоляции сетевого трафика.

Сводная таблица для принятия решения

Реклама

Вывод: используйте VPN для некритичных задач и быстрого старта. Для бизнес-критичных продакшн-сред с высокими требованиями к пропускной способности и стабильности выбирайте ExpressRoute или Direct Connect.

Пошаговая настройка Site-to-Site VPN: Windows Server с Azure и AWS

Это проверенное руководство позволяет настроить VPN-соединение между локальным Windows Server и облаком. Следуйте шагам последовательно, чтобы избежать типичных ошибок.

Подготовка: что нужно знать перед началом

Соберите эту информацию до начала настройки:

• Публичный статический IP-адрес вашего локального интернет-шлюза или Windows Server (если он находится за NAT, потребуется проброс портов).
• Диапазоны IP-адресов локальной сети, которые должны быть доступны из облака (например, 192.168.1.0/24).
• Диапазон адресов для облачной виртуальной сети (VNet в Azure или VPC в AWS), например, 10.1.0.0/16. Он не должен пересекаться с локальным.
• Тип и размер шлюза в облаке. В Azure это SKU (Basic, VpnGw1, VpnGw2 и т.д.). В AWS – тип виртуального приватного шлюза. Выбор влияет на стоимость и производительность.
• Требования к локальному Windows Server: Windows Server 2016/2019/2022, наличие двух сетевых адаптеров (один для локальной сети, один для интернета) или настройка маршрутизации на одном адаптере.

Настройка VPN с Azure: от Virtual Network Gateway до проверки туннеля

1. Создайте Virtual Network и подсеть в Azure Portal. Перейдите в раздел "Virtual networks", нажмите "+ Create". Укажите имя, регион и адресное пространство (например, 10.1.0.0/16). Добавьте подсеть для ресурсов (например, 10.1.0.0/24).
2. Создайте Virtual Network Gateway. В поиске по сервисам найдите "Virtual network gateways" и создайте новый. Выберите созданную VNet, тип шлюза "VPN", SKU (для начала подойдет VpnGw1). Укажите публичный IP-адрес (создастся новый).
3. Скачайте конфигурацию VPN-устройства. После развертывания шлюза перейдите в его настройки, в разделе "Settings" -> "Point-to-site configuration" (или в разделе подключений) найдите опцию скачивания конфигурации. Выберите в списке устройств "Windows Server" или "Generic". В скачанном ZIP-файле найдите файл конфигурации (обычно `GenericDevice.txt`). В нем будут указаны ключевые параметры: IP-адрес шлюза Azure, Pre-shared key (PSK), предложения IKE/IPsec.
4. Настройте роль "Шлюз удаленного доступа" на Windows Server. Откройте PowerShell от имени администратора и выполните установку роли:
   Install-WindowsFeature RemoteAccess -IncludeManagementTools
   После установки запустите мастера настройки Routing and Remote Access (через Server Manager или `rrasmgmt.msc`). Выберите конфигурацию "Secure connection between two private networks" (Site-to-Site VPN). В процессе мастера вам потребуется ввести данные из конфигурации Azure: IP-адрес удаленного шлюза (Azure Gateway IP), Pre-shared key, параметры безопасности (IKEv2, алгоритмы шифрования).
5. Создайте подключение Site-to-Site в Azure. Вернитесь в портал Azure, в настройках шлюза создайте новое подключение ("Connections" -> "+ Add"). Выберите тип "Site-to-site (IPSec)", укажите локальный IP-адрес Windows Server и тот же Pre-shared key, что использовали на сервере.
6. Проверьте подключение. В Azure Portal статус подключения должен измениться на "Connected". На Windows Server выполните команду в PowerShell для проверки состояния туннеля IPSec:
   Get-NetIPsecQuickModeSA
   Команда должна вернуть активное Security Association. Для проверки сетевой связности выполните `ping` с локального сервера на внутренний IP-адрес виртуальной машины в Azure VNet.

Реклама

Настройка VPN с AWS: Virtual Private Gateway и Customer Gateway

1. Создайте VPC и подсеть в AWS Console. Перейдите в сервис VPC, создайте новую VPC с адресным диапазоном (например, 172.31.0.0/16). Создайте как минимум одну публичную подсеть в этой VPC.
2. Создайте и присоедините Virtual Private Gateway. В разделе VPC найдите "Virtual Private Gateways" и создайте новый. После создания выберите его и в меню действий нажмите "Attach to VPC", выбрав созданную VPC.
3. Создайте Customer Gateway. В том же разделе VPC найдите "Customer Gateways" и создайте новый. В поле "IP Address" укажите публичный статический IP-адрес вашего локального Windows Server.
4. Создайте Site-to-Site VPN Connection. Перейдите в "Site-to-Site VPN Connections" и создайте новое подключение. Выберите созданный Virtual Private Gateway и Customer Gateway. В настройках routing выберите "Static" и укажите локальный диапазон IP-адресов (например, 192.168.1.0/24). Нажмите "Download configuration" и в выпадающем списке выберите производителя устройства "Generic".
5. Настройте Windows Server, используя конфигурацию AWS. Откройте скачанный файл конфигурации. Найдите секции для туннеля 1 и 2 (AWS создает два туннеля для отказоустойчивости). Вам понадобятся: IP-адреса AWS-туннелей, Pre-Shared Keys для каждого туннеля, параметры IKE/IPsec. Настройте подключение на Windows Server через Routing and Remote Access, создав два отдельных запроса на подключение (по одному для каждого туннеля), используя соответствующие IP и ключи.
6. Активируйте туннель и проверьте состояние. Вернитесь в AWS Console к созданному VPN Connection. После настройки на стороне Windows статус должен измениться на "UP". Для проверки используйте команду `Get-NetIPsecQuickModeSA` на Windows Server и попробуйте выполнить `ping` с AWS-инстанса в созданной подсети на локальный IP-адрес Windows Server.

Типичные ошибки и их решение

• "Туннель не поднимается" (Status: DOWN). В 80% случаев проблема в несовпадении параметров IKE/IPsec или Pre-Shared Key. Сверьте все параметры в конфигурационном файле облака и настройках Windows Server: версия IKE (IKEv1/IKEv2), алгоритмы шифрования (AES256), целостность (SHA256), группа Диффи-Хеллмана (DH Group 2 или 14). Убедитесь, что публичные IP-адреса указаны верно.
• "Туннель поднят, но трафик не идет" (Status: UP, но ping не работает). Проверьте таблицы маршрутизации. На Windows Server выполните `route print` и убедитесь, что есть маршрут к облачной подсети через VPN-интерфейс. В облаке проверьте таблицы маршрутов (Azure Route Table, AWS Route Table) – там должен быть маршрут к локальной подсети через виртуальный шлюз. Также проверьте правила сетевой безопасности: брандмауэр Windows, Azure Network Security Groups (NSG) или AWS Network ACLs (NACL) могут блокировать ICMP (ping) или нужные порты.
• "Периодические обрывы туннеля". Проверьте время жизни SA (Phase 2 Lifetime). На Windows Server и в облачной конфигурации эти значения должны совпадать или быть близкими. Убедитесь в стабильности вашего публичного IP-адреса. Если он динамический, используйте сервисы DDNS или рассмотрите вариант с выделенной линией.

Реклама

Маршрутизация в гибридной среде: как трафик находит путь

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

Статические маршруты на Windows Server: команды и практика

Просмотреть текущую таблицу маршрутизации можно командой:

route print

Чтобы добавить постоянный (персистентный) маршрут к облачной подсети через локальный IP-адрес VPN-интерфейса, используйте команду:

route add -p 10.1.0.0 mask 255.255.0.0 192.168.1.1

Где:
10.1.0.0 mask 255.255.0.0 – адресный диапазон Azure VNet.
192.168.1.1 – IP-адрес локального VPN-интерфейса (или IP-адрес следующего прыжка в локальной сети).
Флаг -p делает маршрут постоянным, сохраняя его после перезагрузки.

Метрика маршрута важна, когда у сервера несколько сетевых интерфейсов. Система выбирает маршрут с наименьшей метрикой. Указать метрику можно ключом -metric. Например, для VPN-подключения можно задать низкую метрику, чтобы трафик в облако шел через него, а не через основной шлюз по умолчанию.

route add -p 172.31.0.0 mask 255.255.0.0 192.168.1.1 metric 10

Для AWS VPC с диапазоном 172.31.0.0/16.

Настройка маршрутов в облаке: Azure Route Table и AWS Route Table

Чтобы трафик из облачных ресурсов возвращался в локальную сеть через VPN, необходимо настроить маршруты в облаке.

В Azure:

1. Создайте ресурс "Route table" в той же подписке и регионе, что и VNet.
2. Перейдите в созданную таблицу маршрутов, выберите "Routes" -> "+ Add".
3. Укажите:
   - Address prefix: локальная подсеть (например, 192.168.1.0/24).
   - Next hop type: Virtual network gateway.
   - Next hop address: оставьте пустым (шлюз выберется автоматически).
4. Сохраните маршрут. Затем перейдите в "Subnets" -> "+ Associate" и свяжите эту таблицу маршрутов с подсетями, где находятся ваши облачные ВМ. Теперь трафик с этих ВМ в локальную сеть будет направляться через VPN-шлюз.

В AWS:

1. В консоли VPC перейдите в "Route Tables".
2. Найдите основную таблицу маршрутов, связанную с вашей VPC (или создайте новую).
3. Отредактируйте маршруты ("Edit routes") и добавьте новую запись:
   - Destination: локальная подсеть (192.168.1.0/24).
   - Target: выберите созданный Virtual Private Gateway.
4. Сохраните изменения. Убедитесь, что эта таблица маршрутов ассоциирована с нужными подсетями VPC.

BGP для ExpressRoute и Direct Connect: автоматизация маршрутизации

При использовании ExpressRoute или Direct Connect можно задействовать протокол динамической маршрутизации BGP. Его основное преимущество – автоматический обмен информацией о сетевых путях. При добавлении новой подсети в локальной сети или в облаке маршруты распространяются автоматически, без ручного добавления статических записей.

Настройка BGP происходит на трех уровнях:

1. Со стороны облачного провайдера: Microsoft (для ExpressRoute) или Amazon предоставляет свой номер автономной системы (ASN) и адреса пиринга.
2. Со стороны клиента: настройка BGP выполняется на граничном маршрутизаторе в вашем ЦОД или, в некоторых случаях, с помощью службы Routing and Remote Access (RRAS) на Windows Server.
3. Настройка сессий BGP между вашим устройством и облачным шлюзом с указанием ASN и IP-адресов для пиринга.

Реклама

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

Диагностика проблем: от базовых проверок до анализа логов

Когда подключение не работает, следуйте системному алгоритму диагностики от простого к сложному.

Чек-лист быстрой диагностики

1. Проверка базовой связности. С локального сервера выполните `ping` на внутренний IP-адрес облачной ВМ. С облачной ВМ выполните `ping` на локальный IP-адрес Windows Server. Если ping не проходит, используйте `tracert` (Windows) или `traceroute` (Linux) для определения точки обрыва.
2. Проверка состояния туннеля IPSec. На Windows Server выполните:
   Get-NetIPsecQuickModeSA
   Если список пуст, туннель не установлен. Проверьте статус подключения в портале Azure ("Connections") или AWS ("Site-to-Site VPN Connections").
3. Проверка доступности конкретных портов. Используйте PowerShell:
   Test-NetConnection -ComputerName 10.1.0.4 -Port 3389
   Эта команда проверит доступность RDP-порта на облачной ВМ.
4. Проверка правил сетевой безопасности. Убедитесь, что Azure NSG или AWS NACL разрешают входящий трафик с локальной подсети на нужные порты (например, ICMP для ping, TCP 3389 для RDP). На самом Windows Server проверьте входящие правила брандмауэра Windows.
5. Проверка таблиц маршрутизации. На Windows Server – `route print`. В облаке – проверьте Route Tables на наличие маршрута к локальной подсети.

Анализ логов: где и что искать

Если базовые проверки не выявили причину, переходите к анализу журналов.

На Windows Server откройте "Event Viewer" (Просмотр событий). Перейдите в:
Applications and Services Logs -> Microsoft -> Windows -> RasClient и RasServer.
В этих журналах ищите события с уровнями Error или Warning, связанные с установкой подключения IKE/IPsec. Например, ошибка "IKE authentication failed" указывает на неверный Pre-Shared Key. "No proposal chosen" означает несовпадение параметров шифрования между клиентом и сервером.

В Azure используйте сервис Network Watcher. Инструмент "Connection Troubleshoot" позволяет проверить связность между ресурсами. "NSG Flow Logs" показывают, разрешается или блокируется трафик правилами безопасности.

В AWS активируйте "VPC Flow Logs" для подсети или сетевого интерфейса. Эти логи покажут, принимается или отвергается трафик. Для VPN-подключений также можно просматривать логи в CloudWatch.

Сравнение параметров, найденных в логах с обеих сторон подключения, – самый надежный способ найти расхождение в настройках.

Архитектура безопасности и отказоустойчивости

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

Настройка правил фильтрации трафика

Применяйте принцип минимальных привилегий на всех уровнях.

• Azure Network Security Groups (NSG): создайте правило, разрешающее входящий трафик только на необходимые порты (например, RDP 3389, порты для 1С:Предприятие) с исходного адреса, равного вашей локальной подсети (192.168.1.0/24). Запретите весь остальной входящий трафик из интернета. Используйте Service Tags (например, "VirtualNetwork") для упрощения правил.
• AWS Network ACLs: настройте аналогичные правила разрешения для входящего трафика с локальной подсети и правила deny по умолчанию.
• Брандмауэр Windows: на локальном Windows Server создайте входящие правила, разрешающие трафик с облачной подсети (например, 10.1.0.0/16) только на нужные порты.

Реклама

Шифрование трафика обеспечивается протоколом IPSec на уровне VPN-туннеля. Для выделенных подключений (ExpressRoute/Direct Connect) можно дополнительно использовать шифрование на уровне приложения или IPsec поверх выделенного канала.

Схемы отказоустойчивости: от двух VPN-туннелей до гибридного подключения

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

• Вариант 1 (Базовый): два Site-to-Site VPN-туннеля. Настройте второй VPN-туннель от локального шлюза к другому шлюзу в том же или другом регионе облака. В Azure можно настроить активный-активный режим для шлюза. В AWS при создании VPN Connection по умолчанию создаются два туннеля к разным устройствам – используйте оба, настроив их на локальной стороне. Это защитит от сбоя одного облачного шлюза или интернет-канала.
• Вариант 2 (Надежный): ExpressRoute/Direct Connect + резервный Site-to-Site VPN. Выделенная линия служит основным высокопроизводительным каналом. Настроенный VPN-туннель через интернет выступает в роли аварийного канала. При сбое выделенной линии трафик автоматически или вручную переключается на VPN. Это требует настройки маршрутов с разными метриками или использования BGP с соответствующими атрибутами.
• Вариант 3 (Максимальный): два канала ExpressRoute или Direct Connect. Закажите два физических подключения к разным точкам присутствия (PoP) облачного провайдера. Это обеспечивает отказоустойчивость на уровне физической инфраструктуры (кабели, оборудование провайдера). Самый дорогой, но и самый надежный вариант.

Выбор схемы зависит от требований бизнеса к RTO (Recovery Time Objective) и RPO (Recovery Point Objective), а также от бюджета.

Для комплексного управления сетевой инфраструктурой в мультиоблачных сценариях, включая маршрутизацию между AWS, Google Cloud и Azure, изучите наше практическое руководство по multi-cloud сетям. Там вы найдете готовые схемы и скрипты автоматизации.

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