Mesh Wi-Fi 위성 노드가 VPN 공유기를 쓰는지 확인하는 방법
기본 게이트웨이, 노드의 전달 모드, 공유기의 상태 테이블을 따라가며 Mesh 위성 아래 클라이언트가 VPN을 타는지 증명합니다.
기본 공유기와 같은 Wi-Fi 이름에 응답하는 위성은 그 아래 클라이언트의 패킷이 어디로 가는지 거의 알려 주지 않습니다. 노드는 반증이 없는 한 라디오이자 브리지입니다. 출구를 정하는 것은 각 클라이언트가 받는 기본 게이트웨이와 그 앞 노드의 전달 모드입니다. 다음 다섯 가지 점검을 클라이언트에서 바깥으로 진행하면, 속도 테스트의 인상이 아니라 설명할 수 있는 답을 얻게 됩니다.
클라이언트가 실제로 받은 게이트웨이를 읽습니다
클라이언트에서 라우팅 테이블과 이웃 테이블을 출력합니다. 기본 경로는 트래픽을 전달하는 주소를 가리키고, 이웃 항목은 그 주소를 가진 MAC을 가리킵니다. 공유기의 기기 목록이 아니라 클라이언트에서 확인하는 이유는 기기 목록은 연결 관계를 보여 줄 뿐 경로는 보여 주지 않기 때문입니다.
ip route show default
ip -6 route show default
ip neigh showWindows는 같은 사실을 다른 형식으로 출력합니다:ipconfig /all 는 기본 게이트웨이를, arp -a 는 MAC을 보여 줍니다. macOS에서는 route -n get default 와 arp -an 가 같은 역할을 합니다.
그 게이트웨이를 이미 알고 있는 두 주소, 곧 기본 공유기의 LAN 주소와 위성의 관리 주소와 비교합니다. 게이트웨이가 공유기의 LAN 주소라면 클라이언트는 공유기에 브리지되어 있고 그 세그먼트에 대한 공유기의 정책이 그대로 적용됩니다. 게이트웨이가 위성의 주소라면 위성이 라우팅하는 것이며 공유기는 클라이언트 패킷을 LAN 트래픽으로 보지 못하므로, 판단은 노드에서 이루어져야 하고 그곳에서 이루어지지 않으면 아예 이루어지지 않습니다.
노드가 실제로 어느 모드인지 확인합니다
Mesh 제품은 같은 세 단어를 서로 다른 동작에 재사용하므로 앱의 표시보다 패킷의 경로를 믿어야 합니다. 브리지 또는 액세스 포인트 모드는 프레임을 전달합니다. 라우터 모드는 서브넷을 끝내고 DHCP를 돌립니다. 게스트 모드는 보통 클라이언트를 자체 규칙이 있는 별도 VLAN에 둡니다. 다른 공유기 뒤에 있는 라우터 모드 노드는 이중 NAT가 되고, 그 클라이언트는 이미 변환된 상태로 VPN 공유기에 도착하므로 출발지 주소에 기반한 정책이 무력해집니다.
| What you see | What it means | Next check |
|---|---|---|
| Gateway is the router's LAN address, one MAC for every node | The node bridges; the router owns the policy | Router policy for that LAN and VLAN |
| Gateway is the node's address and DHCP comes from the node | The node routes; double NAT | Node's own VPN client, or a static route plus policy on the router |
| Gateway is a different subnet on a guest SSID | Guest VLAN, often client-isolated | Whether that VLAN is inside the tunnel policy |
| Gateway changes when you walk into another room | Roaming across segments | Repeat the check per node |
MAC을 확인하려면 노드의 라벨을 읽고 ip neigh 의 결과와 대조합니다. 제조사는 기본 MAC만 인쇄하고 각 무선의 MAC은 바이트를 하나 올려 만들기 때문에 마지막 자리가 달라지므로, 주소 전체가 아니라 앞부분을 비교하십시오. 게이트웨이의 MAC이 공유기의 LAN 인터페이스 것이라면 그 클라이언트에 대해 노드는 라우팅하지 않는 것입니다.
출구는 공유기에서 증명하며, 속도 테스트로는 증명하지 않습니다
변환을 보여 주는 곳은 공유기 쪽 상태뿐이므로, OpenWrt에서는 정책 규칙과 라우팅 테이블을 나열하고, 터널에 최근 핸드셰이크가 있는지 확인합니다.
ip rule show
ip route show table all | grep default
wg showpfSense나 OPNsense에서는 같은 증거가 pfctl -sr 에 규칙으로, pfctl -ss 에 활성 상태로, WireGuard 상태 페이지에 피어 카운터로 있으며, 참고 자료는 WireGuard 클라이언트 문서 입니다. 상태 테이블을 클라이언트 주소로 걸러 보십시오. 상태가 클라이언트를 터널 주소로 변환해 보여 주면 트래픽은 터널 안에 있고, WAN 주소를 보여 주면 터널 밖이며, 대시보드 표시는 상관없습니다.
클라이언트에서 traceroute를 하면 상태 테이블이 주지 못하는 사실, 즉 첫 홉이 드러납니다. 첫 홉이 공유기의 LAN 주소라면 클라이언트는 공유기에 곧바로 닿은 것입니다. 노드 주소이고 그다음에 사설 홉이 하나 더 이어진다면 라우팅된 세그먼트이며, 두 번째 홉이 정책을 쥐어야 할 장비입니다.
노드가 주소 말고 무엇을 나눠 주는지 확인합니다
DHCP 옵션은 임대와 함께 배포되므로 자체 DHCP를 제공하는 노드는 자기 DNS와 자기 IPv6 라우터 알림도 함께 줄 수 있습니다. 그래서 클라이언트는 터널로 나가면서도 노드의 리졸버로 질의를 보내거나, 터널 정책이 결코 덮지 않는 전역 IPv6 주소를 받을 수 있으므로, 둘 다 클라이언트에서 출력하십시오.
cat /etc/resolv.conf
ip -6 addr show scope global리졸버가 노드이고 노드가 공유기로 전달한다면 DNS는 터널을 따릅니다. 노드가 로컬에서 해석하거나 통신사 리졸버를 가리킨다면 HTTP가 터널을 타더라도 질의는 터널 밖으로 나갑니다. IPv6도 같은 시험이 필요하며, 전역 주소와 터널을 우회하는 기본 경로의 조합은 유출이고, Mesh 펌웨어는 IPv6를 켜 둔 채 VPN 정책이 IPv4만 덮는 경우가 많습니다.
일부러 터널을 끊고 결과를 적습니다
터널을 내리고 공유기 옆의 클라이언트가 아니라 그 노드에 연결된 클라이언트를 관찰합니다 ping 과 짧은 타임아웃의 curl 는 충분하며, 물어야 할 것은 트래픽이 멈추는지 WAN으로 되돌아가는지입니다. 터널은 공유기 자체의 서비스 명령으로 멈춥니다. 예를 들어 wg-quick down wg0 이나 OpenVPN 서비스 중지로 멈추고, 시험은 짧게 유지하십시오.
클라이언트가 계속 동작한다면 그 세그먼트에서 노드나 공유기가 열린 실패를 하고 있고, Mesh가 킬 스위치를 조용히 되돌린 것입니다. 터널을 되돌리고 핸드셰이크 카운터가 움직였는지 확인한 뒤, 세 번째 단계의 상태 테이블 점검을 다시 하십시오.
노드마다 라벨, SSID, 게이트웨이 주소, MAC 앞부분, 출구 확인 여부, IPv6 적용 여부, 터널을 내렸을 때의 동작을 한 줄씩 기록합니다. 답이 달라지는 곳은 로밍이므로 실제로 걸어 다니는 방에서 시험하십시오. 한 줄이 나머지와 어긋나면 조사할 대상은 그 노드이고, 수정은 그 줄의 게이트웨이를 가진 장비에 넣어야 합니다.