라우터 VPN으로 기기 하나만 통과시키려면 토글이 아니라 세 가지 규칙이 필요하다

라우터 VPN에는 기기별 스위치가 없고, 찾고 있는 토글은 대신 정책 라우팅 규칙을 써 주는 지름길일 뿐입니다. 노트북 한 대, 포트 범위 하나, 주소 목록 하나, 또는 LAN 세그먼트 하나만 터널을 써야 하고 나머지는 모두 WAN에 남아야 하는 순간, 여러분은 기능을 켜는 것이 아니라 정책 경로를 만드는 것입니다. 작업에는 움직이는 세 부분이 있고 각각 다르게 실패합니다 — 경로가 없는 표시된 테이블은 침묵처럼 보이고, 잘못된 체인에 적용한 마크는 아무 일도 없었던 것처럼 보이며, 빠진 NAT 규칙은 연결은 되지만 아무것도 나르지 않는 터널처럼 보입니다. 두 부분이 더 빠지는데, mangle 규칙에 결코 나타나지 않기 때문이며 그것이 DNS와 IPv6입니다.

신화: 터널은 클라이언트 설정이다

라우터 쪽 VPN 클라이언트는 0.0.0.0/0을 메인 라우팅 테이블에 넣고 터널로 향하게 하는 한 가지 무딘 일을 잘합니다. WireGuard는 그것을 AllowedIPs에서 끌어오고, OpenVPN 은 서버가 밀어 주는 redirect-gateway에서 끌어옵니다. 둘 다 라우터 뒤의 모든 호스트 경로를 바꿉니다. AllowedIPs를 좁히거나 route-nopull을 추가하면 클라이언트가 설치하는 내용이 바뀌지만, 그 설치가 누구에게 적용되는지는 바뀌지 않습니다. 클라이언트는 기기를 보지 못하고 패킷만 보기 때문입니다.

출발지나 목적지로 선택하는 것은 라우팅 결정이므로 RouterOS에서는 mangle 규칙과 두 번째 테이블, OpenWrt나 DD-WRT에서는 MARK와 ip rule, pfSense에서는 게이트웨이가 터널인 방화벽 규칙으로 라우터의 정책 계층에 속합니다. Netgate의 WireGuard 클라이언트 레시피 는 그 플랫폼에서 규칙의 게이트웨이, 인터페이스 할당, 아웃바운드 NAT 항목이 모두 일치해야 클라이언트 하나가 터널을 쓸 수 있으므로 추측하기 전에 읽어야 할 문서입니다.

신화의 나머지 절반은 두 번째 라우터다. 박스를 하나 더 사거나 기기를 게스트 SSID로 옮기는 것이 흔히 효과가 있는데, 이유는 하드웨어가 아니라 기기를 자체 서브넷에 두어 펌웨어가 이미 이해하는 출발지 선택자를 얻기 때문입니다. 소유한 라우터에서 그 세그먼트를 정의할 수 있다면, 추가 박스는 없던 문제를 푸는 셈입니다.

첫 번째 조각: 기본 경로가 아닌 터널

RouterOS에서는 기본 경로 없이 클라이언트를 추가하고 터널에 자체 테이블을 줍니다. 첫 번째 경로가 표시된 기본 경로이고, 두 번째가 실패 절반입니다.

/ip route add dst-address=0.0.0.0/0 gateway=VPN_GATEWAY_IP routing-mark=vpn distance=1
/ip route add dst-address=0.0.0.0/0 type=unreachable routing-mark=vpn distance=2

도달 불가 경로가 바로 표시된 테이블이 메인 테이블의 예외 목록보다 나은 이유입니다. 터널이 끊기면 표시된 패킷은 조용히 WAN으로 되돌아가지 않고 즉시 도달 불가를 받으므로, 장애가 한 시간 뒤에 확인하는 지리 위치 페이지가 아니라 애플리케이션 오류 메시지에 나타납니다.

RouterOS 7은 6.x가 함께 묶어 두던 것을 나눕니다: 테이블을 /routing table add name=vpn fib로 선언한 뒤 경로와 mangle 규칙에서 이름으로 참조합니다. 테이블을 정의하지 않고 routing-mark를 직접 쓰는 6.x 스니펫은 깨끗하게 로드되고 아무것도 일치하지 않습니다. 또 다른 고전은 0.0.0.0/1의 두 절반이거나 한 테이블에 같은 거리의 기본 경로 두 개이며, 커널이 하나를 고르고 재부팅 후 동작이 바뀔 수 있습니다.

두 번째 조각: 경로 조회 전에 마크하기

선택자가 어떤 패킷이 그 테이블로 들어갈지 정합니다. RouterOS는 보통 목적지 정책이면 주소 목록, 기기 정책이면 출발지 주소에서 시작합니다:

/ip firewall mangle add chain=prerouting src-address=192.168.88.50 action=mark-routing new-routing-mark=vpn
/ip firewall mangle add chain=prerouting dst-address-list=via-vpn action=mark-routing new-routing-mark=vpn
/ip firewall address-list add list=via-vpn address=203.0.113.10

리눅스 펌웨어도 netfilter 마크와 표시된 패킷을 채워 둔 테이블로 보내는 규칙으로 같은 일을 합니다:

iptables -t mangle -A PREROUTING -p tcp --dport 27000:27050 -j MARK --set-mark 0x200
ip route add default dev tun0 table 100
ip rule add fwmark 0x200 table 100

