OpenWrt 공유기 VPN 설정은 모든 기기의 트래픽을 한꺼번에 터널로 보내는 작업이 아닙니다. 스마트폰은 일반 인터넷을 사용하고, TV의 특정 서비스나 업무용 PC만 VPN을 통과하게 하려면 공유기에서 인터페이스, 방화벽, DNS, 정책 기반 라우팅을 함께 구성해야 합니다. 이 구조를 제대로 이해하면 기기마다 VPN 앱을 설치하지 않고도 집 안의 여러 장치를 역할에 맞게 분리할 수 있습니다.

다만 OpenWrt의 VPN 클라이언트 설정은 단순히 서버 주소를 입력하는 절차와 다릅니다. WireGuard를 사용할지, OpenVPN을 사용할지, 또는 별도 패키지를 통해 Shadowsocks·VMess·Trojan·Hysteria2 같은 프로토콜을 연결할지 먼저 결정해야 합니다. 공유기 모델의 플래시 저장 공간과 메모리, 펌웨어 버전, 제공받은 구성 형식도 함께 확인해야 합니다.

OpenWrt에서 트래픽 분배가 동작하는 구조

일반적인 OpenWrt 네트워크에서는 LAN에 연결된 기기가 공유기를 기본 게이트웨이로 사용합니다. 공유기는 목적지 주소를 확인한 뒤 WAN 인터페이스 또는 VPN 인터페이스 중 하나로 패킷을 전달합니다. 모든 트래픽을 VPN으로 보내는 방식은 비교적 단순하지만, 국내 서비스나 로컬 기기까지 터널을 통과하면 접속 문제가 생길 수 있습니다. 그래서 실제 가정용 환경에서는 정책 기반 라우팅을 사용해 대상 기기, 목적지 주소, 소스 네트워크를 기준으로 경로를 나누는 편이 유연합니다.

가장 이해하기 쉬운 분류는 세 가지입니다. 첫째는 특정 기기 전체를 VPN으로 보내는 방식입니다. 예를 들어 TV의 모든 외부 연결을 VPN 인터페이스로 보낼 수 있습니다. 둘째는 특정 목적지 도메인이나 IP 대역만 VPN으로 보내는 방식입니다. 이 경우 한 PC에서 업무 사이트는 일반 회선으로 사용하고 선택한 서비스만 터널로 보낼 수 있습니다. 셋째는 기본 경로를 VPN으로 두고, 로컬 네트워크와 일부 예외 목적지만 WAN으로 우회하는 방식입니다.

3

주요 분배 방식

2

핵심 경로 선택지

4

점검할 구성 층

1

기본 게이트웨이

공유기에서 확인할 구성 층은 네트워크 인터페이스, 방화벽, 라우팅 정책, DNS입니다. 네트워크 인터페이스가 연결되지 않으면 터널 자체가 만들어지지 않습니다. 방화벽이 허용하지 않으면 인터페이스가 연결되어도 LAN 패킷이 통과하지 못합니다. 정책이 없으면 패킷은 기본 WAN으로 나갈 수 있고, DNS가 다른 경로를 사용하면 도메인 기반 규칙이 예상과 다르게 작동할 수 있습니다.

구성 요소 역할 문제가 생겼을 때 보이는 현상
VPN 인터페이스 공유기와 원격 서버 사이의 터널 생성 핸드셰이크 실패, 인터페이스 미연결
방화벽 영역 LAN에서 VPN으로 패킷을 전달하고 응답을 허용 연결 상태는 정상인데 웹 접속 불가
정책 기반 라우팅 기기와 목적지에 따라 WAN 또는 VPN 선택 원하는 기기가 다른 출구를 사용함
DNS 설정 도메인 이름을 주소로 해석하고 정책 판단을 보조 도메인 규칙이 누락되거나 예상과 다른 서버로 연결

프로토콜과 구성 파일 준비하기

OpenWrt 공유기에서 처음 구성한다면 WireGuard가 비교적 명확한 출발점입니다. 제공받은 구성에는 일반적으로 개인 키와 주소, 원격 피어의 공개 키, 서버 주소와 포트, 허용 IP가 들어 있습니다. OpenWrt의 네트워크 메뉴에서 WireGuard 인터페이스를 만들고 이 값을 각 필드에 옮길 수 있습니다. 개인 키는 외부에 공개하지 말아야 하며, 설정 화면이나 문의 스크린샷에 그대로 포함하지 않는 것이 좋습니다.

