[EC2] EC2에서 OpenVPN Client 설치해서 프라이빗 클라우드 호스팅하기 (ssh 연결 끊김 현상)

🧐 들어가기전

❓ 프라이빗 클라우드 자원 활용 및 외부 접근성 확보에 대한 고민

학교에서 이번에 Cloud 관련 사업을 하면서 실습 환경을 제공해주기 위해 학생마다 프라이빗 클라우드를 사용할 수 있는 기회를 얻었고, 생각보다 쓸 수 있는 자원이 넉넉하였다. 따라서 해당 머신에서는 평소에 메모리를 많이 잡아먹어 하지 못하였던 실습들을 할 수 있는 기회를 얻어 너무너무 좋았다.(오픈스택, elk 등등..)

하지만 프라이빗 클라우드 환경의 특성상 각 인스턴스에 프라이빗 IP만 발급되는 구조적인 한계가 있었다. 이로 인해 해당 인스턴스에 접근하려면 VPN을 통해 사설 네트워크 망으로 접속하는 것이 필수적이었고, 이는 서비스 호스팅이나 외부와의 직접적인 공유 측면에서 아쉬웠다.

최근에 진행 중인 프로젝트

최근에 프로젝트를 진행하면서 이 빵빵한 인스턴스를 어떻게든 활용하고 싶었다. 그나마 Prometheus 같은 경우에는 Main Server로 가서 메트릭 정보를 pull 방식으로 가져오기에 아웃바운드에는 제약이 없는 프라이빗 클라우드를 활용할 수 있었다. 하지만 이렇게 구축은 가능해도 결국 Grafana를 통한 메트릭 정보를 모니터링 하려면 vpn을 켜야한다는 불편함이 있었고 이는 팀원 간의 공유 측면에서 원활하지 못하였다.

 

💡 EC2를 활용한 프라이빗 클라우드 호스팅 아이디어 구상

그러다 문득 이러한 문제 상황을 해결하기 위한 방안으로, AWS의 EC2 서버를 활용하는 아이디어를 구상했다. 구체적으로는 EC2 인스턴스 하나를 마치 라우터처럼 활용하여 다음과 같은 방식으로 프라이빗 클라우드의 외부 접근성을 확보하는 것이다.

 

1. EC2 인스턴스에 OpenVPN Client 설치
   AWS EC2 인스턴스와 프라이빗 클라우드 네트워크 사이에 안전한 VPN 터널을 구축한다.
2. EC2 인스턴스의 Public IP 활용
   EC2 인스턴스에 할당된 Public IP를 외부 접근을 위한 주소로 사용한다.
3. Nginx를 통한 트래픽 포워딩
   EC2 서버에 Nginx를 설치하고 설정하여, 해당 Public IP와 연결된 도메인 주소로 외부 사용자들이 접속했을 때, Private Cloud 내부의 원하는 서비스로 트래픽을 안전하게 포워딩한다.

 

이러한 접근 방식을 통해 프라이빗 클라우드 내부의 인스턴스들도 마치 퍼블릭 클라우드의 자원처럼 외부에서 직접 접근 가능하게 하여, 서비스 호스팅이 가능하다고 판단이 들었다.

---

🚨 문제 발생

1️⃣ Open VPN 클라이언트 설치 시 SSH 접속 불가

🔹Open VPN 클라이언트 초기 세팅 및 실행

sudo mkdir -p /etc/openvpn/client/
sudo mv ~/{학번}.ovpn /etc/openvpn/client/

우선 기존에 가지고 있던 OpenVPN 프로파일을 서버로 넘긴 후 위와 같이 openvpn 디렉터리 안으로 ovpn 파일을 이동시켰다.

# systemd 재로드
sudo systemctl daemon-reload

# 서비스 활성화
sudo systemctl enable openvpn-client@{학번}.service

# 서비스 시작
sudo systemctl start openvpn-client@{학번}.service

