VPN 연결 전후 라우팅 테이블 변화와 우선순위 이해하기
VPN 연결 전후, 라우팅 테이블이 뭐가 그렇게 달라지나요?
라우팅 테이블은 쉽게 말해 “내 PC가 보낼 택배(패킷)를 어느 길로 보낼지 적어둔 주소록”이에요. 목적지 IP(주소)별로 “다음 경유지(게이트웨이)”가 정해져 있거든요. AWS 문서에 따르면 라우팅 테이블은 트래픽 경로를 제어하는 “규칙 세트”로 구성되고, 인터넷 게이트웨이·NAT·VPN 같은 대상으로 보낼지 결정할 수 있다고 해요(자료에 따르면: AWS VPC Route Tables).
즉 VPN을 켠다는 건, 이 주소록에 “회사/집(원격망)으로 가는 전용길”을 추가하거나, 경우에 따라 “모든 택배를 일단 VPN 택배사로” 보내도록 기본 길을 바꾸는 작업에 가깝습니다.
제가 2023년에 독일 베를린에서 원격으로 한국 본사망에 붙는 VPN 이슈를 봤을 때도, 체감 속도 문제의 8할은 결국 라우팅 테이블에서 기본 경로가 어디로 잡혔는지였거든요.
VPN 켜기 전: 기본 경로(디폴트 라우트)가 왕이에요
VPN 연결 전에는 보통 라우팅 테이블이 단순합니다.
내 PC가 붙어있는 로컬 네트워크(예: 192.168.0.0/24)는 그냥 공유기(또는 로컬 인터페이스)로
나머지 인터넷 전체는 “기본 경로(0.0.0.0/0)”로 공유기(기본 게이트웨이)로
여기서 핵심은 “가장 구체적인 경로가 이긴다”는 점이에요. 같은 목적지라도 더 좁게(더 구체적으로) 잡힌 경로가 우선권을 가져갑니다. 그래서 VPN이 들어오면 보통 “특정 대역으로 가는 더 구체적인 길”이 추가되면서 트래픽 흐름이 달라지죠.
실무에서 이 개념이 중요한 이유는, VPN 자체가 ‘암호화’보다 먼저 ‘어느 길로 보낼지’부터 결정해야 해서 여기서 삐끗하면 연결은 됐는데 서비스는 안 되는 상황이 바로 나오거든요.
VPN 켠 뒤 1: 스플릿 터널링이면 ‘회사로 가는 길’만 추가돼요
스플릿 터널링(split tunneling)은 “회사/특정 서비스로 가는 트래픽만 VPN으로, 나머지 인터넷은 원래대로” 보내는 방식이에요. 이때 라우팅 테이블 변화는 보통 이런 느낌입니다.
회사 대역(예: 10.0.0.0/8, 172.16.0.0/12 같은 사내망) → VPN 인터페이스(터널)로 가는 경로가 추가
기존 기본 경로(0.0.0.0/0)는 그대로 유지 → 유튜브/포털/게임은 평소처럼 집 공유기로 나감
클라우드 쪽에서도 논리는 같아요. 예를 들어 AWS Site-to-Site VPN에서는 원격 네트워크로 가는 경로를 라우트 테이블에 “가상 프라이빗 게이트웨이” 대상으로 넣어야 한다고 설명하거든요(자료에 따르면: AWS Site-to-Site VPN route priority). PC든 VPC든 “원격망으로 가는 길을 테이블에 추가한다”는 본질은 같습니다.
왜 스플릿을 쓰냐고요?
인터넷은 로컬로 빠져서 속도/지연이 유리할 수 있고
회사망 접근만 터널로 보호하면 트래픽이 덜 복잡해질 수 있어요
다만 이건 조직 정책/보안 요구에 따라 달라질 수 있습니다.
VPN 켠 뒤 2: 풀 터널링이면 기본 경로가 VPN으로 갈아타요
풀 터널링(full tunneling)은 “인터넷 포함 전부 VPN으로” 보내는 방식이에요. 라우팅 테이블 관점에서 제일 큰 변화는 이거예요.
기본 경로(0.0.0.0/0)가 VPN 인터페이스 쪽으로 바뀌거나,
VPN 쪽이 더 우선순위 높은 기본 경로를 하나 더 만들어서 사실상 VPN이 기본 출구가 됩니다
비유로 하면, 동네 택배를 포함해 모든 택배가 “일단 회사 물류센터(VPN)”로 모였다가, 거기서 다시 목적지로 재배송되는 구조죠.
여기서 실무적으로 흔한 장면이 하나 있어요. “VPN 서버 자체로 가는 길”은 예외로 로컬 게이트웨이를 유지해야 연결이 끊기지 않거든요. 그래서 특정 IP만 VPN이 아닌 특정 게이트웨이로 보내는 식의 라우트가 필요할 때가 있습니다. OpenVPN 라우팅 관련 질의응답에서도 특정 IP로 가는 트래픽을 지정한 경로로 보내는 설정 예가 언급돼요(자료에 따르면: Unix & Linux Stack Exchange의 OpenVPN 라우팅 예시).
요지는 “전부 VPN으로 보내되, VPN 연결을 유지하기 위한 최소한의 예외 경로는 남겨둔다”는 겁니다.
“겹치는 경로”가 있으면 누가 이기나요? (우선순위 감각)
VPN 켰는데도 어떤 서비스는 로컬로 새거나, 반대로 원치 않는데 VPN으로 빨려 들어가는 경우가 있죠. 대부분 “겹치는 경로” 때문입니다.
AWS Site-to-Site VPN 문서에서는 겹치거나 중복되는 경로가 있을 때 로컬 경로가 우선될 수 있고, 같은 CIDR이면 전파된 경로보다 정적 경로가 우선될 수 있다고 설명해요(자료에 따르면: AWS Site-to-Site VPN route priority). 이 얘기를 PC로 가져오면 이런 감각으로 이해하면 됩니다.
더 구체적인 목적지 대역(예: /32, /24)이 더 넓은 대역(/0, /8)보다 우선
같은 목적지라면 “우선순위/메트릭(metric, 비용)”이 낮은 쪽이 선택되는 경우가 많음(운영체제/환경마다 다를 수 있어요)
VPN 클라이언트가 라우트를 “추가만” 하는지, “기본 경로를 교체”하는지에 따라 체감이 확 달라짐
그래서 VPN 문제 해결의 1번은 “지금 라우팅 테이블에 어떤 규칙이 들어갔는지”를 보는 거예요.
참고로 이런 ‘가장 구체적인 경로가 우선’하는 원칙은 IETF의 IP 라우팅 관련 표준(RFC 1812 등)에서도 기본 전제로 깔려 있는, 네트워크 세계의 거의 헌법 같은 룰이기도 해요.
흔한 오해 3가지: VPN은 마법이 아니라 ‘길 안내’ 변경이에요
1) “VPN 켜면 무조건 더 안전하죠?”
VPN은 “내 트래픽이 어디로 흘러가게 할지”를 바꾸고, 그 구간을 암호화하는 데 강점이 있어요. 하지만 어떤 트래픽을 터널로 보낼지는 라우팅 테이블(정책)에 달려요. 즉 스플릿이면 인터넷 트래픽은 평소 경로로 나갈 수 있습니다.
2) “연결만 됐는데 사내 시스템이 안 열려요”
VPN은 연결(터널 생성)과 라우팅(어느 대역을 터널로 보낼지)이 둘 다 맞아야 해요. 클라우드에서도 서브넷에 어떤 라우트 테이블이 연결됐는지에 따라 길이 달라진다고 설명하거든요(자료에 따르면: Azure route table 관리 문서). PC에서도 “회사 대역 라우트가 실제로 추가됐나?”가 관건입니다.
3) “VPN 끄면 원래대로 100% 복구되죠?”
대부분은 복구되지만, 간혹 클라이언트가 추가한 경로가 깔끔히 제거되지 않거나, DNS/우선순위가 남아서 찝찝한 경우가 있어요. 환경마다 달라질 수 있으니, 문제 생기면 “현재 라우팅 테이블”을 확인하는 습관이 제일 확실합니다.
마무리: VPN 전후 변화는 결국 ‘기본길’과 ‘회사길’의 재배치예요
다만, 이 글에서 말한 변화는 ‘일반적인 PC/클라우드 VPN 구성’ 기준이라 회사 정책(강제 프록시, ZTNA, 전용 에이전트)이나 OS/클라이언트 종류에 따라 라우팅이 다르게 보일 수도 있습니다.
정리하면 이렇습니다.
VPN 연결 전: 기본 경로(0.0.0.0/0)가 인터넷으로 나가는 메인 출구
VPN 연결 후(스플릿): 회사/특정 대역으로 가는 경로만 VPN으로 추가
VPN 연결 후(풀): 기본 경로 자체가 VPN으로 바뀌어 인터넷도 터널로 감
문제의 대부분은 “겹치는 경로”와 “우선순위(구체성/메트릭)”에서 터집니다
VPN은 마법 방패가 아니라, 내 트래픽의 “길 안내 표지판(라우팅 테이블)”을 바꾸는 기술이거든요. 표지판만 잘 읽으면, VPN이 왜 어떤 때는 빠르고 어떤 때는 답답한지도 납득이 되실 거예요.