OpenVPN은 인증서와 키, 서버 주소, 암호화 방식이 함께 들어간 구성 파일을 사용하는 경우가 많습니다. 파일 전체를 그대로 가져올 수 있는 환경도 있지만, OpenWrt 버전과 설치된 패키지에 따라 추가 패키지가 필요할 수 있습니다. 설정 파일에 사용자 이름과 비밀번호가 별도 파일로 지정되어 있다면 경로와 권한도 확인해야 합니다.

Shadowsocks, VMess, Trojan, Hysteria2는 WireGuard나 OpenVPN과 같은 방식으로 LuCI 기본 화면에 항상 표시되는 것은 아닙니다. 해당 프로토콜을 지원하는 클라이언트 패키지와 서비스 관리 방식이 필요하며, 구독 링크를 공유기에 바로 붙여넣는다고 자동으로 작동하지 않습니다. 구독 링크는 호환 클라이언트에 서버 구성을 전달하는 수단이고, 라우터에서 트래픽을 분배하려면 그 클라이언트가 실제로 실행되며 투명 프록시 또는 정책 라우팅을 제공해야 합니다.

이 절의 결론: 공유기에서 사용할 프로토콜은 구성 파일의 형식과 OpenWrt 패키지 지원 여부를 기준으로 선택해야 합니다. 구독 링크가 있다고 해서 라우터가 자동으로 VPN 클라이언트가 되는 것은 아닙니다.

OpenWrt에서 VPN과 분배 규칙 설정하기

이제 실제 설정 순서를 진행해 보겠습니다. 메뉴 이름은 OpenWrt 버전과 설치된 패키지에 따라 조금 다를 수 있지만, 작업 순서는 크게 달라지지 않습니다. 먼저 LuCI에 접속해 Network 영역에서 VPN 인터페이스를 추가합니다. WireGuard라면 인터페이스 이름을 구분하기 쉬운 이름으로 지정하고 개인 키, 터널 주소, 피어 공개 키, 엔드포인트 주소와 포트를 입력합니다. 허용 IP는 제공된 구성의 의미를 확인한 뒤 입력해야 하며, 임의로 넓히면 모든 경로가 터널로 향할 수 있습니다.

인터페이스를 저장한 뒤에는 방화벽에서 별도 영역을 만들거나 기존 VPN 영역에 연결합니다. LAN에서 VPN으로 나가는 전달을 허용하고, VPN에서 돌아오는 응답이 차단되지 않도록 구성해야 합니다. NAT가 필요한 구조라면 VPN 영역의 마스커레이딩 설정도 확인합니다. 이 단계에서 무조건 방화벽을 완전히 개방하는 것은 좋지 않습니다. 필요한 방향과 인터페이스만 허용하고, 관리 화면은 LAN에서만 접근할 수 있도록 유지하는 편이 안전합니다.

다음은 분배 규칙입니다. 가장 쉬운 테스트는 특정 기기의 IP 주소를 고정하고 그 주소에서 시작하는 트래픽만 VPN으로 보내는 것입니다. DHCP 고정 임대 기능을 사용하면 TV나 테스트용 PC가 재부팅된 뒤에도 같은 주소를 받을 수 있습니다. 이후 정책 기반 라우팅 패키지를 사용해 소스 주소를 VPN 인터페이스와 연결합니다. 목적지 기반 규칙을 만들 때는 서비스가 사용하는 도메인과 IP가 바뀔 수 있다는 점을 고려해야 합니다.

  1. 구성 백업: 현재 네트워크와 방화벽 설정을 저장하고 복구 방법을 확인합니다.
  2. 인터페이스 추가: WireGuard 또는 OpenVPN 정보를 입력하고 저장합니다.
  3. 기본 연결 확인: VPN 인터페이스를 일시적으로 테스트한 뒤 핸드셰이크와 로그를 확인합니다.
  4. 방화벽 연결: LAN에서 VPN으로 전달되는 규칙과 필요한 NAT 동작을 설정합니다.
  5. 기기 지정: DHCP 고정 임대로 테스트 장치의 주소를 고정합니다.
  6. 정책 적용: 해당 기기 또는 목적지에 VPN 경로를 지정하고 다른 장치는 WAN에 남깁니다.
  7. DNS 확인: 기기에서 새 DNS 설정을 받도록 연결을 갱신하고 도메인 규칙을 다시 확인합니다.

