VPN между сайтами: маршрут не используется

VPN между сайтами: маршрут не используется, UniFi Network

silanea

Guest

23.04.2019 22:15:00

Привет! У меня проблема с site-to-site IPSEC VPN между моим USG Pro и удалённым VPS на базе CentOS. Туннель поднят, маршрут на USG задан, но когда я пингую удалённую сторону с USG или с любого устройства за ним, получаю ответ от следующего хопа моего провайдера, то есть, очевидно, маршрут через туннель вообще не используется.

USG находится за обычным роутером в режиме exposed host, WAN IP USG — 192.168.0.8, LAN IP роутера — 192.168.0.5. Подсеть USG — 192.168.1.0/24, VPS — 192.168.2.0/24. Конфигурация USG приложена.

# route:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default [router-ip] 0.0.0.0 UG 0 0 0 eth2
loopback * 255.0.0.0 U 0 0 0 lo
192.168.0.0 * 255.255.255.0 U 0 0 0 eth2
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
192.168.2.0 * 255.255.255.0 U 0 0 0 vti64

# ping 192.168.2.1 (с USG через SSH или с клиентов за ним):
PING 192.168.2.1 (192.168.2.1) 56(84) байт данных.
From [isp-next-hop] icmp_seq=1 Destination Net Unreachable
From [isp-next-hop] icmp_seq=2 Destination Net Unreachable
^C
--- 192.168.2.1 ping statistics ---
2 пакета передано, 0 получено, +2 ошибки, 100% потеря, время 1001 мс

# traceroute 192.168.2.1:
traceroute to 192.168.2.1 (192.168.2.1), max 30 прыжков, пакеты по 38 байт
1 [router] (192.168.0.5) 0.390 ms 0.349 ms 0.340 ms
2 [isp-next-hop] ([isp-next-hop]) 8.768 ms !N 6.429 ms !N 4.707 ms !N

# ip xfrm policy:
src 192.168.2.0/24 dst 192.168.1.0/24
dir fwd priority 2883
tmpl src [vps-wan-ip] dst 192.168.0.8
proto esp reqid 1 mode tunnel
src 192.168.2.0/24 dst 192.168.1.0/24
dir in priority 2883
tmpl src [vps-wan-ip] dst 192.168.0.8
proto esp reqid 1 mode tunnel
src 192.168.1.0/24 dst 192.168.2.0/24
dir out priority 2883
tmpl src 192.168.0.8 dst [vps-wan-ip]
proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
socket out priority 0
src ::/0 dst ::/0
socket in priority 0
src ::/0 dst ::/0
socket out priority 0
src ::/0 dst ::/0
socket in priority 0
src ::/0 dst ::/0
socket out priority 0

Я совершенно не понимаю, почему правило маршрутизации для подсети VPS игнорируется. Может, я где-то что-то упустил? Спасибо!

UI-Team

Guest

17.05.2019 15:15:00

@silanea

У тебя в выводе SA снова показывается tunnel, а не VTI. Ты не меняешь настройки постоянно? Еще там показывается 0 байт входящих и 0 байт исходящих — ты вообще пытаешься отправить трафик, когда делаешь этот вывод? Эти счётчики часто сбрасываются. Нельзя корректно проснимать tcpdump трафик по VPN с «tunnel» (политикой) на USG, нужен именно VTI, иначе увидишь только внутренний трафик туннеля при входе через WAN, а исходящий трафик не будет виден. Я бы советовал тестировать клиентов, которые находятся «за» USG, а не сам USG. Особенно на VPN с политикой, где селекторы трафика должны совпадать точно.

silanea

Guest

20.05.2019 13:48:00

@UBNT-jaffe

Я перепрошил USG, теперь туннель поднят и работает в обе стороны, за одним единственным исключением: если пинговать USG (192.168.1.1) с любого устройства из удалённой подсети (192.168.2.0/24), пакеты регистрируются на USG, но ответа нет. Наверное, у меня где-то не хватает правила в брандмауэре, но эта задача стоит настолько низко в моём списке дел, что пока просто забью на неё. Огромное спасибо за помощь; честно говоря, я даже не знаю, что именно исправило эту неразбериху, просто рад, что VPN работает.

silanea

Guest

19.05.2019 23:11:00

@UBNT-jaffe

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

silanea

Guest

16.05.2019 16:30:00

# show vpn ipsec sa:peer-[vps-wan]-tunnel-0: #51, УСТАНОВЛЕНО, IKEv2, baccb2339a2c15c2:e10ffd5992be1a66
локальный '[usg-wan]' @ [usg-wan]
удалённый '[vps-wan]' @ [vps-wan]
AES_CBC-256/HMAC_SHA1_96/PRF_HMAC_SHA1/ECP_384
установлено 969 секунд назад, перевыпуск ключа через 26831 секунду, повторная аутентификация через 1380 секунд
peer-[vps-wan]-tunnel-0: #1, УСТАНОВЛЕНО, ТУННЕЛЬ, ESP:AES_CBC-256/HMAC_SHA1_96
установлено 969 секунд назад, перевыпуск ключа через 1646 секунд, истекает через 2631 секунду
входящий c099eedf, 0 байт, 0 пакетов
исходящий ceaaadcf, 0 байт, 0 пакетов
локальная сеть 192.168.1.0/24
удалённая сеть 192.168.2.0/24

Да, у второго VPS IP 192.168.2.2. Он подключён к первому VPS через LAN на базе VNIC, который подключён к мосту на первом VPS с IP 192.168.2.1. Трафик между ними полностью работает.

UI-Team Guest	#6 15.05.2019 16:15:00 Можешь снова показать вывод команды «show vpn ipsec sa» с USG? И есть ли у второго VPS за первым IP из подсети 192.168.2.0/24?