그런 다음, 위와 같이 openvpn-client service를 실행시켰다.

 

🔹문제 발생

그러나 위와 같이 실행시키자마자 갑자기 서버가 끊기고 다시 재접속이 안되는 현상이 발생하였다.

심지어 aws에서 브라우저 기반 콘솔로도 접속이 되지 않았다. 보통 메모리 용량이 초과해서 서버가 터지는 경우는 리부트하면 다시 접속할 수 있었는데 이번에는 상황이 달랐다. 아무리  리부트를 다시해봐도, 인스턴스를 중지시키고 다시 실행시켜보아도 해당 인스턴스로 여전히 접근할 수 없었다.

 

따라서 해당 문제는 서버 자원 문제가 아닌 네트워크 문제라고 판단이 들었다.

 

Open VPN으로 VPN을 키는 순간 네트워크의 문제로 인하여 기존의 인스턴스의 ip로 접근할 수가 없었던 것이다.

---

2️⃣ OpenVPN의 구성

OpenVPN은 안전한 가상 사설망을 구축하기 위해 특별한 가상 네트워크 인터페이스를 사용한다. OpenVPN이 사용하는 주요 가상 인터페이스는 TUN(Tunnel)과 TAP두 가지이다. 이 둘은 OSI 모델의 다른 계층에서 작동하며, 각기 다른 특성과 용도를 가진다.

https://liujunming.top/2022/07/31/Notes-about-TUN-TAP-Interface/

🔹1. TUN (Tunnel) 인터페이스: IP 패킷을 위한 라우팅 터널

TUN 인터페이스는 OSI 모델의 네트워크 계층(3계층)에서 작동한다. TUN을 사용하는 VPN 연결에서는 클라이언트에게 새로운 IP 주소가 할당되며, 이 IP 주소를 통해 트래픽이 VPN 서버로 라우팅된다.

• 주요 특징:
  • IP 패킷 처리: TUN은 오직 IP 패킷만을 캡슐화하고 전송
  • 효율성: IP 패킷 헤더만 포함하여 캡슐화하므로 오버헤드가 적어 일반적으로 TAP보다 빠르고 효율적
  • 라우팅 기반: 주로 원격에 있는 개별 호스트나 네트워크 간의 연결(Point-to-Point)에 사용된다. 클라이언트의 라우팅 테이블이 변경되어 특정 목적지 IP 또는 모든 트래픽이 VPN 터널로 향하도록 설정
  • 브로드캐스트/멀티캐스트 제한: 기본적으로 네트워크상의 브로드캐스트나 멀티캐스트 트래픽을 터널링하지 않는다.

https://blog.naver.com/rpg2003a/221209134202

🔹2. TAP 인터페이스: 이더넷 bridging을 위한 가상 LAN 카드

TAP 인터페이스는 OSI 모델의 데이터 링크 계층(2계층)에서 작동한다. 이는 실제 물리적인 이더넷 카드처럼 동작하며, IP 패킷뿐만 아니라 MAC 주소를 포함하는 이더넷 프레임 전체를 처리한다. TAP를 사용하는 VPN 연결에서는 VPN 클라이언트가 마치 VPN 서버가 속한 물리적 로컬 네트워크에 직접 연결된 것처럼 bridging 될 수 있다.

• 주요 특징:
  • 프로토콜 독립성: IP 이외의 다양한 네트워크 프로토콜의 트래픽도 터널링할 수 있음
  • 이더넷 브릿징: VPN 클라이언트의 가상 TAP 인터페이스가 VPN 서버가 속한 물리적 네트워크 인터페이스와 bridging되어 VPN을 통해 마치 로컬 LAN에 있는 것처럼 통신이 가능
  • 브로드캐스트/멀티캐스트 지원: 브로드캐스트 및 멀티캐스트 트래픽을 VPN 터널을 통해 전송 가능
  • 오버헤드: 이더넷 프레임 전체를 캡슐화해야 하므로 TUN 인터페이스보다 데이터 오버헤드가 커서 상대적으로 성능 저하가 발생할 수 있음

