안녕하세요, 누리클라우드입니다.
VPN 장비가 없다면 AWS VPN의 고객 게이트웨이를 구성할 수 없어서 테스트 구성을 해볼 수가 없는데요, VPN 장비 대신 윈도우 서버의 '라우팅 및 원격 액세스 서비스'를 사용해도 구성이 가능합니다. 이번 글에서는 위와 같이 구성할 때 몇 가지 체크포인트에 대해 알아보도록 하겠습니다.
우선, "Windows Server 2012 R2를 고객 게이트웨이로 구성"하는 상세한 내용은 Amazon 문서 사이트를 참고하여 터널링까지 완료한 것으로 간주하고, 마지막 단계에서 End-to-End 통신이 안될 때 체크해야 할 사항들에 대해서 소개드리겠습니다.
VPN 구성
예로 설명 드릴 VPN 구성을 간략하게 요약하면, 서울리전에 AWS VPN 연결을 구성하고 도쿄리전에 Windows Server 2012 R2 EC2 인스턴스로 고객 게이트웨이를 구성합니다. 윈도우 서버는 고객 단에 아직 VPN 장비가 없는 상황을 가정하여 장비 대용으로 사용하는 겁니다. 도쿄리전에 고객 게이트웨이의 윈도우 EC2를 생성 후 Amazon 문서 사이트의 내용대로 EC2의 네트워크 속성과 고정 EIP를 붙이고 보안 그룹까지 확인합니다. 1, 2단계를 거쳐 서울리전에서 VPC의 VPN 연결 구성을 완료하고, 3단계에서 다시 도쿄리전의 윈도우 서버로 와서 라우팅 및 원격 액세스 서비스를 설치 및 설정하고 서울리전의 VPN 구성에서 다운로드한 설정 파일을 수정하여 윈도우 서버에서 스크립트로 터널 설정을 적용하여 줍니다. 그리고, 윈도우 방화벽에서 터널링 관련 설정들을 완료합니다.
터널링 구간 핑 테스트
모든 설정을 잘 구성한 경우라면 아래와 같이 도쿄리전의 윈도우서버에서 서울리전의 리눅스 인스턴스로 핑 테스트를 하면 첫 번째 패킷이 터널링을 개시하고 두 번째 패킷부터 정상 속도로 응답을 수신하는 것을 확인할 수 있습니다. AWS VPN 측에서는 개시 장치가 아니므로 핑 테스트로 터널링을 개시할 수 없습니다.
그런데, 기나긴 구성 과정을 마치고 최종 테스트에서 불행히도 아래와 같이 타임아웃이 확인되면 깜깜 해지는 상황이 됩니다.
이때 당황하지 않고 간단한 몇 가지 확인으로 문제를 빠르게 해결할 수 있습니다. Amazon 문서 사이트의 하단에 ping 실패할 때 확인해야 할 정보를 먼저 점검해 보시고, 특별히 이상이 없다면 다음 방법으로 확인해야 할 범위를 줄일 수 있습니다.
문제 해결
핑 응답이 없을 때 양 끝단에 패킷 분석 툴을 설치하여 구간을 나누어서 확인해 봅니다. 패킷 분석 툴은 리눅스는 tcpdump, 윈도우는 windump혹은 wireshark를 사용할 수 있습니다.
핑을 걸어 둔 상태에서 출발지와 도착지에서 패킷 분석 툴을 실행하여 핑의 송수신 패킷의 성공 여부를 확인해 봅니다.
Case 0: 송신 측에서 요청/응답 패킷이 보이고 수신 측에서 요청/응답 패킷이 보이는 경우 – 정상
핑이 성공한 경우는 아래와 같이 송신 측과 수신 측에서 요청과 응답 패킷을 확인할 수 있습니다. 이때, 윈도우 VPN에서는 AWS VPN 측의 외부 아이피 주소 2개 중 터널링이 활성화된 아이피(예:52.79.138.62)로 4500 포트로 캡슐화 된 UDP-encap 패킷이 ICMP핑 패킷 대신 교환되는 것을 확인할 수 있습니다.
송신 측:
수신 측:
[root@ip-10-10-100-110 ~]# tcpdump -nni eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
08:00:00.500847 IP 172.31.16.103 > 10.10.100.110: ICMP echo request, id 1, seq 9, length 40
08:00:00.500870 IP 10.10.100.110 > 172.31.16.103: ICMP echo reply, id 1, seq 9, length 40
08:00:05.238585 IP 172.31.16.103 > 10.10.100.110: ICMP echo request, id 1, seq 10, length 40
08:00:05.238607 IP 10.10.100.110 > 172.31.16.103: ICMP echo reply, id 1, seq 10, length 40
Case 1: 송신 측에서 요청 패킷이 보이지 않는 경우
UDP-encap패킷이 아닌 ICMP패킷이 보인다면 터널링 구간으로 라우팅이 안 되는 것이므로 목적지 아이피가 AWS VPN사설 대역이 아닌 아이피를 잘못 기입하였을 수 있습니다. 요청 패킷 자체가 보이지 않는 경우는 윈도우 VPN의 터널링이나 라우팅 설정이 잘못되어 있을 수 있습니다.
Case 2: 송신 측에서 요청 패킷이 보이지만 수신 측에서 요청 패킷이 보이지 않는 경우
핑이 되지 않을 때 대부분 이 경우일 겁니다. 터널링 구간을 기준으로 송신 측의 라우팅 테이블이나 수신 측의 방화벽을 확인해 봅니다.
Case 3: 수신 측에서 요청/응답 패킷이 보이지만 송신 측에서 응답 패킷이 보이지 않는 경우
수신 측에 요청 패킷이 잘 도달되었으나 보내는 응답 패킷이 제대로 돌아오지 않는 경우로, 수신 측의 라우팅 테이블이나 송신 측의 방화벽을 확인해 봅니다.
부록 – 윈도우 VPN 자체가 아닌 윈도우 VPN이 속한 서브넷의 다른 인스턴스가 구성된 경우
윈도우 서브넷의 다른 인스턴스에서 AWS VPN 측에 핑 확인을 해보기 위해서는 아래와 같이 AWS 콘솔에서 윈도우VPN이 있는 서브넷의 라우팅 테이블에 AWS VPN 측 서브넷이 윈도우 VPN의 인터페이스를 게이트웨이로 하여 추가하여야 합니다.
윈도우 VPN단의 핑 보내는 측
주의! 이 구성에서는 터널링이 만료되었을 때 사설 네트워크의 다른 인스턴스가 AWS VPN 측에 패킷을 보내도 터널링이 개시되지 않습니다.
윈도우 VPN 라우터 측
이 때는, 다른 인스턴스와 윈도우 VPN 사이 교환되는 ICMP 패킷과 윈도우 VPN과 AWS VPN 사이 교환되는 터널링 패킷을 모두 확인할 수 있습니다.
AWS VPN의 핑 받는 측
수신 측에서는 일반 구성시와 마찬가지로 종단의 아이피들로 핑 패킷이 교환되는 것을 확인할 수 있습니다.
맺음말
이상으로 윈도우서버의 VPN 기능을 사용해서 AWS VPN 테스트 구성 및 여러 가지 문제 증상에 대한 트러블슈팅 방법에 대해 알아보았습니다. 클라우드로 VPN 연동을 구성할 때 참고가 되시길 바라겠습니다.