테스트할 때는 브라우저 한 번만 열어 보는 것보다 단계별로 확인하는 편이 좋습니다. 먼저 공유기에서 VPN 인터페이스가 연결되었는지 봅니다. 다음으로 테스트 기기의 기본 게이트웨이가 OpenWrt인지 확인하고, 로컬 공유 폴더나 프린터처럼 집 안에서만 사용하는 주소가 계속 접근되는지 확인합니다. 그 후 일반 웹사이트와 선택한 목적지를 각각 확인해 어떤 트래픽이 WAN을 사용하고 어떤 트래픽이 VPN을 사용하는지 비교합니다.

# 상태 확인 예시
ip address
ip route
logread | grep -i -E 'wireguard|openvpn|firewall'
ping -c 3 공유기주소

위 명령은 환경에 따라 출력 형식이 다를 수 있습니다. 중요한 것은 명령 결과의 숫자를 무조건 정상으로 판단하는 것이 아니라, VPN 인터페이스가 실제로 존재하는지, 경로가 예상한 장치와 목적지에 연결되는지, 로그에 인증이나 방화벽 오류가 없는지를 보는 것입니다. 설정을 바꾼 뒤에는 클라이언트의 Wi-Fi 연결을 끊었다가 다시 연결해 오래된 DHCP와 DNS 정보를 제거하는 것도 도움이 됩니다.

분할 라우팅과 DNS에서 자주 생기는 문제

분할 라우팅에서 가장 흔한 문제는 정책보다 먼저 DNS가 목적지를 결정한다는 점을 놓치는 것입니다. 도메인 기반 정책을 사용하는데 기기가 공유기의 DNS를 사용하지 않거나, 외부 DNS로 직접 질의하도록 설정되어 있으면 도메인 목록이 기대대로 적용되지 않을 수 있습니다. 반대로 모든 DNS를 VPN으로 보내도록 설정하면 로컬 호스트 이름이나 공유기 내부 서비스가 제대로 해석되지 않을 수도 있습니다. 집 안 장치와 외부 목적지를 구분해 DNS 정책을 설계해야 합니다.

또 다른 문제는 IPv6입니다. IPv4만 VPN으로 보내도록 설정했는데 기기가 IPv6 연결을 우선하면 웹사이트가 WAN의 IPv6 경로를 사용할 수 있습니다. 이것은 반드시 오류라고 단정할 수는 없지만, “특정 기기의 모든 외부 트래픽을 VPN으로 보낸다”는 목표와는 맞지 않을 수 있습니다. IPv6 터널을 별도로 구성할지, 테스트 기간에 해당 LAN의 IPv6 광고를 조정할지 결정한 뒤 확인해야 합니다. 중요한 것은 IPv4만 확인하고 전체 경로가 끝났다고 판단하지 않는 것입니다.

MTU와 MSS도 점검 대상입니다. VPN 캡슐화로 패킷 크기가 커지면 일부 사이트나 장시간 연결에서만 멈춤이 나타날 수 있습니다. 모든 웹사이트가 열리는데 특정 파일 다운로드나 스트리밍 연결만 중단된다면 MTU, MSS 조정, 경로상의 조각화 차단을 순서대로 확인합니다. 값을 무작정 낮추기보다 현재 인터페이스와 제공된 구성의 권장값을 우선 확인하는 편이 좋습니다.

장애 복구와 장기 운영 점검

VPN을 켠 뒤 집 안의 모든 기기가 인터넷에 접속하지 못한다면 먼저 분배 정책을 임시로 해제하고 WAN 기본 경로를 복원합니다. 그 상태에서 LAN 인터넷이 정상이라면 문제는 VPN 인터페이스, 방화벽 전달, NAT 또는 정책 중 하나에 있을 가능성이 높습니다. 반대로 VPN을 꺼도 인터넷이 되지 않는다면 DNS나 기존 WAN 설정을 먼저 확인해야 합니다.

