이상한점 하나

이번에 회사에서 업무중에 이해가 안되는 현상을 마주쳤었다. 네트워크 환경 셋팅 업무였는데, 서로 다른 두가지 케이스에서 패킷을 쏠 때 다른 결과가 나오는 문제였다. 상황에 대해 자세히 설명하면 아래와 같다. 나도 조금 문제가 있는 구조라고 생각했는데, 일단 급하다고 해서 어쩔 수 없이 확장성을 고려하지 않고 환경을 구성했다.

다음과 같이 인터넷상에 로봇(라즈베리파이)이 있고, 각 로봇이 서버(window 11))로 패킷을 보내야 하는 구조이다. 로봇1은 서버의 12번 포트, 로봇2는 13번 포트로 패킷을 전송한다. 이때 아래와 같이 두가지 버전으로 명령을 전송했었다.

1. 공인아이피로 명령 전송

2. 내부아이피로 명령 전송

그런데 공인 아이피로 명령 전송할 때는 UDP로 보내는 영상이 잘 스트리밍이 되었지만, 내부아이피로 보낼때는 영상이 계속해서 깨지고, 프레임이 버벅거리는 문제가 있었다.

우선 VPN이란?

일단 무엇이 저런 차이를 만들었는지에 대해 알아보기전에 VPN이 뭔지부터 자세히 복습하고 넘어가려고 한다. AWS 홈페이지에 따르면 “VPN 또는 가상 사설 네트워크는 인터넷을 통해 디바이스 간에 사설 네트워크 연결을 생성합니다. VPN은 퍼블릭 네트워크를 통해 데이터를 안전하게 익명으로 전송하는 데 사용됩니다. 또한 사용자 IP 주소를 마스킹하고 데이터를 암호화하여 수신 권한이 없는 사람이 읽을 수 없도록 합니다” 라고 한다. 즉 VPN이란 특정 기기(내 경우에는 Iptime에서 설정한 VPN서버)사이에 암호화 터널을 생성하여, 이를 통해 통신하는 방법을 의미한다.

그렇다면 VPN이 설정된 환경에서는 네트워크 패킷이 VPN Client와 VPN Server사이의 암호화 터널과 VPNServer와 패킷의 목적지 사이의 라우팅으로 통해 데이터가 교환된다는 뜻이다. 이를 내가 구축한 환경에서 표현하면 아래 그림과 같이 통신한다고 이해할 수 있다.

그렇다면 두 case의 차이는 패킷이 VPN서버에 도착해서 iptime에서 라우팅 규칙에 따라 라우팅되느냐, 내부아이피를 통해 자동으로 라우팅되어 가느냐 차이밖에 없는것 같은데 뭐가 문제인지 이해가 가지 않는다.

라우팅 테이블

먼저 컴퓨터 내부에서는 여러개의 네트워크 연결이 존재^{wifi, 이더넷 연결이 모두 존재하는 등} 할 때, 트래픽을 어떤 연결을 통해 보내야 할지를 정해야 한다. 이렇게 트래픽을 어떻게 보내고, 분배할지에 대한 규칙이 라우팅 테이블에 정의가 된다. 즉 라우팅 테이블이란 네트워크 장비(예: 라우터, 컴퓨터, 서버)에서 패킷을 어디로 보내야 할지 결정하는 정보를 담고 있는 데이터 구조이다.

라우팅 테이블은 위 표와 같은 구성을 갖는데 간단하게 하나씩 살펴보자. 먼저 Network Destination과 Netmask는 함께 사용되며 각각 목적지 네트워크의 IP 주소와 대상 주소를 설명할 때 쓰이는 값이다. 특정 패킷의 목적지 ip와 Netmask를 AND연산 한 결과가 Network Destination과 같으면 해당 행의 정보를 통해 패킷이 이동하게 된다. 두번째로 Gateway는 물리적으로 연결된 이웃 네트워크 기기의 실제 IP주소이다. Interface는 해당하는 이웃 노드로 이동하기 위한 실제 기기 내부의 어뎁터이다. 마지막으로 Metric은 특정 패킷의 주소를 만족하는 Network Destination과 Netmask가 여러개일 경우 먼저 선택해야하는 우선순위이다.

이러한 정보를 통해 네트워크 장비에서는 패킷을 이웃 네트워크 기기중 어떤 기기로 보낼지 선택하게 된다.

VPN연결 시 라우팅 테이블

그렇다면 실제 내가 구축한 환경에서 VPN연결 전후로 라우팅 테이블이 어떻게 구성되는지 확인해보자.

