Назад | Перейти на главную страницу

Azure Site-to-Site VPN с маршрутизатором на базе Linux для подключения портов VPN к серверу RRAS, сохраняя NAT для другого трафика.

Я пытаюсь настроить и запустить Azure Site-to-Site VPN с использованием RRAS, но мне нужна помощь в настройке iptables моего маршрутизатора для подключения портов и протоколов VPN к серверу RRAS без использования NAT, при этом разрешая использование NAT для всего остального трафика. .

Мне удалось правильно настроить Azure и виртуальную машину, и я могу установить и запустить соединение с данными, передаваемыми через ссылку (и показанными на портале Azure как связанные с данными, идущими в обоих направлениях). Однако установленное соединение невозможно использовать, я не могу проверить связь или установить какое-либо соединение между виртуальной машиной Azure и моими локальными машинами.

Я считаю, что это связано с тем, что в Azure Site-to-Site VPN требуется, чтобы локальный VPN-шлюз был подключен напрямую к Интернету без прохождения через брандмауэр NAT (который я должен использовать, поскольку это мой домашний широкополосный доступ, поэтому у меня есть только один IP-адрес), поэтому соединение может быть установлено. NAT на моем маршрутизаторе изменяет пакеты таким образом, что они не могут быть правильно маршрутизированы после достижения сервера RRAS.

Я пробовал альтернативные решения Site-to-Site VPN (OpenVPN, SoftEther, сам RRAS), но ни одно из них не работает должным образом, демонстрируя ту же проблему, при которой VPN-соединение хоста двух виртуальных машин может подключаться ко всему, а мои домашние сетевые серверы могут быть правильно маршрутизируется для подключения к стороне Azure, но я считаю, что либо из-за ограничений на виртуальные машины Azure (только один сетевой адаптер и отсутствие возможности включить неразборчивый режим), либо из-за самой виртуальной сети Azure, это означает, что никакая другая виртуальная машина Azure не может подключиться к моему дому сеть, несмотря на добавление статических маршрутов для прохождения через сервер VPN или добавление его в качестве дополнительного шлюза.

Я использую маршрутизатор Asus RT-AC68U с последней сборкой Merlin, поэтому я надеюсь, что смогу использовать Azure Site-to-Site VPN, изменив правила iptables и конфигурацию сети следующим образом:

Сейчас сеть выглядит так:

Виртуальные машины Azure - 192.168.1.0/25, VPN-шлюз с использованием динамической маршрутизации с общедоступным IP-адресом.

Домашняя сеть 192.168.0.0/24:

VDSL Modem <- мост PPPOE, чтобы маршрутизатор имел общедоступный IP -> Asus Router <- NAT -> 192.168.0.0.24

Вот что я пытаюсь сделать, чтобы у RRAS был общедоступный IP-адрес только для целей VPN:

Я открыт для других предложений, чтобы заставить работать Site-to-Site VPN, если есть более простое решение.

[обновление 1]

В настоящее время я думаю о следующем: я дал виртуальной машине RRAS Hyper-V дополнительный сетевой адаптер и назначил его VLAN 635, случайный режим включен, если по какой-то причине он хочет изменить свой MAC-адрес. Затем я отключил все элементы подключения, кроме двух элементов обнаружения топологии канального уровня и IPv4.

Я назначил настройкам IPv4 общедоступный IP-адрес, маску подсети 255.255.255.255 и шлюз, который является тем же шлюзом, что и адаптер ppp0 в маршрутизаторе.

Я выполнил на маршрутизаторе следующее, чтобы попытаться направить любой трафик, пытающийся связаться со шлюзом Azure VPN через VLAN, и, таким образом, надеюсь, разрешить его маршрутизацию без использования NAT:

/usr/sbin/ip link add link br0 name br0.635 type vlan id 635
/usr/sbin/ip link set dev br0.635 up

/usr/sbin/iptables -I INPUT -i br0.635 -j ACCEPT
/usr/sbin/iptables -I FORWARD -i ppp0 -o br0.635 -s <azure gateway IP> -j ACCEPT
/usr/sbin/iptables -I FORWARD -i br0.635 -o ppp0 -d <azure gateway IP> -j ACCEPT
/usr/sbin/iptables -I FORWARD -i ppp0 -o br0.635 -s <ppp0's gateway> -j ACCEPT
/usr/sbin/iptables -I FORWARD -i br0.635 -o ppp0 -d <ppp0's gateway> -j ACCEPT