설정을 되돌릴 때는 변경한 항목을 한 번에 모두 지우기보다 역순으로 해제하는 것이 좋습니다. 정책 라우팅을 해제하고, 방화벽 전달을 원래대로 복원한 뒤, 마지막에 VPN 인터페이스를 중지합니다. 공유기 관리 화면에 접근할 수 없는 상황을 대비해 로컬 관리 주소와 유선 연결 방법을 미리 확인하세요. 중요한 설정은 백업 파일로 저장하되, 개인 키가 포함될 수 있으므로 일반 문서와 같은 위치에 보관하지 않는 것이 안전합니다.

장기 운영에서는 연결 상태만 확인해서는 부족합니다. 서버 인증서나 키가 변경되었는지, 구독 구성이 갱신되었는지, OpenWrt 패키지 업데이트 후 방화벽 이름이나 서비스 동작이 달라졌는지 살펴봐야 합니다. TV처럼 설정 변경이 어려운 기기는 별도 테스트 장치로 먼저 확인한 뒤 정책을 적용하는 편이 안전합니다. 또한 가족이 사용하는 스마트폰까지 강제로 같은 경로에 넣기보다, 필요한 기기만 명확하게 지정하면 장애 범위를 줄일 수 있습니다.

한 문장 결론: OpenWrt 공유기 VPN은 인터페이스를 연결하는 데서 끝나지 않습니다. 기기 주소를 고정하고, 방화벽과 정책 라우팅을 분리해 설정한 뒤, DNS·IPv6·복구 경로까지 확인해야 집 전체 네트워크를 안정적으로 분배할 수 있습니다.

자주 묻는 질문

구독 링크를 OpenWrt에 바로 붙여넣으면 되나요?

항상 가능한 것은 아닙니다. 구독 링크는 호환 클라이언트에 서버 구성을 전달하는 방식이며, OpenWrt가 해당 형식과 프로토콜을 직접 해석한다는 뜻은 아닙니다. WireGuard나 OpenVPN은 보통 전용 구성 파일 또는 필드별 정보를 사용합니다. Shadowsocks, VMess, Trojan, Hysteria2를 사용하려면 이를 지원하는 라우터 패키지와 투명 프록시 또는 정책 라우팅 기능이 별도로 필요합니다.

집 안의 모든 기기를 VPN으로 보내야 하나요?

그럴 필요는 없습니다. 특정 TV, 테스트용 PC, 업무 장치처럼 목적이 분명한 기기만 VPN 정책에 넣고 나머지는 일반 WAN을 사용하게 할 수 있습니다. 기기별 정책은 구조가 이해하기 쉽고 장애가 생겼을 때 영향을 받는 범위도 작습니다. 모든 기기를 보내야 한다면 로컬 네트워크, DNS, IPv6 예외가 정상인지 먼저 확인하세요.

VPN을 켠 뒤 일부 사이트만 느려지는 이유는 무엇인가요?

해당 사이트가 VPN 경로를 사용하면서 경로 길이, MTU, DNS 응답, 서버 측 제한의 영향을 받을 수 있습니다. 사이트 하나만의 문제인지 같은 목적지의 여러 기기에서도 재현되는지 구분하고, 정책을 잠시 WAN으로 바꿔 비교하세요. 특정 연결만 중단된다면 MTU와 MSS, DNS, IPv6 순서로 점검하는 것이 좋습니다.

설정을 잘못해 인터넷이 끊기면 어떻게 되돌리나요?

먼저 정책 기반 라우팅을 해제해 WAN 기본 경로를 복원하고, 이후 방화벽의 VPN 전달 규칙과 인터페이스를 역순으로 중지합니다. LuCI에 접속할 수 없다면 미리 저장한 설정 백업과 유선 LAN 접근 방법을 사용해야 합니다. 백업 파일에는 개인 키가 포함될 수 있으므로 안전한 장소에 보관하고 공개 저장소나 공유 문서에는 올리지 마세요.