가는 길과 돌아오는 길 — 라우팅·NAT·분할 터널

한 줄 요약

VPN 대역의 패킷이 사내 서버에 닿게 하는 길은 둘입니다 — 사내망에 「10.8.0.0/24 는 VPN 게이트웨이로」 를 알려 주는 라우팅, 그리고 게이트웨이가 출발지를 자기 주소로 바꾸는 NAT. 터널로 무엇을 보낼지도 둘입니다 — 사내 대역만(분할 터널), 전부(전체 터널).

왜 이게 필요했나

1모듈 끝에서 본 장면을 다시 떠올려 봅시다. 포워딩을 켜자 요청은 사내 서버에 닿았는데 답은 엉뚱한 NIC 로 나갔습니다. 사내 서버는 자기 경로 표대로 답할 뿐이고, 그 표에 10.8.0.0/24 가 없으면 기본 경로를 고릅니다. 실무에서 VPN 장비는 대개 사내망의 기본 게이트웨이가 아닙니다 — 방화벽이나 코어 스위치가 기본 게이트웨이이고 VPN 장비는 그 옆에 붙은 기계 하나입니다. 그래서 「터널은 붙는데 아무것도 안 열린다」 가 VPN 도입 첫날의 가장 흔한 문의입니다.

어떻게 동작하나

라우팅. 사내 라우터(이 실습에서는 사내 서버가 그 역할)에 10.8.0.0/24 via 10.10.0.1 을 넣습니다. 출발지가 그대로라 사내 서버의 기록과 방화벽 규칙을 직원(VPN 주소) 단위로 쓸 수 있습니다. 대신 VPN 대역이 사내의 다른 대역과 겹치지 않게 처음부터 주소 계획에 넣어야 하고, 사내 라우터를 만질 권한이 있어야 합니다.

NAT. 게이트웨이가 사내망으로 나가는 VPN 패킷의 출발지를 10.10.0.1 로 바꿉니다(masquerade). 사내 서버는 게이트웨이에게 답하고, 게이트웨이의 연결 추적이 그 답을 원래 노트북으로 되돌립니다. 사내망을 하나도 안 만지니 설치가 쉽습니다. 대신 사내 서버의 기록에는 모든 직원이 한 주소로 남습니다. AWS Client VPN 이 IPv4 에서 이쪽을 골랐습니다 — VPC 안의 서버에는 Client VPN 네트워크 인터페이스의 주소가 보이고, 누가 붙었는지는 연결 기록으로 따로 봅니다.

분할 터널. 서버가 사내 대역 경로만 밀어 주면(push route) 노트북의 인터넷 트래픽은 원래 기본 경로로 나갑니다. 회사 회선을 아끼고 화상회의가 빠릅니다. 그 대신 회사는 그 트래픽을 보지도 막지도 못하고, 노트북이 동시에 두 망에 걸쳐 있습니다.

전체 터널. redirect-gateway def1 은 기본 경로를 지우지 않고 0.0.0.0/1 과 128.0.0.0/1 두 경로를 tun 으로 더합니다. 둘 다 /0 보다 길어서 가장 긴 접두어 규칙으로 이기고, VPN 이 끊기면 원래 기본 경로가 그대로 남아 있습니다. 노트북의 인터넷 트래픽이 게이트웨이로 오므로 게이트웨이는 그것을 인터넷 쪽 NIC 의 주소로 NAT 해 내보내야 합니다(사설 10.8.x 로는 인터넷이 답할 수 없습니다). 그리고 OpenVPN 은 서버 주소 하나만은 터널이 아니라 「VPN 전의 기본 게이트웨이」 로 보내는 /32 경로를 따로 만듭니다 — 터널을 실어 나르는 패킷 자신이 터널로 빨려 들어가지 않게 하는 장치입니다.

전체 터널이 삼키는 것들. 이 실습 환경을 만들며 전체 터널을 처음 켰을 때 노트북이 통째로 끊겨 다시는 닿지 않았습니다(2026-11-01). 원인은 둘이었습니다. 0/1·128/1 이 노트북의 관리망(세션망을 실어 나르는 바깥 망, 채점과 이름 풀이)까지 터널로 삼켰고, 서버로 가는 /32 우회 경로가 기본 경로 쪽 NIC 를 가리켰는데 이 망에서는 서버가 그쪽에 없었습니다. 그래서 이 환경에는 관리망을 늘 바깥 NIC 로, 세션망을 늘 eth1 로 보내는 플랫폼 경로가 깔려 있습니다. 현장의 같은 사고는 「전체 터널을 켰더니 집 프린터·NAS 가 안 보인다」, 「원격 관리 도구가 끊겼다」 입니다. 클라이언트 쪽의 route <대역> net_gateway 가 그 대역만 VPN 전의 게이트웨이로 빼는 장치입니다.

VPN 대역 고르기. 라우팅으로 붙이든 NAT 로 붙이든 VPN 대역(이 실습의 10.8.0.0/24)은 사내의 어떤 대역과도, 그리고 직원들의 집 대역과도 겹치면 안 됩니다. 사내에 이미 10.8.0.0/16 을 쓰는 지사가 있으면 그쪽으로 가는 패킷이 터널로 빨려 들어가고, 직원 집 공유기가 사내망과 같은 192.168.0.0/24 를 쓰면 노트북은 사내 서버 주소를 자기 집 안에서 찾습니다. 그래서 VPN 대역은 VPC·지사·사무실 대역과 함께 주소 계획표에 처음부터 적어 두고, 집에서 흔한 192.168.0.x·192.168.1.x 는 피합니다. AWS Client VPN 의 클라이언트 CIDR 도 연결할 VPC 대역과 겹치면 만들어지지 않습니다.

사람마다 다르게. 서버의 client-config-dir 디렉터리에 인증서 CN 이름으로 파일을 두면 그 사람에게만 push 가 갑니다. 관리자·외주 인력만 전체 터널, 특정 직원에게만 추가 대역, 고정 VPN 주소(ifconfig-push) 같은 정책이 여기서 걸립니다.

현장에서 만나는 모습

재택 전환 첫 주에 전체 터널로 시작했다가 회사 인터넷 회선이 화상회의로 꽉 차 분할 터널로 바꾼 회사가 많습니다. 반대로 분할 터널로 두었다가 「노트북이 회사망과 카페 와이파이에 동시에 걸쳐 있다」 는 감사 지적을 받고 관리 대상 기기만 전체 터널로 바꾸기도 합니다. 어느 쪽이든 경로 표가 진실입니다 — 설정 화면이 아니라 노트북의 ip route get <목적지> 로 확인하세요.

다음 실습에서 할 것

포워딩만 켠 상태의 비대칭 경로를 tcpdump 로 잡고, NAT 와 돌아오는 경로로 각각 풀어 사내 서버가 보는 출발지를 비교합니다. 분할 터널의 경로를 적은 뒤 전체 터널로 바꾸고, 한 사람만 전체 터널로 두고, 집 공유기 대역을 터널 밖으로 뺍니다.