К сожалению, это не работает, и при попытке подключения в RRAS он сообщает мне, что удаленный сервер не отвечает.

Итак, мне удалось выяснить это после долгих поисков, я могу использовать встроенную функциональность Azure Site-to-Site VPN с OpenSwan, которая работает на Linux-компьютере (Raspberry Pi / Arch Linux) за моей домашней сетью. NAT-роутер.

Топология сети:

  • 192.168.0.0/24 - Домашняя сеть
  • 192.168.1.0/24 - сеть Azure
  • 192.168.0.1 - частный IP домашнего маршрутизатора
  • 192.168.0.2 - Linux-сервер, действующий как VPN-сервер и шлюз домашней сети

Сначала я настроил Azure с помощью:

  • Это обычная удаленная сеть
  • Моя локальная сеть с VPN-адресом в качестве общедоступного IP-адреса
  • Включен флажок Site-to-Site в сети Azure, связывающей его с моей локальной сетью.
  • Создал статический шлюз, поэтому используется IKEv1

На маршрутизаторе моей домашней сети я отправил на свой шлюз Linux, на котором запущен Openswan (192.168.0.2), следующее:

  • UDP 500
  • UDP 4500
  • Протокол 50 (GRE)

Мой ipsec.conf выглядит так:

version 2.0

config setup
    nat_traversal=yes
    virtual_private=%4:192.168.0.0/24
    protostack=auto
    interfaces="ipsec0=eth0"

conn azure
    authby=secret
    auto=start
    type=tunnel
    left=192.168.0.2
    leftsubnet=192.168.0.0/24
    leftnexthop=192.168.0.1
    right=<azure's VPN gateway IP>
    rightsubnet=192.168.1.0/24
    ike=3des-sha1-modp1024,aes128-sha1-modp1024
    esp=3des-sha1,aes128-sha1
    pfs=no

ipsec.secrets:

192.168.0.2 <azure vpn gateway> : PSK "Azure's PSK"

Это позволило установить и запустить связь, чтобы обеспечить маршрутизацию между сайтами (в обе стороны после большого разочарования):

/etc/sysctl.conf:

net.ipv4.ip_forward = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.icmp_ignore_bogus_error_responses = 1

Сценарий bash, который запускается при загрузке, чтобы обеспечить выполнение проверки ipsec:

#!/bin/bash

for vpn in /proc/sys/net/ipv4/conf/*; do
    echo 0 > $vpn/accept_redirects;
    echo 0 > $vpn/send_redirects;
done

sysctl -p

Наконец, мои правила iptables, которые потребовали наибольшего количества возни:

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

-A FORWARD -s 192.168.1.0/24 -m policy --dir in --pol ipsec -j ACCEPT
-A FORWARD -s 192.168.0.0/24 -m policy --dir out --pol ipsec -j ACCEPT
-A INPUT -p udp -m udp --dport 500 -j ACCEPT
-A INPUT -p udp -m udp --dport 4500 -j ACCEPT
-A INPUT -m policy --dir in --pol ipsec -j ACCEPT
-A INPUT -p esp -j ACCEPT

nat, это позволяет виртуальным машинам Azure подключаться к любому компьютеру в моей домашней сети:

-A PREROUTING -i eth0 -p udp -m udp --dport 4500 -j DNAT --to-destination <azure public vpn ip>:4500
-A PREROUTING -i eth0 -p udp -m udp --dport 500 -j DNAT --to-destination <azure public vpn ip>:500
-A POSTROUTING -o eth0 -j MASQUERADE

Со всем этим я могу пинговать и общаться в обоих направлениях, все виртуальные машины Azure могут видеть мою домашнюю сеть, все машины домашней сети могут видеть мои виртуальные машины Azure.

Сторона Azure сама по себе правильно выполняет маршрутизацию, для моей домашней сети я настроил статический маршрут в своем маршрутизаторе для отправки 192.168.1.0/24 на 192.168.0.2, но для тестирования на своей машине я просто создал статический маршрут:

route -p ADD 192.168.1.0 MASK 255.255.255.0 192.168.0.2 METRIC 100

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