체인은 스타일 선택이 아닙니다. 패킷이 FORWARD에 도달할 때쯤 경로 조회는 이미 끝났으므로 거기서 MARK나 DROP은 다시 쓰거나 버릴 수만 있습니다. 마크는 전달 트래픽이면 PREROUTING에, 라우터가 만들어 내는 트래픽이면 OUTPUT에 들어가야 하며, 라우터의 DNS와 NTP, 업데이트 확인이 바로 그곳에 있습니다. 그 출력 경로가 완전히 터널링한 구성이 누출 테스트에서 여전히 ISP 리졸버로 답하는 흔한 이유입니다.

기기 정책에는 흔들리지 않는 일치가 필요하므로 DHCP에서 주소를 예약하거나 전용 세그먼트용 인터페이스를 일치시키세요. 나중에 다른 기기로 옮겨 가는 주소는 표시 없이 잘못된 클라이언트에 터널을 적용합니다. 자체 서브넷을 가진 SSID별 브리지는 같은 발상의 더 오래 가는 버전이며, IPv6 규칙에도 살 자리를 줍니다.

세 번째 조각: NAT, DNS 그리고 LAN 예외

터널로 나가는 트래픽에는 반대편이 응답할 출발지 주소가 필요하므로 변환 범위를 터널 인터페이스로 좁히세요. RouterOS에서는 out-interface=VPN_NAME, 리눅스에서는 -o tun0, pfSense에서는 일치하는 아웃바운드 NAT 항목입니다. 그 범위 지정이 없는 masquerade 규칙은 그대로 두려던 트래픽까지 다시 쓰고, 증상은 터널을 타지 않는 기기가 공인 주소를 잃는 것입니다.

LAN 예외는 터널 자체보다 더 많은 지원 스레드를 만듭니다. 표시된 테이블에 기본 경로만 있으면 선택된 기기에서 프린터나 NAS 목적지가 그 기본 경로와 일치해 터널로 사라집니다. 같은 테이블에 LAN 경로를 추가하거나 선택자에서 로컬 서브넷을 제외하면 되고, 둘 다 동작하지만 나중에 VLAN을 추가할 때는 제외 쪽이 정확하게 유지하기 쉽습니다.

DNS는 별도 경로를 탑니다. 라우터가 전달하는 질의는 라우터에서 시작되어 OUTPUT을 따르고 전달 마크를 따르지 않으므로, 완전히 터널링한 노트북도 여전히 ISP를 통해 이름을 해석합니다. 클라이언트를 터널로 닿는 리졸버로 향하게 하거나 라우터 자체의 port-53 트래픽을 마크한 뒤, 답변이 웹 요청과 함께 이동했다고 가정하지 말고 해석된 주소를 확인하세요.

규칙은 일치하는데 앱이 여전히 WAN을 쓸 때

목적지 목록은 빨리 낡습니다. 이름이 목록에 없는 주소로 해석되면 요청은 WAN으로 가는데, 목록에 있는 주소로 한 모든 테스트는 성공했던 것입니다. 클라이언트가 쓰는 것과 같은 리졸버에서 목록을 새로 고치고, 기기 하나의 모든 트래픽을 정말로 원한다면 출발지 기반 선택자를 선호하세요.

IPv6는 조용한 우회로입니다. 기기에는 자체 기본 경로와 자체 규칙 집합을 가진 두 번째 주소 체계가 있고, IPv4 주소만 일치시키는 것은 정책의 절반입니다. 같은 선택자를 ip6tables나 nftables 등가물에 적용하거나, 그 세그먼트의 IPv6를 사고가 아니라 의도적으로 끄세요.

이미 맺어진 연결도 중요합니다. 변경 전에 만들어진 conntrack 항목은 만료될 때까지 옛 경로를 계속 따르므로, 편집 중에 열어 둔 브라우저는 전혀 적용되지 않은 규칙과 똑같이 보입니다. 정책을 판단하기 전에 새 연결을 열거나 상태를 비우세요.

두 기기와 재부팅으로 검증한다

터널을 타야 하는 기기와 타지 않아야 하는 기기를 시험하고, 속도 숫자 대신 두 번째 홉을 비교하세요. 각각의 traceroute는 두 번째 홉에서 터널 게이트웨이나 ISP 게이트웨이를 보여 주므로, 둘이 똑같아 보이면 마크나 테이블이 규칙이 말하는 대로 동작하지 않는 것입니다. 시험에는 새 연결을 쓰세요.

그다음 재부팅하세요. 시동 순서는 동작하던 정책이 깨지는 지점으로, 도달 불가 경로가 설치되기 전에 클라이언트가 올라와 있어야 하고 옛 규칙 집합을 복원하는 저장된 스냅숏은 여러분의 테이블을 덮어씁니다. 모든 규칙이 저장된 구성에 있는지, 표시된 기본 경로가 부팅 후에도 존재하는지 입력한 직후만이 아니라 확인하세요.

무언가 실패하면 먼저 마크를 제거해 정상 트래픽이 돌아오는지 보고, 그다음 테이블을 제거하세요. 그 순서가 라우팅 문제를 쫓는지 방화벽 문제를 쫓는지 알려 주고, 작업을 마칠 동안 집에는 작동하는 프린터가 남습니다.