VPN Tunneling 구간 SSH timeout 증상 (3handshake)

각 업체 간에 VPN을 통해서 SSH연결을 통해 유지보수로 사용중 신규 PC에 대한 SSH가 되지 않았다.

이 업체는 공중망, 전용회선, VPN을 전부 사용하고 있는 복잡한 관계기도하고 예전부터 사용했기 때문에 정확한 히스토리가 없었다.

 

업체에서 망분리 작업을 진행하면서 기존 사용하던 100.x.x.x 대역이 아닌 새로운 대역 200.x.x.x 를 추가 요청이 왔다.

내부에서는 VPN Tunneling 과 VPN의 보안정책, VPN 정책, Server ACL(Tcp wrapper)만 등록하면 정상 통신이 되어야했다.

내부 사설망은 망분리가되었지만 같은 VPN 장비를 사용하기 때문이다.

 

하지만 연결은 되지 않았다.

결국 을에 입장에서 정확한 근거를 찾아 업체측에게 전달하여 확인해야 했다.

아래 내용을 이해하기 편하게 IP를 지정하여 설명한다.

• 서버 : 10.x.x.x
• L4 : 20.x.x.x
• 기존 PC : 100.x.x.x
• 신규 PC : 200.x.x.x

 

VPN Log 확인

VPN에서 설정이 동일하게 설정되었는지 그리고 터널링이 정상적인지에 대해서 로그를 확인했다.

로그 확인 결과 3-Handshake가 정상적으로 이뤄지지 않았다는게 보여졌다.

3Handshke가 정상적으로 이뤄지려면 S(yn) - S(yn)/A(ck) - A(ck) 가 이뤄져야 한다.

 

[클라이언트IP-서버IP 패킷 내용]

INIT="Incomplete" CLOSED="TimeOut" FLAGS="S <-> SA" START="03/18/2024-09:07:10" END="03/18/2024-09:07:30" PACKETS="10" BYTES="484"

 

Traceroute(Tracert)를 이용한 경로 추적

Traceroute(서버), Tracert(윈도우)를 이용한다.

보통은 보안장비를 거쳐가거나 방화벽에서 이 경로추적 포트를 막은 경우에 추적이 되지않을 수 있지만 내부에서의 경로추적을 별도로 막은 것이 없다면 어떻게 데이터가 나가는지 확인할 수 있다.

 

업체측에게 경로 추적에 대한 정보를 요청했다.

기존 PC는 업체의 L3와 VPN을 거쳐서 나오는 것을 볼 수 있었고 신규PC는 L3와 VPN이 홉에 찍혀있지 않았다.

하지만 이걸로 인해서 확신할 순 없었다.

신규 PC에서 서버로 SSH 요청 시 VPN에서 요청 로그가 찍혀있었기 때문이다.

 

VPN 과 Server TCP Dump를 통해 패킷 분석

VPN → L4 → L2 → L2 → Server 구조에서 L2를 제외하고 L4, VPN, Server에 대한 TCP Dump를 진행했다.

실제 우리 내부 네트워크에서 받지 못하거나 다음 패킷을 보내지 않았을 수 있다는 가정을 가지고 검증이 필요했다.

 

L4(Alteon/알테온) TCP dump 사용 방법

이 장비 문서찾기 엄청 껄끄러웠다. 그래서 일단 함께 메뉴얼을 올려두겠다.

$ ssh 관리자계정@20.x.x.x
$ /maint/pktcap/capture -l host 20.x.x.x and port 22

# 캡처 중단
$ stop

# 캡처 캐시 삭제
$ clearcap

 

Server(Solaris) TCP dump 사용 방법

솔라리스의 경우 오래된 장비이기도 하고 tcpdump가 설치되어있지 않아 snoop를 이용했다.

$ snoop -v -V host 10.x.x.x and port 22

 

Tcp Dump 분석 결과

L4에서 분석한 결과를 보면 처음 클라이언트(200)가 서버(20)로 Syn을 보낸것을 볼수 있다.

하지만 그 이후에 서버가 응답이 없자 다시 SA(Syn-Ack)를 계속 보내는 것을 볼 수 있다.

VPN로그에서도 동일한 로그였고 서버도 동일했다. 