---

3️⃣ 문제점 분석

🔹Open VPN Client를 실행하기 전

openVPN 연결 전의 ip route

인스턴스(4.3.2.1/24)가 OpenVPN 연결 전에는 내 로컬 머신(9.8.7.6/24)과 성공적으로 SSH 연결을 맺을 수 있다.

 

🔹Open VPN Client를 실행한 후

이 상태에서 인스턴스에서 OpenVPN 연결을 시작하면 새로운 tun0 인터페이스가 활성화(가상의 IP 10.0.0.2)된다.

 

이때, 만약 원격 OpenVPN 서버가 클라이언트에 어떤 라우팅 규칙도 푸시하지 않는다면 SSH 연결은 문제없이 유지된다.

그러나 원격 OpenVPN 서버가 인스턴스의 기본 게이트웨이를 10.0.0.1 (원격 OpenVPN 엔드포인트)로 교체하도록 푸시하는 경우 문제가 발생한다. 이 상황에서는 OpenVPN 자체 트래픽을 제외한 모든 외부 통신이 VPN 터널을 통해 이루어지게 된다.

 

이것이 바로 비대칭 라우팅 문제를 야기한다.

• 내 머신(9.8.7.6)에서 인스턴스(4.3.2.1)로 가는 트래픽은 기존 경로를 통해 흐른다.
• 하지만 인스턴스(4.3.2.1)에서 내 머신(9.8.7.6)으로 돌아오는 트래픽은 VPN 연결 설정 후, 기본 게이트웨이가 10.0.0.1로 변경되어 VPN 터널을 통해 라우팅된다.

흐름을 정리하자면 아래와 같다.

 

• 요청: 로컬 컴퓨터 -> 인터넷 -> EC2 서버의 공인 IP 주소
  • 여기까지는 SSH 요청이 EC2 서버에 정상적으로 도달한다.
• 응답: EC2 서버는 SSH 요청을 처리한 후, 로컬 컴퓨터로 응답 패킷을 돌려보내려 한다. 이때 문제가 발생한다.
  OpenVPN 클라이언트가 실행되면서 EC2 서버의 기본 라우팅 테이블이 변경된다. 이 라우팅 테이블은 EC2 서버의 모든 아웃바운드 트래픽을 VPN 터널(tun0 인터페이스)을 통해 VPN 서버로 보내도록 지시한다.
  • 따라서 SSH 응답 패킷은 EC2 서버의 원래 공인 IP 주소를 통해 인터넷으로 나가는 대신, VPN 터널 VPN 서버​ 인터넷 의 경로를 거쳐 나가게 된다.
  • SSH 요청은 EC2 서버로 직접 들어오지만, SSH 응답은 VPN 서버를 통해 다른 경로로 나가게 된다. 이렇게 요청과 응답이 다른 경로를 통하면, 중간에 있는 라우터나 방화벽 같은 네트워크 장비들이 이 패킷을 비정상적인 것으로 간주하고 드롭시켜버릴 가능성이 매우 높다. 즉 SSH 클라이언트는 응답을 받지 못하므로 연결이 끊어지거나 시간 초과 오류가 발생한다.
  • 또한 NAT의 관점에서, VPN 서버는 이 패킷을 인터넷으로 내보내면서 패킷의 출발지 IP 주소를 EC2 서버의 VPN 내부 IP가 아닌 자신의 공인 IP 주소로 바꿔치기한다. 그 결과 SSH 클라이언트가 보낸 IP주소로 부터 응답이 오는 것이 아닌 달라진 공인 IP 주소로부터 패킷이 오므로 예상치 못한 응답으로 간주하고 버리게 되는 것이다.

이 때문에 SSH 클라이언트는 유효하지 않은 응답을 받거나 아예 받지 못하게 되어 연결이 끊어지게 되는 것이다.

 

---

