무선 클라이언트는 액세스 포인트가 터널에 대해 아무것도 모른 채 VPN 뒤에 있을 수 있다. 무선을 게이트웨이의 LAN에 브리지하고, 주소 지정과 터널을 게이트웨이가 소유하게 하면, Wi-Fi의 모든 장치가 같은 정책을 물려받는다. 다른 선택인 자체 게이트웨이를 둔 두 번째 라우팅 세그먼트는 다른 장애 모드를 가진 다른 설계다.

둘 다 인터넷과 장치 사이에 상자를 놓기 때문에 혼동된다. 각자가 무엇을 소유하는지 비교하는 것이 선택하는 가장 빠른 길이다.

VPN을 Wi-Fi 앞에 두는 두 가지 방법

브리지 배치에서 액세스 포인트는 무선과 유선 세그먼트 사이에서 프레임을 나를 뿐 그 밖의 일은 하지 않는다: 서브넷 하나, 주소 권한 하나, 정책을 수행하는 라우터 하나다. 라우팅 배치에서는 두 번째 상자가 자체 주소, 자체 DHCP 범위, 자체 기본 경로를 가지므로 트래픽은 터널에 도달하기 전에 경계를 하나 더 넘는다. 브리지 설계는 모든 무선 장치를 게이트웨이에 대해 로컬로 보이게 하므로 규칙 한 세트가 모두를 덮는다. 라우팅 설계는 생각할 세그먼트와 정책이 잘못될 두 번째 장소를 준다.

internet
  -> vpn-capable gateway: routing, tunnel, dns, failure policy
  -> bridged access point: radio onto the same lan
  -> wifi clients

무선 장치가 유선 장치와 같은 터널을 쓰는 것이 요구 사항이면 브리지를 고른다. 격리할 수 있는 세그먼트를 원하거나 두 번째 상자가 이미 라우터로 존재하면 라우팅을 고른다.

브리지 배치가 실제로 바꾸는 것

브리징은 변환 계층과 경쟁하는 기본 게이트웨이를 없애고 관리 문제를 더한다. 액세스 포인트는 여전히 접근할 수 있는 주소가 필요하며, 벤더 워크플로는 보통 메인 LAN을 통해 이를 마련한다. 그 DHCP 서비스는 꺼져 있어야 하며, 그렇지 않으면 두 권한이 서로 충돌하는 임대를 내준다. 게이트웨이는 터널, 리졸버 설정, 터널이 끊겼을 때 무엇을 할지에 대한 결정을 보유하므로 정책은 정확히 한 곳에 산다.

무선은 그런 것들을 터널에서 자동으로 물려받지 않는다. 그것을 가릴 계층을 더하는 일을 그만둘 뿐이다.

두 번째 라우팅 세그먼트가 맞는 곳

라우팅 세그먼트는 그 뒤의 장치가 LAN의 나머지와 다른 취급을 필요로 할 때 복잡성을 정당화한다. 게스트 네트워크, 실험실, 또는 항상 특정 국가를 통해 나가야 하는 클라이언트 집합은 모두 경로에 라우터를 두는 이유다. 대가는 두 번째 주소 권한, 일관성을 유지해야 하는 두 번째 방화벽, 그리고 그쪽 누군가가 세그먼트에 도달해야 할 경우 메인 LAN에서의 반환 경로다. 이는 구성 세부 사항이 아니라 의무다.

흔한 실수는 여전히 자체 DHCP와 변환을 돌리는 라우터를 재사용해 라우팅 버전을 우연히 만드는 것이다. 그것은 이중 변환과 아무도 추적할 수 없는 정책을 낳는다.

게이트웨이가 아니라 Wi-Fi 클라이언트에서 시험한다

게이트웨이에서의 성공한 요청은 터널이 게이트웨이에 대해 작동함을 증명한다. 진짜 질문은 무선 클라이언트의 전달 트래픽이 그것을 쓰는지이며, 이는 클라이언트에서 관찰해야 한다. 아래 명령은 클라이언트의 주소, 경로, 원격 서비스가 보는 주소를 확인한다.

ip -4 addr show wlan0
ip route get 1.1.1.1
curl -sS https://api.ipify.org; echo
traceroute -n -m 4 1.1.1.1

게이트웨이 LAN 내부의 주소는 브리지가 프레임을 변환하지 않고 통과시킨다는 것을 확인해 준다. 첫 홉이 게이트웨이인 경로는 클라이언트가 다른 곳에서 두 번째 기본 경로를 얻지 않았음을 확인해 준다. 출구 주소 확인이 진짜 질문에 답하며, 짧은 추적은 첫 홉이 예상대로인지 보여 준다. 클라이언트의 주소가 다른 범위에서 온다면 첫 용의자는 길을 잃은 DHCP 서버다.

각 상자의 역할, 주소, DHCP 권한을 적어 둔다. 세 줄짜리 도면이면 충분하고, 규칙이 어디에 속하는지에 대한 대부분의 논쟁을 정리한다.

관련 글