Проверка работоспособности PBR

1. Для проверки работоспособности PBR, на устройстве Traffic_Inspection из linux bash выполните команду tcpdump на интерфейсе ens32, и отправьте ICMP трафик с устройства host1_behind_spoke1 устройству host2_behind_spoke1.

root@Traffic_Inspection:~# tcpdump -i ens32 -n host 192.168.1.100 and host 192.168.2.100

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on ens32, link-type EN10MB (Ethernet), capture size 262144 bytes

09:57:36.003398 IP 192.168.1.100 > 192.168.2.100: ICMP echo request, id 32727, seq 1, length 64

09:57:36.003415 IP 192.168.1.100 > 192.168.2.100: ICMP echo request, id 32727, seq 1, length 64

09:57:36.004305 IP 192.168.2.100 > 192.168.1.100: ICMP echo reply, id 32727, seq 1, length 64

09:57:36.004313 IP 192.168.2.100 > 192.168.1.100: ICMP echo reply, id 32727, seq 1, length 64

09:57:37.005058 IP 192.168.1.100 > 192.168.2.100: ICMP echo request, id 32727, seq 2, length 64

09:57:37.005083 IP 192.168.1.100 > 192.168.2.100: ICMP echo request, id 32727, seq 2, length 64

09:57:37.006258 IP 192.168.2.100 > 192.168.1.100: ICMP echo reply, id 32727, seq 2, length 64

09:57:37.006266 IP 192.168.2.100 > 192.168.1.100: ICMP echo reply, id 32727, seq 2, length 64

09:57:38.006534 IP 192.168.1.100 > 192.168.2.100: ICMP echo request, id 32727, seq 3, length 64

09:57:38.006550 IP 192.168.1.100 > 192.168.2.100: ICMP echo request, id 32727, seq 3, length 64

09:57:38.007263 IP 192.168.2.100 > 192.168.1.100: ICMP echo reply, id 32727, seq 3, length 64

09:57:38.007270 IP 192.168.2.100 > 192.168.1.100: ICMP echo reply, id 32727, seq 3, length 64

Видно, что трафик от host1_behind_spoke1 до host2_behind_spoke1 и обратно проходят через Traffic_Inspection. Из-за того пакет сначала передается от Hub1 устройству Traffic_Inspection, а потом Traffic_Inspection отправляет его обратно криптошлюзу Hub1, то каждый пакет наблюдается дважды.

2. Проверьте, что на криптошлюзах Hub1 и Spoke1 установлено защищенное IPsec соединение. Для этого выполните команду run sa_mgr show из cisco-like консоли криптошлюзов.

Hub1#run sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:

Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd

1 1 (172.16.100.2,500)-(172.16.2.100,500) active 2160 3296

2 2 (172.16.100.2,500)-(172.16.1.2,500) active 2380 2452

IPsec connections:

Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd

1 1 (192.168.1.0-192.168.1.255,*)-(192.168.254.1,*) * ESP tunn 0 0

2 2 (192.168.100.0-192.168.100.255,*)-(192.168.1.0-192.168.1.255,*) * ESP tunn 440 440

3 3 (192.168.100.0-192.168.100.255,*)-(192.168.254.1,*) * ESP tunn 256 256

4 4 (192.168.2.0-192.168.2.255,*)-(192.168.1.0-192.168.1.255,*) * ESP tunn 528 528

5 5 (192.168.1.0-192.168.1.255,*)-(192.168.2.0-192.168.2.255,*) * ESP tunn 528 528

Spoke1#run sa_mgr show

ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:

Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd

1 1 (172.16.1.2,500)-(172.16.100.2,500) active 2452 2380

IPsec connections:

Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd

1 1 (192.168.1.0-192.168.1.255,*)-(192.168.100.0-192.168.100.255,*) * ESP tunn 440 440

2 2 (192.168.1.0-192.168.1.255,*)-(192.168.2.0-192.168.2.255,*) * ESP tunn 528 528

3 3 (192.168.2.0-192.168.2.255,*)-(192.168.1.0-192.168.1.255,*) * ESP tunn 528 528

Видно, что на криптошлюзах Hub1 и Spoke1 установлено защищенное IPsec соединение. Если этого не произошло, то проверьте файл журнала (команда run less /var/log/cspvpngate.log). При необходимости увеличьте уровень логирования с помощью (команда logging trap debugging в консоли cisco-like) и заново инициируйте защищенное соединение.

3. Можно проверить работоспособность PBR для Client1. Для этого на устройстве Traffic_Inspection из linux bash выполните команду tcpdump на интерфейсе ens32, и отправьте ICMP трафик с устройства Client1 устройству host1_behind_spoke2.

root@Traffic_Inspection:~# tcpdump -i ens32 -n host 192.168.1.100

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on ens32, link-type EN10MB (Ethernet), capture size 262144 bytes

10:16:39.456564 IP 192.168.254.1 > 192.168.1.100: ICMP echo request, id 1, seq 107, length 40

10:16:39.456583 IP 192.168.254.1 > 192.168.1.100: ICMP echo request, id 1, seq 107, length 40

10:16:39.457516 IP 192.168.1.100 > 192.168.254.1: ICMP echo reply, id 1, seq 107, length 40

10:16:39.457524 IP 192.168.1.100 > 192.168.254.1: ICMP echo reply, id 1, seq 107, length 40

10:16:40.469209 IP 192.168.254.1 > 192.168.1.100: ICMP echo request, id 1, seq 108, length 40

10:16:40.469226 IP 192.168.254.1 > 192.168.1.100: ICMP echo request, id 1, seq 108, length 40

10:16:40.470228 IP 192.168.1.100 > 192.168.254.1: ICMP echo reply, id 1, seq 108, length 40

10:16:40.470236 IP 192.168.1.100 > 192.168.254.1: ICMP echo reply, id 1, seq 108, length 40

10:16:41.479642 IP 192.168.254.1 > 192.168.1.100: ICMP echo request, id 1, seq 109, length 40

10:16:41.479656 IP 192.168.254.1 > 192.168.1.100: ICMP echo request, id 1, seq 109, length 40

10:16:41.480582 IP 192.168.1.100 > 192.168.254.1: ICMP echo reply, id 1, seq 109, length 40

10:16:41.480590 IP 192.168.1.100 > 192.168.254.1: ICMP echo reply, id 1, seq 109, length 40

10:16:42.495418 IP 192.168.254.1 > 192.168.1.100: ICMP echo request, id 1, seq 110, length 40

10:16:42.495435 IP 192.168.254.1 > 192.168.1.100: ICMP echo request, id 1, seq 110, length 40

10:16:42.496394 IP 192.168.1.100 > 192.168.254.1: ICMP echo reply, id 1, seq 110, length 40

10:16:42.496401 IP 192.168.1.100 > 192.168.254.1: ICMP echo reply, id 1, seq 110, length 40

Видно, что трафик от Client1 до host1_behind_spoke1 и обратно проходят через Traffic_Inspection. Из-за того пакет сначала передается от Hub1 устройству Traffic_Inspection, а потом Traffic_Inspection отправляет его обратно криптошлюзу Hub1, то каждый пакет наблюдается дважды.