silanea Guest	#7 15.05.2019 08:57:00 @UBNT-jaffe Извиняюсь за долгое молчание, мешала масштабная перестройка инфраструктуры. Теперь USG напрямую выходит в публичную сеть, посреднический роутер убран. Я могу отправлять трафик с USG на VPS через туннель, но несколько проблем ещё остались. Вот текущая конфигурация: USG: ipsec.conf: # сгенерировано с помощью /opt/vyatta/sbin/vpn-config.pl config setup conn %default keyexchange=ikev1 conn peer-[vps-wan]-tunnel-0 left=[usg-wan] right=[vps-wan] leftsubnet=192.168.1.0/24 rightsubnet=192.168.2.0/24 ike=aes256-sha1-ecp384! keyexchange=ikev2 reauth=no ikelifetime=28800s forceencaps=yes esp=aes256-sha1-ecp384! keylife=3600s rekeymargin=540s type=tunnel compress=no authby=secret auto=route keyingtries=%forever #conn peer-[vps-wan]-tunnel-0 # ipsec status: Routed Connections: peer-[vps-wan]-tunnel-0{1}: ROUTED, TUNNEL peer-[vps-wan]-tunnel-0{1}: 192.168.1.0/24 === 192.168.2.0/24 Security Associations (1 up, 0 connecting): peer-[vps-wan]-tunnel-0[1]: ESTABLISHED 3 минуты назад, [usg-wan][[usg-wan]]...[vps-wan][[vps-wan]] peer-[vps-wan]-tunnel-0{1}: INSTALLED, TUNNEL, ESP в UDP SPIs: c0e098ff_i c368ff16_o peer-[vps-wan]-tunnel-0{1}: 192.168.1.0/24 === 192.168.2.0/24 # mtr 192.168.2.2 (второй VPS за удалённым VPS, подключен через сетевой мост): My traceroute [v0.82] [usg-hostname] (0.0.0.0) Ср, 15 мая 2019, 10:36:59 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 192.168.2.1 0.0% 20 13.2 13.0 12.7 13.5 0.2 2. 192.168.2.2 0.0% 19 13.7 13.5 13.3 13.9 0.2 Я могу зайти по ssh с USG на удалённый VPS и на второй VPS за ним. (Но наоборот не выходит, см. ниже.) Удалённый VPS ipsec.conf: config setup conn %default leftsubnet=192.168.2.0/24 authby=secret auto=start conn [usg] right=[usg-wan] rightsubnet=192.168.1.0/24 ike=aes256-sha1-ecp384! esp=aes256-sha1-ecp384! left=[vps-wan] leftsourceip=192.168.2.1 keyexchange=ikev2 ikelifetime=3600s keylife=3600s # strongswan status: Security Associations (1 up, 0 connecting): acheron[5]: ESTABLISHED 13 минут назад, [vps-wan][[vps-wan]]...[usg-wan][[usg-wan]] acheron{5}: INSTALLED, TUNNEL, reqid 4, ESP в UDP SPIs: c368ff16_i c0e098ff_o acheron{5}: 192.168.2.0/24 === 192.168.1.0/24 ping, mtr и ssh с удалённого VPS и второго VPS на USG просто «зависают»/тайм-аутятся. Запуск на VPS: # mtr 192.168.1.1 My traceroute [v0.92] [vps-wan] (192.168.2.1) 2019-05-15T10:54:31+0200 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev На USG: # tcpdump -i any -nn icmp or esp or udp port 500 or udp port 4500 [...] 10:49:04.618084 IP 192.168.2.1 > 192.168.1.1: ICMP echo request, id 29949, seq 33784, length 44 10:49:04.618320 IP 192.168.2.1 > 192.168.1.1: ICMP echo request, id 29949, seq 33784, length 44 10:49:04.689990 IP [vps-wan].4500 > [usg-wan].4500: UDP-encap: ESP(spi=0xc0e098ff,seq=0x568), length 116 10:49:04.690056 IP [vps-wan].4500 > [usg-wan].4500: UDP-encap: ESP(spi=0xc0e098ff,seq=0x568), length 116 10:49:04.689990 IP 192.168.2.1 > 192.168.1.1: ICMP echo request, id 29949, seq 33785, length 44 10:49:04.690220 IP 192.168.2.1 > 192.168.1.1: ICMP echo request, id 29949, seq 33785, length 44 10:49:04.761674 IP [vps-wan].4500 > [usg-wan].4500: UDP-encap: ESP(spi=0xc0e098ff,seq=0x569), length 116 10:49:04.761739 IP [vps-wan].4500 > [usg-wan].4500: UDP-encap: ESP(spi=0xc0e098ff,seq=0x569), length 116 10:49:04.761674 IP 192.168.2.1 > 192.168.1.1: ICMP echo request, id 29949, seq 33786, length 44 10:49:04.761902 IP 192.168.2.1 > 192.168.1.1: ICMP echo request, id 29949, seq 33786, length 44 10:49:04.833345 IP [vps-wan].4500 > [usg-wan].4500: UDP-encap: ESP(spi=0xc0e098ff,seq=0x56a), length 116 10:49:04.833379 IP [vps-wan].4500 > [usg-wan].4500: UDP-encap: ESP(spi=0xc0e098ff,seq=0x56a), length 116 10:49:04.833345 IP 192.168.2.1 > 192.168.1.1: ICMP echo request, id 29949, seq 33787, length 44 10:49:04.833470 IP 192.168.2.1 > 192.168.1.1: ICMP echo request, id 29949, seq 33787, length 44 [...] То же самое при запуске mtr на втором VPS. Стоит ли выложить какие-то ещё логи или информацию?

Читают тему (гостей: 1)