Site-to-Site VPN 사용기
이번 포스팅은 Site-to-Site (IPsec) VPN trouble shooting을 위해 이것 저것 찾아보던 중 생각보다 troueble shooting을 위한 정보가 다양하게 제공되지 않는 슬픔 😢 과 분노를 바탕으로 한다.
우리 회사는 다른 기업들이 그러하듯 On-prem 데이터 센터, 한국 사무실, 인도 사무실그리고 그 외 3rd Party 업체와 AWS를 (인터넷을 통해) 안전하게 연결하기 위해서 Site-to-Site VPN을 사용하고 있다.
내가 관리하는 사내 장비와 AWS 연결 시에는 사내 장비에 나오는 로그를 바탕으로 trouble shooting을 진행할 수 있었다. (아래 화면 참고)
하지만 이번에 데이터 센터를 이전하고 처음으로 3rd Party 업체와 연결을 맺으면서 Site-to-Site VPN 연결에 문제가 발생했다. 3rd Party의 장비 로그를 볼 수 없는 상황에서 내가 AWS를 통해 확인을 할 수 있는 정보는 Site-to-Site VPN의 Up/Down 여부 뿐이었다. 😭
AWS느님이 이렇게 야박할리가 없다며 반나절을 꼬박 Site-to-Site VPN Trouble shooting, Logging에 관하여 찾아봤는데.. 아직까지 유의미한 정보를 찾을 수 없었다.
일단 AWS Site-to-Site와 관련한 정보는 아래 AWS 관련 문서에서 찾을 수 있다.
위의 공식문서를 통해 알 수 있는 건.. AWS Site-to-Site 모니터링을 위해서 사용하는 AWS는 크게 CloudWatch, CloudTrail, AWS Health check 라는 것.
하지만 위의 3가지 서비스를 통해서는 Site-to-Site VPN의 Up/Down 여부 그리고 해당 VPN을 통해 흐르는 트래픽/데이터량 그리고 하나의 VPN당 2개의 터널이 생기는 AWS Site-to-Site VPN 특성 상, 두 tunnel의 생존 여부 정도만 파악할 수 있다.
즉, 내가 사내 네트워크 장비를 통해 볼 수 있었던 ‘왜 연결이 불가한지에 대한 상세 로그: IKE 버전 상이, Encryption 알고리즘 매칭 불가 등..)’ 에 대해서는 알 수 없는 것 같다.
그리고 또 한가지, 사내에서 관리 중인 Fortigate 방화벽의 경우, IPsec VPN (Site-to-Site VPN)을 Force Bring up 할 수 있는 기능과 생성되어 맺어진 터널을 임시로 down 시킬 수 있는 기능이 있었는데 AWS에서는 공식으로 그런 기능을 제공하지 않는다고 한다.
Site-to-Site VPN trouble shooting 관련 문서를 찾으면 죄다 이런식이다. ㅜㅜ 우리는 그런 기능 없으니 Customer Gateway Device 즉, 연결을 맺은 상대방 장비에서 로그를 찾거나 기능을 찾으라는… (거 너무 불친절한거 아니오 😠)
암튼 유의미한 자료를 찾기 전까지는 이렇게 정리를 해보려고 한다.
결론은 AWS Site-to-Site VPN trouble shooting은 CGW의 전적인 지원이 필요하다!
🍰