✨ 해결 방법

1️⃣ 라우팅 테이블 설정 

이 방법은 SSH 연결이 활성화된 상태에서 OpenVPN 클라이언트를 실행했을 때, SSH 응답 트래픽이 VPN 터널을 우회하고 EC2 서버의 원래 공인 IP 경로로 직접 돌아가도록 강제하는 것이다.

 

원리?

라우팅 테이블에서 더 구체적인(specific) 규칙은 덜 구체적인(general) 규칙(예: 0.0.0.0/0을 VPN으로 보내는 규칙)보다 우선시한다. SSH 클라이언트의 특정 IP 주소로 향하는 트래픽에 대해 원래 게이트웨이를 사용하도록 명시적인 규칙을 추가하여, VPN 라우팅 규칙보다 우선하게 만드는 원리이다.

 

sudo ip route add <내 로컬 머신 공인 IP> via <EC2 공인 IP> dev eth0

위와 같이 EC2의 ETH0 Gateway에서 내 로컬 머신 공인 ip로 라우팅 할 수 있도록 구체적인 규칙을 추가해준다.

라우팅 규칙을 추가한다면 위와 같이 ssh의 응답이 정상적으로 내 로컬 머신으로 도착할 수 있다.

🚨주의사항

 

하지만, 이 규칙은 특정 SSH 클라이언트 IP에만 적용된다. 다른 IP에서 SSH 접속을 시도하면 다시 문제가 발생할 수 있다.

따라서 해당 방식은 근본적인 해결책이 될 수 없으며 처음에 호스팅하고자 하는 목표에도 도달할 수 없다.

---

2️⃣ 스플릿 터널링

이 방법은 OpenVPN 클라이언트의 설정 파일을 수정하여 특정 트래픽만 VPN 터널을 통해 보내고 나머지 트래픽은 EC2 서버의 원래 인터넷 연결을 통해 직접 나가도록 하는 방법이다.

 

원리?

기본적으로 OpenVPN은 redirect-gateway 지시문을 사용하여 클라이언트의 모든 트래픽(0.0.0.0/0)을 VPN 터널로 보낸다. 스플릿 터널링은 이 기본 동작을 비활성화하고, VPN을 통해 접근해야 하는 특정 목적지 네트워크로의 트래픽만 VPN 터널을 통하도록 한다.

 

 

🔹Client.ovpn 파일 수정하기

client.ovpn

;redirect-gateway def1 bypass-dhcp

만약 해당 라인이 있다면 주석처리하여 기본 게이트웨이를 VPN 터널로 변경하지 않도록 한다.

 

route 10.0.0.0 255.0.0.0

해당 라인을 추가하여 특정 IP 대역으로의 트래픽만 VPN 터널을 통해 라우팅하도록 지시한다.

이때 10.0.0.0은 내가 접속하고자 하는 private cloud의 내부망 ip이다.

 

route-nopull

마지막으로 route-nopull을 사용하여 OpenVPN이 라우팅 테이블을 자동으로 변경하는 것을 막을 수 있다.

 

위와 같이 설정한다면 private cloud ip 대역에 대해서만 VPN을 통해서 통신하고 나머지 대역에 대해서는 직접 인터넷으로 나가도록 함으로써, SSH 연결 안정성을 확보하고 불필요한 트래픽이 VPN을 경유하면서 발생하는 성능 오버헤드도 줄일 수 있다.

 

10.0.0.0/8 대역대에 대해서만 tun0 인터페이스가 생긴 것을 확인할 수 있으며, 정상적으로 SSH 접근이 가능하다.

private cloud로 ping도 정상적으로 날라가는 것을 확인할 수 있다.

---

📙 출처

https://serverfault.com/questions/404501/openvpn-client-on-amazon-ec2

https://serverfault.com/questions/404501/openvpn-client-on-amazon-ec2

https://serverfault.com/questions/754462/setting-up-open-vpn-client-on-amazon-ec2