정리하면, 클라이언트가 SSH연결 요청 후 서버가 정상적으로 22포트를 열었다고 SA를 보내지만 클라이언트는 이를 받지 못한다.

VPN에서 넘어가는 과정과 SA라는점을 고려하면 클라이언트측의 문제라고 볼 수 있다.

<3 14:53:15.549617 IP 200.x.x.x:64319 > 20.x.x.x:22: S 2712864978:2712864998(20) ack 0 win 64240
>8 14:53:15.549624 IP 200.x.x.x:64319 > 20.x.x.x:22: S 2712864978:2712864998(20) ack 0 win 64240

<8 14:53:15.549910 IP 20.x.x.x:22 > 200.x.x.x:64319: SA 1413645325:1413645345(20) ack 2712864979 win 32853
<3 14:53:16.562721 IP 200.x.x.x:64319 > 20.x.x.x:22: S 2712864978:2712864998(20) ack 0 win 64240

>3 14:53:15.549915 IP 20.x.x.x:22 > 200.x.x.x:64319: SA 1413645325:1413645345(20) ack 2712864979 win 32853
>8 14:53:16.562727 IP 200.x.x.x:64319 > 20.x.x.x:22: S 2712864978:2712864998(20) ack 0 win 64240

<8 14:53:16.562875 IP 20.x.x.x:22 > 200.x.x.x:64319: . 1413645326:1413645346(20) ack 2712864979 win 32853
<3 14:53:18.575920 IP 200.x.x.x:64319 > 20.x.x.x:22: S 2712864978:2712864998(20) ack 0 win 64240

>3 14:53:16.562881 IP 20.x.x.x:22 > 200.x.x.x:64319: . 1413645326:1413645346(20) ack 2712864979 win 32853
<8 14:53:18.576076 IP 20.x.x.x:22 > 200.x.x.x:64319: . 1413645326:1413645346(20) ack 2712864979 win 32853

>3 14:53:18.576082 IP 20.x.x.x:22 > 200.x.x.x:64319: . 1413645326:1413645346(20) ack 2712864979 win 32853
>8 14:53:18.575926 IP 200.x.x.x:64319 > 20.x.x.x:22: S 2712864978:2712864998(20) ack 0 win 64240

<8 14:53:18.919866 IP 20.x.x.x:22 > 200.x.x.x:64319: SA 1413645325:1413645345(20) ack 2712864979 win 32853
>3 14:53:18.919871 IP 20.x.x.x:22 > 200.x.x.x:64319: SA 1413645325:1413645345(20) ack 2712864979 win 32853

<3 14:53:22.578011 IP 200.x.x.x:64319 > 20.x.x.x:22: S 2712864978:2712864998(20) ack 0 win 64240
>8 14:53:22.578015 IP 200.x.x.x:64319 > 20.x.x.x:22: S 2712864978:2712864998(20) ack 0 win 64240

<8 14:53:22.578174 IP 20.x.x.x:22 > 200.x.x.x:64319: . 1413645326:1413645346(20) ack 2712864979 win 32853
>3 14:53:22.578181 IP 20.x.x.x:22 > 200.x.x.x:64319: . 1413645326:1413645346(20) ack 2712864979 win 32853

<8 14:53:25.670316 IP 20.x.x.x:22 > 200.x.x.x:64319: SA 1413645325:1413645345(20) ack 2712864979 win 32853
>3 14:53:25.670323 IP 20.x.x.x:22 > 200.x.x.x:64319: SA 1413645325:1413645345(20) ack 2712864979 win 32853

 

VPN정책 그리고 보안 정책 Inbound와 Outbound 정책 

현재 업체측에서 조치 중이고 조치되는대로 아래 작성할 예정이다.

의심되는건 VPN정책은 사실상 상관없지만 의심되는 것은 2가지다.

 

1. 서버에서도 외부PC에서 22포트를 열어달라 요청하는 과정(SA)에서 보안상의 이유로 거부되었을 확률이 높다 생각이 든다.

2. 보안 정책에 대한 Inbound와 Outbound를 서버 to 서버가 아니기 때문에 인바운드는 막아두었을 확률이 있다.