Azure: роутинг в OpenVPN
Схема:
- Azure Cloud
- Vnet 10.10.0.0/24
- OpenVPN (Debian) eth0 10.10.0.77, tun0 172.16.16.1
- Linux VM eth0 10.10.0.55
- VPN клиент 172.16.16.32
Проблема: при подключении к Linux VM через VPN в логах сервера отображается IP адрес самого VPN сервера (10.10.0.77), а не выданный VPN сервером клиенту IP (172.16.16.32). И это большая проблема если для работы VPN используют несколько пользователей, а нам нужно отслеживать кто когда подключался и кто сделал sudo rm rf; (cейчас при подключении любого юзера через VPN в терминале выводится Last login: Mon Apr 19 12:03:22 2021 from 10.10.0.77).
99.9% howto по OpenVPN копируют друг друга и содержат такое типичное правило iptables
-A POSTROUTING -s 172.16.16.0/24 -o eth0 -j MASQUERADE
Естественно при POSTROUTING+MASQUERADE нужного адреса в логах мы не увидим. Правило POSTROUTING в таблице NAT говорит VPN серверу использовать SNAT для исходящего трафика, который уходит к 10.10.0.55, т.е. подменяется адрес источника. Это ожидаемо.
Я убрал это правило iptables и добавил push route в конфигурацию OpenVPN, но это не помогло.
Что надо сделать
- Включить на Linux VM net.ipv4.ip_forward = 1
- Отказаться от MASQUERADE
- Использовать маршрутизацию на Linux
- Включить ip forward на стороне Azure
Весь секрет в небольшой настройке Azure 🧙
#️⃣ Первый важный документ: Troubleshooting reaching systems over the VPN tunnel, раздел Microsoft Azure specific settings
If you have a virtual network with an OpenVPN Access Server installed on it and you wish to route traffic directly to the VPN client subnet, it is important to note that you should do so by implementing the routes in the virtual network routing table. This is the simplest way to do it, but also necessary. If you attempt to use a static route on a virtual instance instead to route the traffic to the Access Server, and from there to the VPN client subnet, the traffic will very likely be filtered away in the network between your instance and the Access Server. This appears to be a security feature. The solution is to implement the route in the virtual network routing table instead.
#️⃣ Второй важный документ: Reach OpenVPN clients directly from a private network, раздел Change from NAT to routing
#️⃣ Третий важный документ: Connecting Networks to OpenVPN Cloud Using Connectors. Из которого наконец-то узнаём про IP forwarding must be enabled at the VNIC.
#️⃣ Четвертый документ где собственно и показан пример настройки Azure: Microsoft Azure BYOL appliance quick start guide.
Переходим к виртуальной машине: Settings → Networking → выбираем сверху Network Interface → Settings → IP configurations → IP forwarding → Enabled
Теперь создаём Route Table. На главной странице портала Azure: Create a resource → ищем route table
После деплоя Route Table уже создаём маршрут
Указываем подсеть VPN сервера и внутренний адрес VPN сервера
Конфиг iptables
iptables -A INPUT -i eth0 -m state --state NEW -p udp --dport 1194 -j ACCEPT iptables -A INPUT -i tun+ -j ACCEPT iptables -A FORWARD -i tun+ -j ACCEPT iptables -A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -t nat -A POSTROUTING -o eth0 ! -d 10.10.0.0/24 -j MASQUERADE
Остальное через конфиг OpenVPN
push "route 172.16.16.0 255.255.255.0" push "route 10.10.0.0 255.255.255.0" # роуты к отдельным хостам push "route 1.2.3.4 255.255.255.255" push "route 5.6.7.8 255.255.255.255"
EOM
Обсуждение