When VPN Meets Split-Horizon DNS
OpenConnect SSL VPN을 구축하고 Cisco AnyConnect 클라이언트로 VPN을 운영하고 있다. 외부에서 내부망에 접속하기 위한 용도인데, VPN을 연결하면 내부 IP로는 모든 접근이 잘 되고 NAT를 통한 인터넷도 가능한데, 외부 접속용으로 만들어놓은 도메인들이 전부 먹통이 되는 현상이 있었다. 도메인만 안 되고 IP는 되는, 꽤 성가신 문제였다.
증상 정리
VPN 연결 후 상태는 이랬다.
- 내부 IP 직접 접근: 정상
- NAT를 통한 인터넷: 정상
- 외부 공개용 도메인 접근: 실패
이 조합이면 원인은 보통 둘 중 하나다.
- DNS 문제 : VPN 연결 시 ocserv가 클라이언트에 내려주는 DNS가 내부 도메인을 제대로 해석하지 못하는 경우
- Hairpin NAT 문제 : 외부 도메인이 공인 IP를 가리키고 있는데, VPN 클라이언트가 그 공인 IP로 다시 돌아올 때 방화벽이 NAT loopback을 안 해주는 경우
내부 IP로는 접속이 되니까 라우팅 자체는 문제가 없다. 도메인만 안 되는 거라면 결국 이름 해석의 문제다. 실제로 확인해보니, ocserv가 VPN 클라이언트에 dns = 8.8.8.8을 내려주고 있었다. VPN을 붙으면 클라이언트의 DNS가 구글 퍼블릭 DNS로 바뀌는데, 이 DNS는 당연히 내부 도메인을 알 리가 없다. 외부 공개 도메인이라 해도 공인 IP를 응답하니까, VPN 터널 안에서 다시 공인 IP로 돌아가려는 패킷이 hairpin NAT 없이는 실패한다.
해결 방향: Split-Horizon DNS
근본적인 해결책은 VPN 클라이언트가 내부 DNS를 사용하게 만드는 것이다. 내부 DNS가 상황에 맞는 응답을 해주면 된다.
구조는 단순하다.
- 내부 전용 도메인 → 내부 IP 응답
- 외부 공개 도메인이지만 VPN에서는 내부로 접근해야 하는 것 → 내부 IP 응답
- 그 외 일반 인터넷 도메인 → 외부 DNS로 포워딩
이걸 하려면 내부 DNS 서버가 필요하다. DNS 소프트웨어 선택지는 크게 세 가지였다.
| dnsmasq | unbound | PowerDNS | |
|---|---|---|---|
| 장점 | 설정이 가장 단순 | 리졸버 역할에 강하고 운영 안정적 | DB 백엔드, API, 대규모 운영에 강함 |
| 단점 | 레코드 많아지면 관리가 투박 | 초기 설정 감이 약간 필요 | VPN용 리졸버 목적에는 과한 구성 |
| 적합한 경우 | 빠르게, 간단하게 | 정석적이고 오래 쓸 구조 | DNS를 서비스처럼 크게 운영할 때 |
PowerDNS는 이 용도에는 과하다. Authoritative + Recursor를 분리해야 해서 구조가 복잡해진다. 지금 필요한 건 VPN 클라이언트용 내부 DNS 리졸버 + 몇 개 도메인 override 정도라서, dnsmasq나 unbound가 적합하다. 둘 다 써봤는데 unbound가 구조가 더 정돈되어 있고 확장성도 좋아서 unbound를 선택했다.
네트워크 구성 파악
본격적으로 작업하기 전에 현재 네트워크 구조를 정리했다.
172.20.0.0/16: 내부 전용 대역. 서버, 스토리지 등이 여기 있다.10.50.0.0/16: 리버스 프록시(nginx) 대역. 외부 도메인들이 여기 nginx를 통해 들어온다.192.168.70.0/24: VPN 클라이언트에게 할당되는 대역.
firewalld 존 구성은 이랬다.
# firewall-cmd --get-active-zones
internal
sources: 172.20.0.0/16
public
interfaces: eth0 eth1 eth2
reverseproxy
sources: 10.50.0.0/16
# firewall-cmd --zone=public --list-all
public (active)
target: default
icmp-block-inversion: yes
interfaces: eth0 eth1 eth2
services: dhcpv6-client ftp http https ipsec l2tp ntp
ports: 463/tcp 4443/tcp 4443/udp
masquerade: yes
forward-ports:
port=10322:proto=tcp:toport=22:toaddr=172.20.4.1
port=10522:proto=tcp:toport=22:toaddr=172.20.5.1
port=19739:proto=tcp:toport=3389:toaddr=172.20.110.112
port=19839:proto=tcp:toport=3389:toaddr=172.20.110.111
...
rich rules:
rule family="ipv4" source address="192.168.70.0/24" masquerade
# firewall-cmd --zone=internal --list-all
internal (active)
target: default
sources: 172.20.0.0/16
services: dhcpv6-client mdns samba-client ssh
forward: no
masquerade: yes
# firewall-cmd --zone=reverseproxy --list-all
reverseproxy (active)
target: default
sources: 10.50.0.0/16
services:
forward: no
masquerade: yes
public zone에 포트포워딩과 masquerade가 걸려있고, internal과 reverseproxy는 소스 기반으로 분리되어있다. 그리고 VPN 대역인 192.168.70.0/24에 대해서는 public zone의 rich rule로 masquerade만 걸려있는 상태다.
ocserv 핵심 설정은 이 상태였다.
# grep /etc/ocserv/ocserv.conf
ipv4-network = 192.168.70.0/24
tunnel-all-dns = true
dns = 8.8.8.8
문제의 핵심이 보인다. dns = 8.8.8.8이다.
unbound 설치와 설정
설치
dnf install -y unbound
설정 파일 작성
/etc/unbound/unbound.conf
server:
verbosity: 1
statistics-interval: 0
statistics-cumulative: no
extended-statistics: yes
num-threads: 4
log-time-ascii: yes
pidfile: "/var/run/unbound/unbound.pid"
include: /etc/unbound/local.d/*.conf
interface: 127.0.0.1
interface: 3.12.0.1
interface: 9.7.1.1
port: 53
do-ip4: yes
do-udp: yes
do-tcp: yes
access-control: 127.0.0.0/8 allow
access-control: 172.20.0.0/16 allow
access-control: 10.50.0.0/16 allow
access-control: 192.168.70.0/24 allow
hide-identity: yes
hide-version: yes
qname-minimisation: yes
prefetch: yes
forward-zone:
name: "."
forward-addr: 8.8.8.8
forward-addr: 1.1.1.1
여기서 중요한 포인트가 두 가지 있었다.
첫 번째, interface에는 실제로 서버에 올라와 있는 IP만 넣어야 한다.
처음에 VPN 대역의 게이트웨이 주소인 192.168.70.1을 interface에 넣었더니 can't bind socket: Cannot assign requested address 에러가 나면서 기동이 실패했다. ocserv의 VPN 풀 주소와 서버 NIC 주소는 다를 수 있다. 192.168.70.1이 서버에 실제로 할당된 IP가 아니므로 bind 대상이 될 수 없다.
error: can't bind socket: Cannot assign requested address for 192.168.70.1 port 53
fatal error: could not open ports
두 번째, include: /etc/unbound/local.d/*.conf를 활용한다.
local.d 안의 파일에 interface를 넣지 말고, override 레코드만 넣는 용도로 쓰는 게 좋다. 메인 설정과 분리하면 관리가 훨씬 편하다.
리버스 프록시를 DNS 응답 대상으로 활용
여기서 좋은 아이디어가 하나 있었다. 외부 공개 도메인들의 내부 응답을 각 서비스의 실제 내부 IP(172.20.x.x)가 아니라, 리버스 프록시 주소인 10.50.1.1로 통일하는 것이다.
왜냐하면 이 서버에는 이미 nginx 리버스 프록시가 10.50.1.1에서 운영 중이고, 모든 외부 도메인의 호스트 기반 라우팅을 처리하고 있기 때문이다. 그러면 VPN 사용자는 각 서비스의 172.20.x.x를 알 필요 없이, 도메인으로 접근하면 nginx가 알아서 뒤로 라우팅해준다. 외부에서 접근할 때의 구조와 동일한 흐름을 내부에서도 유지할 수 있어서 운영이 깔끔해진다.
- 공용 DNS: service.example.com → 공인 IP
- VPN/내부용 unbound override: service.example.com → 10.50.1.1 (nginx)
nginx 도메인 추출 및 override 파일 작성
server:
# example.org
local-data: "example.org. IN A 10.50.1.1"
local-data: "www.example.org. IN A 10.50.1.1"
local-data: "vcs.example.org. IN A 10.50.1.1"
local-data: "wiki.example.org. IN A 10.50.1.1"
local-data: "secret.example.org. IN A 10.50.1.1"
local-data: "live.example.org. IN A 10.50.1.1"
local-data: "backup.example.org. IN A 10.50.1.1"
local-data: "automation.example.org. IN A 10.50.1.1"
local-data: "toast.example.org. IN A 10.50.1.1"
# example.kr
local-data: "example.kr. IN A 10.50.1.1"
local-data: "www.example.kr. IN A 10.50.1.1"
# service.com
local-data: "service.com. IN A 10.50.1.1"
local-data: "forum.service.com. IN A 10.50.1.1"
local-data: "shop.service.com. IN A 10.50.1.1"
local-data: "admin.service.com. IN A 10.50.1.1"
local-data: "chatbot.service.com. IN A 10.50.1.1"
# 그 외 도메인들...
메인 도메인별로 주석을 넣어 묶으면 나중에 관리하기 훨씬 낫다. 도메인이 수십 개 넘어가면 이 정도 정리는 필수다.
주의할 점 하나. VPN 접속용 도메인(예: vpn.example.org)은 override 대상에서 빼야 한다. 이 도메인을 내부 IP로 돌리면 VPN 연결 자체에 영향을 줄 수 있다.
기동 및 검증
unbound-checkconf
systemctl enable --now unbound
systemctl status unbound
질의 테스트:
dig @172.20.0.1 example.org # → 10.50.1.1
dig @172.20.0.1 git.service.com # → 10.50.1.1
dig @172.20.0.1 google.com # → 외부 정상 조회
firewalld 설정
VPN 클라이언트 대역 192.168.70.0/24에서 DNS 서버 172.20.0.1:53로의 접근을 열어야 한다. 처음에는 VPN 전용 zone을 새로 만들어서 DNS만 허용했다.
firewall-cmd --permanent --new-zone=vpn
firewall-cmd --permanent --zone=vpn --add-source=192.168.70.0/24
firewall-cmd --permanent --zone=vpn --add-service=dns
firewall-cmd --reload
# firewall-cmd --zone=vpn --list-all
vpn (active)
target: default
sources: 192.168.70.0/24
services: dns
forward: no
masquerade: no
이게 문제였다.
DNS는 잘 되는데 내부 IP 접근이 전부 막혀버렸다. 증상이 재밌었는데, RDP는 되고 SSH는 안 되는 식의 기현상이 나타났다.
원인은 firewalld의 source zone 매칭 구조에 있다. firewalld는 패킷의 source IP가 특정 zone의 source에 매칭되면, 인터페이스 기반 zone보다 그 source zone을 우선 적용한다. 192.168.70.0/24가 vpn zone에 매칭되니까, 기존에 public zone에서 허용되던 것들이 전부 무시되고 vpn zone의 정책만 적용된 것이다. vpn zone에는 dns 하나만 열려 있으니, DNS 빼고 전부 막힌 게 맞다.
RDP만 됐던 이유는 별도다. RDP 대상 서버는 게이트웨이 뒤 내부 서버인데, 이 트래픽은 FORWARD 체인을 타고 내부 서버가 직접 응답한다. 반면 게이트웨이 자체 SSH는 INPUT 체인이라 vpn zone 정책에 직접 걸린다. 이 차이 때문에 한쪽만 됐던 것이다.
해결은 간단했다. 별도 zone을 만들 게 아니라, VPN 클라이언트를 내부 사용자처럼 다루면 된다. 192.168.70.0/24를 internal zone에 넣었다.
firewall-cmd --permanent --zone=vpn --remove-source=192.168.70.0/24
firewall-cmd --permanent --delete-zone=vpn
firewall-cmd --permanent --zone=internal --add-source=192.168.70.0/24
firewall-cmd --permanent --zone=internal --add-service=dns
firewall-cmd --reload
# firewall-cmd --zone=internal --list-all
internal (active)
target: default
sources: 172.20.0.0/16 192.168.70.0/24
services: dhcpv6-client dns mdns samba-client ssh
ports: 463/tcp
forward: no
masquerade: yes
이 상태에서 DNS와 SSH는 복구됐는데, 이번엔 내부 서버 IP 직접 접근이 안 됐다. forward: no가 원인이었다. VPN 클라이언트가 게이트웨이를 통해 다른 내부 호스트로 가는 트래픽은 FORWARD 체인을 타는데, 이게 막혀있었다. DNS는 게이트웨이 자신에게 오는 INPUT이라 되지만, 내부 서버 접근은 FORWARD라서 막힌다.
firewall-cmd --permanent --zone=internal --add-forward
firewall-cmd --permanent --zone=reverseproxy --add-forward
firewall-cmd --reload
# firewall-cmd --zone=internal --list-all
internal (active)
target: default
sources: 172.20.0.0/16 192.168.70.0/24
services: dhcpv6-client dns mdns samba-client ssh
ports: 463/tcp
forward: yes
masquerade: yes
# firewall-cmd --zone=reverseproxy --list-all
reverseproxy (active)
target: default
sources: 10.50.0.0/16
forward: yes
masquerade: yes
ocserv 설정 변경
기존:
ipv4-network = 192.168.70.0/24
tunnel-all-dns = true
dns = 8.8.8.8
변경 후:
ipv4-network = 192.168.70.0/24
tunnel-all-dns = true
dns = 172.20.0.1
systemctl restart ocserv
여기서 한 가지 더 삽질이 있었다. ocserv 로그를 보면 DNS는 정상적으로 push되고 있었다.
worker[user]: x.x.x.x sending IPv4 192.168.70.214
worker[user]: x.x.x.x adding DNS 172.20.0.1
그래서 처음에는 route도 명시적으로 넣었다.
route = 172.20.0.0/16
route = 10.50.0.0/16
이게 오히려 망쳤다.
route를 넣으니 DNS는 되는데 내부 IP 접근이 전부 안 됐다. tcpdump로 확인해보니 VPN 클라이언트에서 172.20.0.1:463(SSH)으로 보내는 SYN 패킷이 게이트웨이에 아예 도달하지 않았다. 패킷이 서버까지 안 오고 있었다.
tcpdump -ni any src net 192.168.70.0/24 and dst host 172.20.0.1 and tcp port 463
# → 0 packets captured
ocserv의 route 지시자를 주면 AnyConnect/OpenConnect 클라이언트가 해당 대역에 대해 split route를 별도로 설치하려고 한다. 문제는 172.20.0.0/16이나 10.50.0.0/16 같은 주소가 RFC1918 표준 사설대역이 아니라 공인 IPv4 주소처럼 생긴 대역이라는 점이다. 클라이언트가 split route를 설치할 때 이런 "공인대역처럼 생긴" 목적지에 대해 라우팅을 이상하게 적용하거나 기존 경로와 충돌하면서, 실제로는 터널이 아니라 일반 인터넷 쪽으로 패킷이 빠져버린 것이다.
route를 빼니까 모든 게 정상이 됐다.
ipv4-network = 192.168.70.0/24
tunnel-all-dns = true
dns = 172.20.0.1
# route 없음
클라이언트가 자동으로 잡은 터널 경로보다, 서버가 강제로 내려준 split route가 더 나쁘게 동작한 케이스였다.
최종 구성 요약
ocserv.conf 핵심
ipv4-network = 192.168.70.0/24
tunnel-all-dns = true
dns = 172.20.0.1
unbound.conf 핵심
server:
interface: 127.0.0.1
interface: 172.20.0.1
access-control: 127.0.0.0/8 allow
access-control: 172.20.0.0/16 allow
access-control: 10.50.0.0/16 allow
access-control: 192.168.70.0/24 allow
include: /etc/unbound/local.d/*.conf
forward-zone:
name: "."
forward-addr: 8.8.8.8
forward-addr: 1.1.1.1
firewalld 핵심
internal zone:
sources: 172.20.0.0/16 192.168.70.0/24
services: dns ssh ...
forward: yes
masquerade: yes
내부 DNS가 동반된 VPN 요청 흐름
결과
적용 전후를 비교하면 이렇다.
| 테스트 항목 | 적용 전 (dns=8.8.8.8) | 적용 후 (dns=내부 unbound) |
|---|---|---|
| 내부 IP 직접 접근 (172.20.x.x) | O | O |
| NAT 인터넷 (youtube, google 등) | O | O |
| 외부 공개 도메인 접근 (example.org 등) | X | O |
| 내부 전용 도메인 접근 | X | O |
| VPN에서 SSH (내부 서버) | O (IP로만) | O (도메인으로도) |
| VPN에서 웹 서비스 (https) | X (도메인 불가) | O |
| DNS 응답 — 외부 도메인 | 공인 IP | 10.50.1.1 (nginx) |
| DNS 응답 — 일반 인터넷 | 정상 | 정상 (8.8.8.8 포워딩) |
VPN 연결 후 실제 확인한 내용:
$ nslookup example.org
Server: 172.20.0.1
Address: 172.20.0.1#53
Name: example.org
Address: 10.50.1.1
$ nslookup vcs.service.com
Server: 172.20.0.1
Address: 172.20.0.1#53
Name: vcs.service.com
Address: 10.50.1.1
$ nslookup google.com
Server: 172.20.0.1
Address: 172.20.0.1#53
Non-authoritative answer:
Name: google.com
Address: 142.250.207.46
$ curl -sk https://example.org | head -1
<!DOCTYPE html>
$ ssh user@172.20.5.1
Last login: ...
외부 공개 도메인은 unbound가 내부 nginx IP(10.50.1.1)로 응답하고, nginx가 호스트 기반으로 각 백엔드에 라우팅한다. 일반 인터넷 도메인은 8.8.8.8로 포워딩해서 평소처럼 사용 가능하다. VPN을 붙든 안 붙든, 도메인으로 접근하면 서비스가 된다. 차이는 경로뿐이다.
정리
처음 문제는 VPN 붙으면 도메인이 안 된다 였는데, 해결하고 보니 DNS 하나 바꾸면 될 일이었다. dns = 8.8.8.8을 내부 DNS로 바꾸고, 그 내부 DNS가 상황에 맞는 응답을 해주면 된다.
다만 그 과정에서 삽질이 꽤 있었다.
- unbound interface에 서버에 없는 IP를 넣어서 기동 실패
- firewalld에 VPN 전용 zone을 만들었더니 source zone 우선매칭에 걸려서 DNS 빼고 전부 차단
- forward: no 상태에서 내부 서버 접근이 안 되는 것을 놓침
- ocserv의 route push가 오히려 클라이언트 라우팅을 깨뜨림
결국 최종 구성은 단순하다. ocserv는 dns = 172.20.0.1과 tunnel-all-dns = true만 넣고 route는 뺀다. unbound는 내부 도메인과 외부 공개 도메인의 내부용 override를 넣고, 나머지는 8.8.8.8로 포워딩한다. firewalld는 VPN 대역을 internal zone에 넣어서 내부 사용자와 동일하게 다룬다.