WireGuard와 DNS over HTTPS(DoH) 통합 설정

소개

WireGuard로 안전한 터널을 구성한 뒤에도 DNS 평문 조회는 남은 취약점이 될 수 있다. DNS over HTTPS(DoH)는 DNS 요청을 HTTPS로 암호화해 도청과 변조 위험을 줄여준다. 이 글은 WireGuard와 DoH를 함께 운용하는 개념, 아키텍처 선택지, 실제 구성 예제를 차근차근 설명한다.

개념 정리

WireGuard와 DNS의 역할

WireGuard는 IP 레벨의 암호화 터널을 제공한다. 하지만 클라이언트가 어떤 DNS 서버를 쓰냐에 따라 DNS가 평문으로 노출될 수 있다. 따라서 터널 내에서 DNS를 암호화하는 방법이 필요하다.

DNS over HTTPS(DoH)란

DoH는 DNS 질의를 HTTPS 요청으로 캡슐화해 전송한다. 일반 DNS(UDP 53)보다 감청과 차단에 강하며, 기존 HTTPS 인프라를 통해 전송되므로 네트워크 차단을 우회하는 데에도 유리하다.

아키텍처 선택

WireGuard와 DoH를 통합할 때 보통 세 가지 패턴이 나온다.

• 클라이언트 직접 DoH: 각 클라이언트에서 DoH 클라이언트를 실행
• 게이트웨이 DoH: WireGuard 서버(또는 내부 게이트웨이)에서 DoH 리졸버 실행
• 혼합형: 내부 DNS 캐시(예: dnsmasq) + Upstream DoH

운영 편의성과 중앙 관리 관점에서는 게이트웨이 DoH가 유리하다. 클라이언트는 단일 DNS(예: WireGuard 서버의 내부 IP)를 쓰면 되고, 서버에서 DoH로 전달해 암호화가 보장된다.

준비사항

• WireGuard 서버와 클라이언트 구성은 사전 준비
• DoH 리졸버: cloudflared, dnscrypt-proxy, doh-client 등
• 서버 방화벽 및 포트 포워딩 정책 검토
• systemd 또는 서비스 관리 도구 사용 권장

실제 구성 예제: WireGuard 게이트웨이에서 cloudflared로 DoH 처리

목표는 WireGuard 클라이언트가 WireGuard 서버의 내부 DNS(예: 10.0.0.1)를 사용하면, 서버가 DoH로 외부 DNS를 조회하도록 만드는 것이다.

1) WireGuard 서버 설정(wg0.conf)

[Interface]
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = SERVER_PRIVATE_KEY
PostUp = sysctl -w net.ipv4.ip_forward=1
PostUp = iptables -t nat -A PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 5053
PostDown = iptables -t nat -D PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 5053

# Peer 예시
[Peer]
PublicKey = CLIENT_PUBLIC_KEY
AllowedIPs = 10.0.0.2/32

위 예시는 서버에서 UDP 53 트래픽을 로컬 포트 5053으로 리다이렉트하는 iptables 규칙을 포함한다. cloudflared가 5053에서 DNS-over-HTTPS를 처리하도록 구성할 예정이다.

2) cloudflared 설치 및 설정

cloudflared는 DoH 클라이언트로 자주 사용된다. 리눅스 바이너리를 설치한 뒤, DNS 프록시 모드로 실행하면 로컬 UDP 포트를 통해 DNS 질의를 받아 DoH로 전송한다.

# 예시 systemd 서비스 파일: /etc/systemd/system/cloudflared-dns.service
[Unit]
Description=cloudflared DoH DNS proxy
After=network.target

[Service]
ExecStart=/usr/local/bin/cloudflared proxy-dns --address 127.0.0.1 --port 5053 --upstream https://1.1.1.1/dns-query
Restart=on-failure

[Install]
WantedBy=multi-user.target

위에서는 Cloudflare DoH 엔드포인트를 upstream으로 사용한다. 다른 DoH 제공자를 지정할 수도 있다.

3) WireGuard 클라이언트 설정

[Interface]
Address = 10.0.0.2/32
PrivateKey = CLIENT_PRIVATE_KEY
DNS = 10.0.0.1

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = server.example.com:51820
AllowedIPs = 0.0.0.0/0, ::/0

클라이언트는 DNS 항목에 WireGuard 서버 내부 IP를 지정한다. 이렇게 하면 모든 DNS 질의가 터널을 통해 서버로 전달된다.

4) 방화벽·네트워킹 주의사항

• 서버에서 IP 포워딩 활성화 필요: sysctl net.ipv4.ip_forward=1
• cloudflared가 바인딩하는 주소와 포트(예: 127.0.0.1:5053)가 PostUp의 리다이렉트와 연동되는지 확인
• UDP 53 외에 TCP 53이 필요한 경우 TCP 리다이렉트도 고려
• 내부 DNS 캐시를 추가하면 응답 속도와 안정성이 개선

검증 방법

구성이 완료되면 클라이언트에서 다음 항목을 확인한다.

• nslookup/dig로 DNS가 10.0.0.1을 통해 해석되는지 확인
• 서버에서 cloudflared 로그로 DoH 요청이 정상 송수신되는지 확인
• tcpdump로 터널 밖에 평문 DNS 트래픽이 없는지 검토

문제 해결 요약

1) DNS 누수 검사

인터넷 상의 DNS 누수 테스트 도구로 확인한다. 클라이언트가 로컬 ISP DNS를 직접 사용하면 설정 오류가 있는 것이다.

2) 성능과 지연

DoH는 HTTPS 오버헤드가 있어 기존 UDP DNS보다 지연이 길 수 있다. 내부 캐시나 로컬 캐시링 DNS를 도입하면 체감 성능 개선이 가능하다.

3) 장애 대비

DoH 제공자 장애에 대비해 여러 Upstream을 지정하거나 폴백 정책을 마련하는 것이 권장된다.

결론

WireGuard와 DoH의 결합은 터널링과 DNS 암호화를 함께 제공해 보안성과 프라이버시를 크게 향상시킨다. 게이트웨이 중심의 DoH 적용이 중앙관리와 호환성 측면에서 유리하다. 운영 환경에 따라 클라이언트별 DoH 적용이나 내부 캐시를 병행하면 더 안정적인 서비스 운영이 가능하다. 핵심은 DNS 경로가 터널 내로 확실히 들어오도록 설정하고, DoH 프로세스가 올바르게 동작하는지 로그와 패킷 캡처로 검증하는 것이다.