게스트 Wi-Fi가 계속 메인 경로를 사용합니다: 자체 출구를 주세요

게스트 네트워크를 만들고 경로를 추가했는데도 게스트는 여전히 일반 인터넷 연결로 나갑니다. 터널은 올라와 있고, 메인 LAN도 작동하며, 게스트 장치는 할당한 범위의 주소를 보고하므로 아무것도 고장 난 것처럼 보이지 않습니다. 보통 빠진 것은 경로가 아니라 선택자입니다: 라우터는 패킷이 어느 인터페이스로 도착했는지 고려하기 전에 경로를 결정하므로, 무언가가 게스트 트래픽과 명시적으로 일치하지 않으면 그 트래픽은 기본값을 상속합니다. 해결책은 세그먼트, 정책 규칙, 반환 경로의 순서입니다.

증상: 게스트가 여전히 WAN으로 나갑니다

단서는 출구 주소입니다. 터널을 통해 인터넷에 도달한 게스트 장치는 터널 제공자의 주소를 보고하고, 기본값을 상속한 장치는 일반 연결을 보고합니다. 게스트 장치와 메인 LAN 장치를 나란히 비교하십시오, 흥미로운 경우는 구성한 것과 다르면서 서로 일치할 때입니다.

두 번째 단서는 게스트가 탐색하는 동안 터널 인터페이스에 트래픽이 전혀 없다는 점입니다. 카운터가 움직이지 않으면 정책이 적용된 적이 없으며, 터널 자체를 조정해도 도움이 되지 않습니다.

1단계: 이름만이 아닌 실제 세그먼트

SSID 이름만으로는 격리가 생기지 않습니다. 게스트 네트워크가 자체 인터페이스, VLAN 또는 브리지에서 끝나는지, 주소 범위가 신뢰할 수 있는 LAN과 다른지 확인하십시오. 많은 소비자용 액세스 포인트에서 게스트 SSID는 다른 모든 것과 같은 세그먼트로 브리지되므로, 이를 고치기 전에는 나머지 작업이 불가능합니다.

그런 다음 게스트 범위와 해당 DHCP 서버를 확인하고, 리졸버 설정은 라우터 전체가 아니라 그 세그먼트에 연결해 두십시오. 방화벽 규칙의 주석으로만 존재하는 게스트 서브넷은 세그먼트가 아니며, 라우터에는 일치시킬 인터페이스가 없습니다.

VPN 구성을 쉽게 하려고 게스트를 메인 LAN으로 브리지하지 마십시오. 그것은 원하던 격리를 라우팅 지름길과 맞바꾸는 것이며, 게스트 네트워크가 결국 프린터와 NAS에 접근하게 되는 흔한 이유입니다.

2단계: 소스로 터널을 선택합니다

라우팅 테이블은 목적지로 선택되므로 「0.0.0.0/0을 터널로 보내라」는 규칙은 모든 사람에게 적용됩니다. 정책 라우팅은 두 번째 차원을 추가합니다: 소스 주소로 테이블을 선택하는 것입니다. Linux 기반 라우터에서는 추가 규칙과 전용 테이블이 필요하며, 첫 번째 일치 규칙이 이기므로 순서가 중요합니다:

ip rule add from 192.168.60.0/24 lookup 100 priority 1000
ip route add default dev wg0 table 100
ip route get 1.1.1.1 from 192.168.60.10

마지막 명령이 질문에 직접 답합니다: 이 소스가 이 목적지에 어떤 인터페이스를 사용할 것인가입니다. 변경 전후에 실행하면 브라우저를 건드리지 않고도 정책이 적용되었는지 알 수 있습니다.

대부분의 라우터 펌웨어는 같은 내용을 인터페이스 규칙이나 소스 기반 게이트웨이 선택으로 표현합니다. 플랫폼이 어떤 구문을 쓰든 원리는 같습니다: 입력 인터페이스나 소스 접두사와 일치시킨 다음, 그 일치에만 경로를 재정의합니다. 목적지로 일치하는 규칙은 게스트와 가정용 장치를 구분할 수 없습니다.

