국내 IPsec VPN 문제를 해결하는 방법. 1 부

상황

휴일. 나는 커피를 마셔요. 학생은 두 지점 사이에 VPN 연결을 설정하고 사라졌습니다. 확인해보니 터널이 정말 있는데 터널 안에 교통량이 없습니다. 학생이 전화를 받지 않습니다.

주전자를 켜고 S-Terra Gateway 문제 해결에 들어갑니다. 나는 내 경험과 방법론을 공유합니다.

원시 데이터

지리적으로 분리된 두 사이트는 GRE 터널로 연결됩니다. GRE를 암호화해야 합니다.

GRE 터널의 기능을 확인하고 있습니다. 이를 위해 장치 R1에서 장치 R2의 GRE 인터페이스로 ping을 실행합니다. 암호화 대상 트래픽입니다. 답변 없음:

root@R1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data.

--- 1.1.1.2 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3057ms

Gate1과 Gate2의 로그를 봅니다. 로그에는 IPsec 터널이 성공적으로 시작되었으며 문제가 없다고 행복하게 보고됩니다.

root@Gate1:~# cat /var/log/cspvpngate.log
Aug  5 16:14:23 localhost  vpnsvc: 00100119 <4:1> IPSec connection 5 established, traffic selector 172.17.0.1->172.16.0.1, proto 47, peer 10.10.10.251, id "10.10.10.251", Filter 
IPsec:Protect:CMAP:1:LIST, IPsecAction IPsecAction:CMAP:1, IKERule IKERule:CMAP:1

Gate1의 IPsec 터널 통계에서 실제로 터널이 있지만 Rсvd 카운터가 XNUMX으로 재설정되어 있음을 알 수 있습니다.

root@Gate1:~# sa_mgr show
ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:
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 1070 1014

IPsec connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd
1 3 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 480 0

저는 S-Terra에 다음과 같이 문제를 제기합니다. R1에서 R2로의 경로에서 대상 패킷이 손실된 위치를 찾습니다. 그 과정에서(스포일러) 실수를 발견하게 됩니다.

문제 해결

1단계. Gate1이 R1으로부터 받는 것

저는 내장된 패킷 스니퍼인 tcpdump를 사용합니다. 내부(Cisco와 유사한 표기법에서는 Gi0/1, Debian OS 표기법에서는 eth1) 인터페이스에서 스니퍼를 실행합니다.

root@Gate1:~# tcpdump -i eth1

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
14:53:38.879525 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, length 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 2083, seq 1, length 64
14:53:39.896869 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, length 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 2083, seq 2, length 64
14:53:40.921121 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, length 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 2083, seq 3, length 64
14:53:41.944958 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, length 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 2083, seq 4, length 64

Gate1이 R1으로부터 GRE 패킷을 수신하는 것을 볼 수 있습니다. 나는 계속 나아간다.

2단계. Gate1이 GRE 패킷으로 수행하는 작업

klogview 유틸리티를 사용하면 S-Terra VPN 드라이버 내부의 GRE 패킷에 무슨 일이 일어나고 있는지 확인할 수 있습니다.

root@Gate1:~# klogview -f 0xffffffff

filtration result for out packet 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: chain 4 "IPsecPolicy:CMAP", filter 8, event id IPsec:Protect:CMAP:1:LIST, status PASS
encapsulating with SA 31: 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0
passed out packet 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: encapsulated

대상 GRE 트래픽(proto 47) 172.16.0.1 -> 172.17.0.1이 CMAP 암호화 맵의 LIST 암호화 규칙에 따라 캡슐화되었음을 확인합니다. 다음으로 패킷이 라우팅되었습니다(전달됨). klogview 출력에는 응답 트래픽이 없습니다.

Gate1 장치의 출입 목록을 확인하고 있습니다. 암호화를 위한 대상 트래픽을 정의하는 액세스 목록 LIST가 하나 표시됩니다. 이는 방화벽 규칙이 구성되지 않았음을 의미합니다.

Gate1#show access-lists
Extended IP access list LIST
    10 permit gre host 172.16.0.1 host 172.17.0.1

결론: 문제는 Gate1 장치에 있는 것이 아닙니다.

클로그뷰에 대해 더 알아보기

VPN 드라이버는 암호화해야 하는 트래픽뿐만 아니라 모든 네트워크 트래픽을 처리합니다. VPN 드라이버가 네트워크 트래픽을 처리하고 암호화되지 않은 상태로 전송한 경우 klogview에 표시되는 메시지는 다음과 같습니다.

root@R1:~# ping 172.17.0.1 -c 4

root@Gate1:~# klogview -f 0xffffffff

filtration result for out packet 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: chain 4 "IPsecPolicy:CMAP": no match
passed out packet 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: filtered

ICMP 트래픽(proto 1) 172.16.0.1->172.17.0.1이 CMAP 암호화 카드의 암호화 규칙에 포함되지 않았습니다(일치하지 않음). 패킷은 일반 텍스트로 라우팅(전달)되었습니다.

Step 3. Gate2가 Gate1로부터 받는 것

WAN(eth0) Gate2 인터페이스에서 스니퍼를 시작합니다.

root@Gate2:~# tcpdump -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:05:45.104195 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x1), length 140
16:05:46.093918 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x2), length 140
16:05:47.117078 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x3), length 140
16:05:48.141785 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x4), length 140

Gate2가 Gate1에서 ESP 패킷을 수신하는 것을 볼 수 있습니다.

4단계. Gate2가 ESP 패키지로 수행하는 작업

Gate2에서 klogview 유틸리티를 실행합니다.

root@Gate2:~# klogview -f 0xffffffff
filtration result for in packet 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: chain 17 "FilterChain:L3VPN", filter 21, status DROP
dropped in packet 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: firewall

방화벽 규칙(L50VPN)에 의해 ESP 패킷(proto 3)이 삭제(DROP)된 것을 확인했습니다. Gi0/0에 실제로 L3VPN 액세스 목록이 연결되어 있는지 확인합니다.

Gate2#show ip interface gi0/0
GigabitEthernet0/0 is up, line protocol is up
  Internet address is 10.10.10.252/24
  MTU is 1500 bytes
  Outgoing access list is not set
  Inbound  access list is 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 통계의 수신 트래픽 카운터가 XNUMX이 아닙니다.

root@Gate1:~# sa_mgr show
ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:
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 connections:
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이 CMAP 암호화 맵의 LIST 규칙에 의해 성공적으로 해독(PASS)되었다는 메시지가 표시되었습니다.

root@Gate2:~# klogview -f 0xffffffff
filtration result for in packet 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: chain 18 "IPsecPolicy:CMAP", filter 25, event id IPsec:Protect:CMAP:1:LIST, status PASS
passed in packet 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: decapsulated

결과

한 학생이 쉬는 날을 망쳤습니다.
ME 규칙을 주의하세요.

익명의 엔지니어
t.me/anonymous_engineer

출처 : habr.com