Ситуация
Изход. Пия кафе. Студентът настрои VPN връзка между две точки и изчезна. Проверявам: тунелът наистина съществува, но няма трафик в тунела. Не отговаря на обаждания.
Слагам чайника и се впускам в решаване на проблеми с C-TERRA шлюза. Споделям опита и методологията си.
Изходни данни
Две териториално разделени площадки са свързани с GRE тунел. GRE трябва да бъде криптиран:
Проверявам работоспособността на GRE тунела. За целта пускам ping от устройството R1 до GRE интерфейса на устройството R2. Това е целевият трафик за криптиране. Няма отговор:
root@R1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) байта данни.
--- 1.1.1.2 ping статистики ---
4 пакета изпратени, 0 получени, 100% загуба на пакети, време 3057msПреглеждам логовете на Gate1 и Gate2. Логът радостно съобщава, че IPsec тунелът е успешно установен, без проблеми:
root@Gate1:~# cat /var/log/cspvpngate.log
Aug 5 16:14:23 localhost vpnsvc: 00100119 IPSec връзка 5 установена, селектор на трафика 172.17.0.1->172.16.0.1, протокол 47, връстник 10.10.10.251, id "10.10.10.251", Филтър
IPsec:Protect:CMAP:1:LIST, IPsecAction IPsecAction:CMAP:1, IKERule IKERule:CMAP:1В статистиката на IPsec тунела на Gate1 виждам, че тунелът наистина съществува, но броячът Rcvd е нулиран:
root@Gate1:~# sa_mgr show
ISAKMP сесии: 0 инициирани, 0 отговорили
ISAKMP връзки:
Номер Conn-id (Локален Addr, Порт)-(Отдалечен Addr, Порт) Състояние Изпратени Получени
1 3 (10.10.10.251,500)-(10.10.10.252,500) активна 1070 1014
IPsec връзки:
Номер Conn-id (Локален Addr, Порт)-(Отдалечен Addr, Порт) Протокол Действие Тип Изпратени Получени
1 3 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP тунел 480 0Решавам проблемите с C-TERRA по този начин: търся къде се губят целевите пакети по пътя от R1 до R2. В процеса (спойлер) ще открия грешка.
Решаване на проблеми
Стъпка 1. Какво получава Gate1 от R1
Използвам вграден пакетен снифър – tcpdump. Пускам снифъра на вътрешния (Gi0/1 в нотация Cisco-like или eth1 в нотация на ОС Debian) интерфейс:
root@Gate1:~# tcpdump -i eth1
tcpdump: подробен изход потиснат, използвайте -v или -vv за пълен декод на протокола
слушане на eth1, линк-тип EN10MB (Ethernet), размер на захващане 262144 байта
14:53:38.879525 IP 172.16.0.1 > 172.17.0.1: GREv0, ключ=0x1, дължина 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo запитване, id 2083, seq 1, дължина 64
14:53:39.896869 IP 172.16.0.1 > 172.17.0.1: GREv0, ключ=0x1, дължина 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo запитване, id 2083, seq 2, дължина 64
14:53:40.921121 IP 172.16.0.1 > 172.17.0.1: GREv0, ключ=0x1, дължина 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo запитване, id 2083, seq 3, дължина 64
14:53:41.944958 IP 172.16.0.1 > 172.17.0.1: GREv0, ключ=0x1, дължина 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo запитване, id 2083, seq 4, дължина 64Виждам, че Gate1 получава GRE пакети от R1. Продължавам напред.
Стъпка 2. Какво прави Gate1 с GRE пакетите
С помощта на утилитата klogview наблюдавам какво се случва с GRE пакетите вътре VPN в драйвера C-TERRA:
root@Gate1:~# klogview -f 0xffffffff
резултат на филтрация за изходящ пакет 172.16.0.1->172.17.0.1, протокол 47, дължина 112, интерфейс eth0: верига 4 "IPsecPolicy:CMAP", филтър 8, събитие ID IPsec:Protect:CMAP:1:LIST, статус PASS
инкапсулиране с SA 31: 172.16.0.1->172.17.0.1, протокол 47, дължина 112, интерфейс eth0
преминал изходящ пакет 10.10.10.251->10.10.10.252, протокол 50, дължина 160, интерфейс eth0: инкапсулиран
Виждам, че целевият GRE трафик (протокол 47) 172.16.0.1 -> 172.17.0.1 е преминал (PASS) под правилото за шифроване LIST в криптокартата CMAP и е бил шифрован (инкапсулиран). След това пакетът е маршрутизиран (преминал изход). Няма обратен трафик в извода на klogview.
Проверявам списъците за достъп на устройството Gate1. Виждам един списък за достъп LIST, който определя целевия трафик за шифроване, така че правила за МЭ не са конфигурирани:
Gate1#show access-lists
Разширен IP списък за достъп LIST
10 разреши gre хост 172.16.0.1 хост 172.17.0.1Извод: проблемът не е на устройството Gate1.
Допълнително за klogview
VPN драйверът обработва целия мрежови трафик, не само този, който трябва да бъде шифрован. Следните съобщения се виждат в klogview, ако VPN драйверът е обработил мрежовия трафик и го е предал в незашифрован вид:
root@R1:~# ping 172.17.0.1 -c 4root@Gate1:~# klogview -f 0xffffffff
резултат на филтрация за входящ пакет 172.16.0.1->172.17.0.1, протокол 1, дължина 84, интерфейс eth0: верига 4 "IPsecPolicy:CMAP": няма съвпадение
преминал изходящ пакет 172.16.0.1->172.17.0.1, протокол 1, дължина 84, интерфейс eth0: филтриранВиждам, че ICMP трафик (протокол 1) 172.16.0.1->172.17.0.1 не е преминал (няма съвпадение) в правилата за шифроване на криптокартата CMAP. Пакетът е маршрутизиран (преминал изход) в открит вид.
Стъпка 3. Какво получава Gate2 от Gate1
Стартирам сниффер на WAN (eth0) интерфейса на Gate2:
root@Gate2:~# tcpdump -i eth0
tcpdump: обширен изход потиснат, използвайте -v или -vv за пълен декод на протокола
слушане на eth0, тип на свързването EN10MB (Ethernet), размер на улов 262144 байта
16:05:45.104195 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x1), дължина 140
16:05:46.093918 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x2), дължина 140
16:05:47.117078 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x3), дължина 140
16:05:48.141785 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x4), дължина 140Виждам, че Gate2 получава ESP пакети от Gate1.
Стъпка 4. Какво прави Gate2 с ESP пакетите
Стартирам утилитата klogview на Gate2:
root@Gate2:~# klogview -f 0xffffffff
резултат на филтрация за входящ пакет 10.10.10.251->10.10.10.252, протокол 50, дължина 160, интерфейс eth0: верига 17 "FilterChain:L3VPN", филтър 21, статус DROP
дропнат входящ пакет 10.10.10.251->10.10.10.252, протокол 50, дължина 160, интерфейс eth0: защитна стена
Виждам, че ESP пакетите (протокол 50) са били дропнати (DROP) от правилото (L3VPN) на защитната стена. Убедявам се, че към Gi0/0 наистина е свързан списъкът за достъп L3VPN:
Gate2#show ip interface gi0/0
GigabitEthernet0/0 е активно, линейният протокол е активен
Интернет адресът е 10.10.10.252/24
MTU е 1500 байта
Изходящият списък за достъп не е зададен
Входящият списък за достъп е L3VPNПроблемът е открит.
Стъпка 5. Какво не е наред със списъка за достъп
Разглеждам какво представлява списъкът за достъп L3VPN:
Gate2#show access-list L3VPN
Extended IP access list L3VPN
10 permit udp host 10.10.10.251 any eq isakmp
20 permit udp host 10.10.10.251 any eq non500-isakmp
30 permit icmp host 10.10.10.251 anyВиждам, че ISAKMP пакетите са разрешени, затова IPsec тунелът се установява. Но липсва разрешаващо правило за ESP. Вероятно студентът е объркал icmp и esp.
Коригирам списъка с достъп:
Gate2(config)#
ip access-list extended L3VPN
no 30
30 permit esp host 10.10.10.251 anyСтъпка 6. Проверявам функционалността
Първо се уверявам, че списъкът с достъп L3VPN е верен:
Gate2#show access-list L3VPN
Extended IP access list L3VPN
10 permit udp host 10.10.10.251 any eq isakmp
20 permit udp host 10.10.10.251 any eq non500-isakmp
30 permit esp host 10.10.10.251 anyСега от устройството R1 стартирам целевия трафик:
root@R1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data.
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=35.3 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=3.01 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=2.65 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=2.87 ms
--- 1.1.1.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 2.650/10.970/35.338/14.069 msПобеда. GRE тунелът е установен. Броячът на входящия трафик в статистиката на IPsec не е нулев:
root@Gate1:~# sa_mgr show
ISAKMP сесии: 0 инициирани, 0 отговорили
ISAKMP връзки:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd
1 3 (10.10.10.251,500)-(10.10.10.252,500) active 1474 1350
IPsec връзки:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd
1 4 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 1920 480На шлюза Gate2 в изхода на klogview се появиха съобщения, че целевият трафик 172.16.0.1->172.17.0.1 успешно (PASS) е декриптиран (decapsulated) от правилото LIST в криптокартата CMAP:
root@Gate2:~# klogview -f 0xffffffff
филтрационен резултат за входящ пакет 172.16.0.1->172.17.0.1, протокол 47, дължина 112, if eth0: верига 18 "IPsecPolicy:CMAP", филтър 25, събитие id IPsec:Protect:CMAP:1:LIST, статус PASS
преминал в пакет 172.16.0.1->172.17.0.1, протокол 47, дължина 112, if eth0: декриптиранИтог
Студентът развали изхода.
Внимавай с правилата на МЭ.
Анонимен инженер
t.me/anonimous_engineer
Източник: habr.com