3단계: 반환 경로와 변환

터널로 나간 패킷은 돌아와야 합니다. 터널 피어가 게스트 접두사로 돌아가는 경로를 알거나, 라우터가 게스트 소스를 터널 주소로 변환합니다. 하나를 선택해 적어 두십시오, 실패 방식이 다르기 때문입니다: 반환 경로가 없으면 연결은 설정되지만 응답이 없고, 변환이 없으면 아무것도 나오지 않는 경우가 많습니다.

nft add rule ip nat POSTROUTING ip saddr 192.168.60.0/24 oifname "wg0" masquerade

변환을 선택하면 피어가 이제 모든 게스트에 대해 하나의 주소를 보므로 원격 끝의 클라이언트별 정책은 사라집니다. 주소를 유지하면 양쪽 끝의 라우팅과 정책에 게스트 접두사가 필요하며, 작업은 늘지만 예측 가능합니다.

IPv6에는 자체 규칙이 필요합니다. IPv4용으로 작성한 정책은 다른 패밀리를 다루지 않으며, IPv6가 작동하는 게스트 장치는 그것을 기꺼이 사용하고 신중하게 라우팅한 IPv4 경로는 유휴 상태로 남습니다. 두 패밀리를 모두 라우팅하거나 게스트 세그먼트에서 IPv6를 비활성화하십시오, 하지만 작성한 결합 규칙이 장치가 실제로 하는 일을 다룬다고 가정하지 마십시오. 두 패밀리가 모두 활성화된 클라이언트로 설계가 견뎌야 하는 경우는 두 패밀리가 모두 활성화된 클라이언트로 테스트하는 것입니다. IPv6를 선호하는 노트북은 IPv4 전용 테스트에서는 올바르게 보이지만 실제에서는 누출됩니다.

격리를 테스트하십시오, 탐색만이 아니라

탐색은 출구가 바뀌었다는 것을 증명합니다. 세그먼트가 격리되었다는 것은 증명하지 않으며, 격리가 게스트 네트워크의 존재 이유입니다. 게스트 장치에서 라우터의 관리 인터페이스, 신뢰할 수 있는 LAN 호스트, 거부되어야 할 서비스에 도달해 보십시오, 셋 다 실패해야 하며, 그 실패는 아무도 설명할 수 없는 시간 초과가 아니라 정책 결정이어야 합니다.

그다음 메인 LAN 장치를 테스트해 출구가 바뀌지 않았는지 확인하십시오. 이 설계가 가장 자주 일으키는 회귀가 그것입니다: 게스트를 위한 광범위한 규칙이 목적지에서 일치를 작성했기 때문에 모든 인터페이스에 적용되는 것입니다.

마지막으로 터널이 끊겼을 때 어떻게 할지 결정하십시오. 게스트는 인터넷을 못 받거나 승인한 경로로 폴백합니다, 이를 결정하지 않으면 일반 연결로 조용히 폴백하며, 그것이 바로 게스트 정책이 막으려던 누출입니다. 인터넷 트래픽 라우팅 레시피에서는 pfSense 기반 라우터의 같은 경로 선택을 단계별로 설명합니다.

라우터에서 발생하는 DNS는 사람들을 마지막에 놀라게 하는 경우입니다. 게스트가 라우터를 리졸버로 사용하면 라우터 자체의 쿼리는 게스트 규칙이 아니라 라우터의 경로를 따르므로, 애플리케이션 트래픽은 나가지 않는데 조회만 일반 연결로 나갈 수 있습니다. 세그먼트, 리졸버, 장애 정책을 메모 하나에 정리해 두면 다음 사람이 설계를 다시 도출하지 않고 셋 다 확인할 수 있습니다.