Wi-Fi 클라이언트 격리와 VPN 로컬 접근: 무엇이 당신을 막는가

같은 게스트 SSID에 휴대폰 두 대를 두면 서로 보이지 않지만 둘 다 인터넷에는 닿습니다. 그중 하나에 VPN 클라이언트를 추가하면 세 미터 떨어진 프린터는 보이지 않는 채로 남고, 다른 대륙의 서버는 ping에 응답합니다. 터널에는 고장이 없습니다. 관련된 것은 두 개의 별개 접근 결정이며 그중 하나만 경로 지정에 관한 것입니다. 액세스 포인트는 무선 클라이언트끼리 통신할 수 있는지를 정하고, VPN 클라이언트는 어떤 목적지가 터널로 나가는지를 정합니다. 이 둘을 혼동하면 몇 시간씩 쓸모없는 설정 변경이 생깁니다.

두 관문은 독립적이다

클라이언트 격리는 스위칭 결정입니다. 액세스 포인트는 연결된 한 스테이션에서 프레임을 받아 목적지를 보고, 목적지가 같은 브리지의 다른 스테이션이라는 점을 알아차리고 그 프레임을 버립니다. 그 결정에 스테이션의 IP 주소는 무관하며 VPN도 마찬가지입니다.

경로 지정은 클라이언트에서 내려지는 다른 결정입니다. VPN의 경로 테이블은 192.168.1.50으로 가는 패킷이 터널로 들어갈지 Wi-Fi 인터페이스로 나갈지를 정합니다. 패킷이 Wi-Fi로 나가고 액세스 포인트가 클라이언트를 격리하면 그 패킷은 액세스 포인트에서 사라집니다. 패킷이 터널로 들어가면 액세스 포인트는 원래 목적지를 전혀 보지 못하고 아무것도 격리할 수 없습니다.

일반적인 액세스 포인트에서 격리가 막는 것

제조사들은 이를 클라이언트 격리, AP 격리, 스테이션 격리, 또는 그것을 함축하는 게스트 네트워크라는 여러 이름으로 내놓습니다. OpenWrt에서는 인터페이스별 옵션이 무선 설정 안의 isolate이며, 무선 문서에 설명된 대로입니다. 게스트 SSID는 보통 자체 브리지와 방화벽 영역을 받습니다. 결과적으로 클라이언트 사이의 유니캐스트 프레임은 브리지되지 않아, 두 기기가 모두 신호를 꽉 채워 보여도 이웃에 대한 ping, SMB 연결, 인쇄 작업이 실패합니다.

탐색 프로토콜이 가장 먼저, 가장 눈에 띄게 타격을 받습니다. 프린터와 미디어 기기의 mDNS는 멀티캐스트로 224.0.0.251로 가고, SSDP는 239.255.255.250을 씁니다. 그 프레임이 브리지를 넘는지는 제조사와 멀티캐스트-유니캐스트 변환의 활성화 여부에 달려 있습니다. 목록에서 기기가 빠진 것은 알려진 주소로의 직접 연결 실패보다 약한 증거입니다.

VPN이 바꾸는 것과 바꿀 수 없는 것

전체 터널은 기본 경로를 가져가므로, 로컬 서브넷은 클라이언트가 그들을 위해 더 구체적인 경로를 유지할 때만 닿을 수 있습니다. 분할 터널은 반대로 하며 설계상 로컬 접근을 보존합니다. 어느 설정도 격리하는 액세스 포인트가 자기 클라이언트 둘 사이로 프레임을 넘기게 만들 수 없습니다. 그래서 VPN 클라이언트에서 로컬 트래픽을 허용하는 것은 필요하지만 충분하지 않습니다.

반대 경우도 흔합니다. 액세스 포인트는 클라이언트 간 트래픽을 허용하고, VPN 클라이언트는 로컬 서브넷을 터널에서 제외하며, 프린터는 여전히 응답하지 않습니다. 호스트 방화벽이 Wi-Fi 네트워크를 공용으로 취급하기 때문입니다. 세 계층, 세 가지 다른 기본값이 있고, 대부분의 VPN 로그에는 경로만 보입니다.

어느 관문이 닫혔는지 밝혀내기

VPN을 그림에서 빼는 시험으로, 평범한 기기 두 대를 같은 SSID에 연결하고 주소로 한쪽에서 다른 쪽으로 닿아 보십시오. 실패하면 액세스 포인트가 격리하는 것이고 어떤 VPN 설정도 고치지 못합니다. 성공하면 클라이언트로 가서 Linux에서는 ip route get 192.168.1.50을, Windows에서는 Find-NetRoute -RemoteIPAddress 192.168.1.50을 실행하십시오. 출력은 패킷이 사용할 인터페이스를 알려줍니다.

경로가 Wi-Fi 인터페이스를 가리키면 패킷은 암호화 없이 나가고, 질문은 액세스 포인트와 호스트 방화벽이 이를 허용하는지가 됩니다. 경로가 터널을 가리키면 목적지가 VPN 서버로 보내지는 것이며, 같은 LAN의 기기에는 틀린 일이고 보통 터널의 허용 목록이 너무 넓다는 뜻입니다.

프린터 포트로의 직접 연결이 탐색 목록보다 나은 시험입니다. Linux에서는 nc -vz 192.168.1.50 9100, PowerShell에서는 Test-NetConnection 192.168.1.50 -Port 9100이 애플리케이션 수준 페어링 이야기가 나오기 전에 그 주소에 닿을 수 있는지를 알려줍니다.

지금 있는 네트워크에 맞는 해결책 고르기

호텔이나 게스트 네트워크에서 격리는 의도된 것이며 이를 깨려 해서는 안 됩니다. 로컬 기기는 닿을 수 없는 것으로 취급하고, 인쇄나 공유가 가능한 호스트에 닿을 때는 VPN을 쓰며, SSID를 LAN으로 취급하는 것을 그만두십시오.

집에서는 기기가 본인 것일 때 기본 SSID의 격리를 끄는 것이 합리적이며, 게스트 SSID는 격리된 채로 둡니다. 설정은 액세스 포인트의 무선 구성에 있고 거기에 속하며, 각 클라이언트의 방화벽 예외에 속하지 않습니다.

사무실에서는 액세스 포인트, VLAN, 호스트 방화벽이 모두 의도된 것이라고 가정하십시오. 격리를 꺼 달라고 요청하는 대신 시험 결과를 가지고 에스컬레이션하십시오. 클라이언트를 분리하는 네트워크는 보통 무언가를 보호하고 있기 때문입니다.

애플리케이션을 검증하고 ping만 보지 마십시오

성공한 ping은 경로를 증명할 뿐 서비스를 증명하지 않습니다. 프린터는 흔히 원시 9100이나 631의 IPP를 받아들이면서 탐색은 거부하고, 파일 공유에는 445와 동작하는 이름 해석이 필요합니다. 애플리케이션이 쓰는 포트를 확인한 다음 기기에서 실제 작업을 다시 시도하십시오.

메모에서 두 계층을 분리해 두십시오. Wi-Fi 네트워크가 허용하는 것과 VPN이 경로를 잡는 것입니다. 다음에 기기가 목록에서 사라지면 그 분리가 어디를 먼저 볼지 알려줄 것입니다.