Пример процесса поиска неисправностей:
Проверяем работу VPN:
Со стороны R1 данные не передаются:
R1#ping 10.2.2.0 source 10.0.0.0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.2.0, timeout is 2 seconds:
Packet sent with a source address of 10.0.0.0
…
Success rate is 0 percent (0/5)
На R1 isakmp sa с R4 не устанавливается (установлено только sa с R3):
R1#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
200.0.0.1 100.0.0.1 QM_IDLE 1007 ACTIVE
Со стороны R4 данные не передаются:
R4#ping 10.0.0.0 source 10.2.2.0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.0, timeout is 2 seconds:
Packet sent with a source address of 10.2.2.0
…
Success rate is 0 percent (0/5)
Однако установилось ISAKMP SA с R1:
R4#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
100.0.0.1 202.0.0.1 QM_IDLE 1002 ACTIVE
Перепроверяем его на R1:
R1#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id status
100.0.0.1 202.0.0.1 QM_IDLE 1008 ACTIVE
200.0.0.1 100.0.0.1 QM_IDLE 1007 ACTIVE
IPsec sa не устанавливаются:
R4#sh crypto ipsec sa
interface: FastEthernet2/0
Crypto map tag: MAP1, local addr 202.0.0.1
protected vrf: (none)
local ident (addr/mask/prot/port): (10.2.2.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.0.0.0/255.255.255.0/0/0)
current_peer 100.0.0.1 port 500
PERMIT, flags={origin_is_acl,ipsec_sa_request_sent}
#pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
#pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 20, #recv errors 0
local crypto endpt.: 202.0.0.1, remote crypto endpt.: 100.0.0.1
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet2/0
current outbound spi: 0x0(0)
PFS (Y/N): N, DH group: none
inbound esp sas:
inbound ah sas:
inbound pcp sas:
outbound esp sas:
outbound ah sas:
outbound pcp sas:
Остается проверить настройки, которые относятся ко второй фазе IPsec (все параметры crypto-map и правильность их указания).
R1#sh run | s access-list
R1#sh crypto map
— Решение:
Crypto-map состоит из наборов правил, которые отсортированы по порядку.
Когда трафик проходит через интерфейс, на котором применена crypto-map,
он проверяется на совпадение с ACL, по порядку, по всем наборам правил crypto-map.
Если найдено совпадение, то просмотр останавливается, инициируется туннель с параметрами этого набора правил crypto-map.
На R1 в crypto-map MAP1 ACL 101 используется в первом наборе правил:
crypto map MAP1 10 ipsec-isakmp
set peer 200.0.0.1
set transform-set AES128-SHA
match address 101
crypto map MAP1 20 ipsec-isakmp
set peer 202.0.0.1
set transform-set AES128-SHA
match address 102
Но он создан таким образом, что в ACL 101 попадает и трафик с R1 на R4:
access-list 101 permit ip 10.0.0.0 0.0.0.255 10.0.0.0 0.255.255.255
Поэтому и не создается туннель между R1 и R4, если пинговать с R1 loopback-интерфейс R4.
Когда пинг запускается в обратном направлении, отрабатывает первая фаза, устанавливается isakmp sa,
так как настройки со стороны R4 правильные и он может инициировать создание туннеля.
Но sa второй фазы (ipsec sa) не устанавливаются, так как не совпадают ACL между R1 и R4.
Исправляем ACL 101:
R1(config)#no access-list 101 permit ip 10.0.0.0 0.0.0.255 10.0.0.0 0.255.255.255
R1(config)#access-list 101 permit ip 10.0.0.0 0.0.0.255 10.1.1.0 0.0.0.255
R1#sh run | s access
access-list 101 permit ip 10.0.0.0 0.0.0.255 10.1.1.0 0.0.0.255
access-list 102 permit ip 10.0.0.0 0.0.0.255 10.2.2.0 0.0.0.255
Всё работает:
R4#ping 10.0.0.0 source 10.2.2.0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.0, timeout is 2 seconds:
Packet sent with a source address of 10.2.2.0
!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 508/575/628 ms
3 коментария
Получается, что в этом примере даже с учетом исправлений данные не передаются по туннелю между R3 и R4. Чтобы передавались и между ними, я бы сделал ACL на роутерах такие:
R1:
101 10.0.0.0 0.2.2.0 host 10.1.1.0
102 10.0.0.0 0.1.1.0 host 10.2.2.0
(тут маска 0.2.2.0 будет «пропускать» только адреса 10.0.0.0 и 10.2.2.0, а маска 0.1.1.0 только адреса 10.0.0.0 и 10.1.1.0)
R3:
101 host 10.1.1.0 10.0.0.0 0.2.2.0
R4:
101 host 10.2.2.0 10.0.0.0 0.1.1.0
hunterweb, ну так в этом же смысл задачи. Ошибка в конфигурации, которую необходимо обнаружить.
По-хорошему access листы должны либо не пересекаться, либо идти от частного к общему в порядке crypto map sequence, а не наоборот.
Странно, зачем тогда писать в крипто мапе наборы листов 102 и т.д, если все-равно перебор пойдет с 101.