우선 위 사진은 VPN연결이 없는상태에서의 라우팅 테이블이다. 보이는 것처럼 모든 트래픽이 eth0 (XXX.XXX.101.X 네트워크)을 통해 나가도록 설정되어있다. 이는 로컬 네트워크 환경에서 상단의 공유기만 연결되어있기 때문에 이더넷 케이블로 연결이 하나만 존재하여 당연한 결과인 것 같다.

하지만 VPN연결이 되면 위와 라우팅 테이블이 위 사진과 같이 바뀌게 된다. 한줄씩 천천히 읽어보면, 기본적으로 default dev ppp0 proto static scope link metric 100을 통해 모든 패킷이 vpn연결을 통해 가상으로 만들어진 네트워크 연결인 ppp0으로 나간다. 하지만 VPN 서버 아이피 via 로봇 쪽 공유기 아이피 dev eth0 proto static metric 100을 통해 다이렉트로 VPN서버 아이피로 가는 패킷의 경우 이전과 같이 eth0을 통해 나가게 되어 vpn연결을 통해 패킷이 나가는게 아니라, 기존의 이더넷 연결을 통해 나갈 수 있게 라우팅 테이블이 설정되어있다.

결국 공인 아이피로 명령 전송할 때 잘 스트리밍이 되었던 이유는 위 사진과 같이 실제로 vpn연결이 아니라 이전과 같은 방법으로 eth0 interface를 통해 패킷이 전송되어 암호화를 하지 않고 보내서 빠르게 전송이 되었던 것이다.

L2TP VPN Connection Sequence

그렇다면 왜 모든 패킷이 VPN터널을 통해 통신하지 않고 VPN서버와 통신할 때는 예외 케이스로 남겨뒀을까? 인터넷에 찾아봐도 정확한 정보는 나오지 않았지만, 여러 자료를 보고난 뒤에 의심되는 부분은 vpn연결과 해제를 위한 통로 인 것 같다. 아래 내용은 cisco에서 L2TP 터널의 연결과 종료 로직에 대해 정리한 글을 바탕으로 작성하였다.

위 사진은 L2TP연결시 통신 시퀸스이다. 그림을 보면 NCP(Network Control Protocol)이 존재하는데 이 동작은 L2TP LAC(Access Concentrator)^{유저 단 VPN Client}과 L2TP Network Server(LNS)^{VPN Server}간의 통신이다. 이 동작은 아래와 같은 작업을 진행할때 필요하다.

링크 설정: 링크 설정 단계의 일부로, PPP는 링크가 인증 단계(해당되는 경우)로 들어가기 전에 완료되고 선언되어야 하는 LCP 함수를 사용하며, 네트워크 레이어 열기를 협상합니다.LCP는 PPP 링크를 종료하는 데에도 사용됩니다.

Authentication(인증): 인증 단계는 구현에 따라 다르며 LCP에서 NCP로 이동하기 위한 필수 요건이 아닙니다.LCP 단계 중에 협상 및 동의한 경우 원격 피어는 자신을 식별하고 합의된 인증 방법을 통과해야 PPP가 네트워크 레이어로 이동됩니다.

네트워크 레이어: NCP 협상은 두 피어가 L3 프로토콜의 특성에 동의하도록 보장합니다.IP의 경우 제어 프로토콜을 IPCP(IP Control Protocol)라고 합니다. 피어 간의 협상 외에도 할당 요소도 있습니다.이는 할당된 IP 주소가 없고 서비스 공급업체에 의존하여 연결 시 IP 주소를 할당하는 Microsoft Windows 유형 원격 액세스 클라이언트에서 흔히 발생합니다.

링크 종료: 통화 수명 주기 동안 언제든지 링크 종료 단계를 입력할 수 있습니다.LCP는 종료 요청을 전달하는 데 사용됩니다.

하지만 이 통신 User가 직접 LNS와 통신해야하는 동작이기 때문에 위와 같은 예외 케이스를 만든게 아닌가 싶다.

후기

사실 이렇게 찾아보기 전까지는 VPN연결을 하면 무조건 모든 패킷이 VPN터널을 통과하여 데이터가 오고가게 바뀌는줄 알았는데, 실제로 라우팅 테이블을 확인해보며 VPN에 대해 더 자세히 알게 된 것 같다. 앞으로 네트워크 셋팅할 때 더 정확히 알고 빠르게 수행 할 수 있을 것 같다.