Офис в Казани находился за NAT-маршрутизатором провайдера, что потребовало дополнительной настройки. Кроме того, в московском офисе было несколько VLAN-подсетей.
Шлюз в Казани находился за NAT. Мы настроили NAT-T для инкапсуляции ESP в UDP 4500:
# Конфигурация для шлюза за NAT (Казань)
conn site-to-msk-from-kzn
left=%defaultroute # Автоопределение внешнего IP
leftsubnet=10.3.0.0/24
leftid=@gw-kzn.company.ru
leftfirewall=yes
leftcert=gw-kzn-cert.pem
right=203.0.113.10
rightsubnet=10.1.0.0/24
rightid=@gw-msk.company.ru
forceencaps=yes # Принудительная инкапсуляция в UDP
На NAT-маршрутизаторе провайдера в Казани мы настроили:
- Проброс UDP 500 и UDP 4500 на IP внутреннего VPN-шлюза
- Проброс протокола ESP (IP 50)
В Москве было три подсети (офис, серверный VLAN, гостевая). Мы объединили их через VPN:
# Множественные подсети в одном соединении
conn msk-spb-multi
left=203.0.113.10
leftsubnet=10.1.0.0/24,10.1.1.0/24,10.1.2.0/24
right=198.51.100.20
rightsubnet=10.2.0.0/24
# Создаёт отдельные Child SA для каждой пары подсетей
Split Tunneling — через VPN идёт только трафик к удалённым подсетям, интернет-трафик идёт напрямую. В site-to-site VPN это поведение по умолчанию.
Для корректной работы мы настроили маршруты на всех маршрутизаторах офисов:
# На маршрутизаторе московского офиса:
ip route add 10.2.0.0/24 via 10.1.0.1 # К СПб через VPN-шлюз
ip route add 10.3.0.0/24 via 10.1.0.1 # К Казани через VPN-шлюз
# На маршрутизаторе СПб:
ip route add 10.1.0.0/24 via 10.2.0.1
ip route add 10.3.0.0/24 via 10.2.0.1
# Проверка с клиентского ПК:
traceroute 10.2.0.100 # Должен идти через VPN-шлюз
Для автоматической раздачи маршрутов через DHCP мы настроили опцию 121:
# В dhcpd.conf московского офиса:
option classless-routes code 121 = array of unsigned integer 8;
subnet 10.1.0.0 netmask 255.255.255.0 {
range 10.1.0.100 10.1.0.200;
option routers 10.1.0.254;
option classless-routes 24, 10, 2, 0, 10, 1, 0, 1,
24, 10, 3, 0, 10, 1, 0, 1;
}