VPN-CLOUD-WG-015 Сетевое оборудование и VPN

Настройка Site-to-Site WireGuard между облаком (Yandex Cloud / AWS) и офисом

Обновлено: 25.08.2026 · Официальная документация ↗

При интеграции локальных серверов с виртуальными машинами в VPC Yandex Cloud или AWS EC2 возникают сетевые заторы:

Облачные инстансы внутри VPC не могут достучаться до офисных серверов, хотя сам VPN-шлюз доступен.
Отбрасывание пакетов на виртуальных интерфейсах облака из-за встроенных проверок подлинности IP-источника (Source/Destination Check).
Асимметричная маршрутизация при наличии нескольких зон доступности (Availability Zones).
Сброс активных соединений правилами облачных групп безопасности (Security Groups).

1. Настройка инстанса VPN-шлюза в облаке (Linux VM)

# 1. Включение маршрутизации в ядре (/etc/sysctl.d/99-routing.conf):
net.ipv4.ip_forward = 1
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.default.rp_filter = 2
sysctl -p /etc/sysctl.d/99-routing.conf

# 2. Конфигурация WireGuard (/etc/wireguard/wg0.conf):
[Interface]
Address = 10.250.0.1/30
ListenPort = 51820
PrivateKey = CLOUD_PRIVATE_KEY
MTU = 1420

# Проброс трафика между офисом (192.168.10.0/24) и облаком (10.128.0.0/16):
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT

[Peer]
PublicKey = ONPREM_OFFICE_PUBLIC_KEY
Endpoint = 198.51.100.10:51820
AllowedIPs = 10.250.0.2/32, 192.168.10.0/24
PersistentKeepalive = 15

2. Обязательная настройка облачной платформы (Yandex Cloud / AWS)

AWS EC2: Выберите инстанс VPN-шлюза -> Actions -> Networking -> Change source/dest check -> Disable (Остановить проверку!).
Yandex Cloud VPC: В таблице маршрутизации VPC (Route Table) добавьте статический маршрут: Destination: 192.168.10.0/24 -> Next Hop Type: IP Address -> Next Hop: 10.128.0.5 (Внутренний IP VPN-шлюза). Привяжите таблицу ко всем подсетям VPC.
Security Groups: Разрешите входящий UDP 51820 на внешнем интерфейсе и весь внутренний трафик 192.168.10.0/24 внутри VPC.

3. Конфигурация офисного маршрутизатора (On-Premise)

# /etc/wireguard/wg0.conf в офисе:
[Interface]
Address = 10.250.0.2/30
PrivateKey = ONPREM_PRIVATE_KEY
MTU = 1420

[Peer]
PublicKey = CLOUD_PUBLIC_KEY
Endpoint = 84.201.x.x:51820
AllowedIPs = 10.250.0.1/32, 10.128.0.0/16
PersistentKeepalive = 15

4. Проверка связности сквозным пингом с рабочего места

ping 10.128.0.15  # Пинг облачной базы данных из офиса
traceroute 10.128.0.15

💡 Практика специалистов: Всегда проверяйте, чтобы MTU на интерфейсе WireGuard в облаке было не более 1420 байт, так как стандартный MTU виртуальных сетей в AWS и Yandex Cloud составляет ровно 1500 (без поддержки Jumbo Frames наружу), и любой оверхед вызовет скрытую фрагментацию.

Частые вопросы (FAQ)

Почему виртуальные машины в AWS не видят офисную сеть через VPN-шлюз?

По умолчанию AWS отбрасывает любой пакет, чей IP-адрес отправителя не совпадает с IP-адресом сетевого интерфейса EC2 инстанса. Чтобы инстанс мог работать транзитным маршрутизатором, необходимо отключить Source/Destination Checking в свойствах сетевой карты.

Нужно ли настраивать NAT/Masquerade на облачном VPN-шлюзе?

Если вы настроили статическую таблицу маршрутизации в облачной VPC (Next-Hop Routing), NAT не требуется (трафик маршрутизируется в чистом виде). Если прав на изменение VPC нет, придется маскарадить трафик через IP шлюза.

Как обеспечить отказоустойчивость облачного VPN-шлюза?

Разверните два идентичных VPN-шлюза в разных зонах доступности (например, ru-central1-a и ru-central1-b) и настройте между ними и офисом динамическую маршрутизацию BGP поверх WireGuard.

Какая пропускная способность достижима между AWS и On-Premise через WireGuard?

На современных CPU с инструкциями AVX-512 даже на недорогих виртуальных машинах (c6i.large) WireGuard легко утилизирует гигабитный канал (до 3-5 Гбит/с) с минимальной нагрузкой на ядра.