로컬 장치가 VPN에서 사라짐: 세 가지 별개의 장애

VPN이 켜질 때 장치 목록에서 사라지는 프린터도 자기 주소에서는 여전히 응답할 수 있다. 목록은 검색으로 채워지고, 이름은 리졸버에서 올 수 있으며, 서비스 자체는 소켓으로 도달하므로 이 셋은 각각 독립적으로 실패할 수 있다. 어느 계층에서 무엇이 동작하는지 비교하면 어떤 기능을 바꿔야 하는지 알 수 있다. 먼저 모든 로컬 접근 예외를 켜면 증거가 사라진다.

그것이 없는 장치와 단지 광고되지 않는 장치의 차이다.

검색, 이름, 도달 가능성은 세 개의 계층이다

검색 프로토콜은 멀티캐스트나 브로드캐스트에 의존하며, 이들은 기본적으로 라우팅된 터널을 넘지 않으므로 장치는 목록에서 사라져도 여전히 완전히 도달 가능할 수 있다. 이름 확인은 두 번째 계층으로, VPN은 리졸버를 바꿀 수 있고 이전에 로컬 네트워크가 응답하던 이름이 이제 다른 곳에서 확인되거나 전혀 확인되지 않을 수 있다. 도달 가능성은 라우트, 방화벽 규칙, 수신 대기 서비스로 이루어진 세 번째 계층이다. 다른 두 계층이 정상이어도 각 계층은 따로 깨질 수 있다.

아래에서 위로 시험해 보자. 도달 가능성 검사 하나로 분리가 분명해지는데, nc -vz 192.168.1.20 443 가 성공하면 경로와 서비스가 정상이고 의심 대상은 이름이며, 실패하면 문제는 라우팅과 정책으로 넘어간다. 그다음 이름을 물어보자. 처음 마주치는 실패가 작업해야 할 계층이며, 그 위의 계층은 이를 보상할 수 없다.

먼저 주소를 묻고, 그다음 호스트 이름을 묻는다

주소는 응답하고 이름이 응답하지 않는다면 문제는 라우팅이 아니라 확인이다. 자체 리졸버를 설치하는 VPN 클라이언트는 로컬 이름에 어느 서버가 응답하는지를 바꿀 수 있고, 로컬 도메인을 전달하지 않는 클라이언트는 이름을 응답 없이 남긴다. 주소도 실패한다면 문제는 경로로, 터널을 통한 기본 라우트, 클라이언트 측의 로컬 트래픽 차단, 또는 물리 인터페이스만 허용하는 방화벽 규칙이다.

둘 다 동작하는데 자동 검색이 안 된다면, 장치가 터널 너머로 자신을 광고하지 않을 뿐이다. 이는 멀티캐스트 기반 검색에서 예상되는 동작이며 설정 실패가 아니다. 주소로 장치를 추가하는 것이 보통 정직한 해결책이다.

로컬 접근 토글이 실제로 바꾸는 것

로컬 네트워크 접근 설정은 보통 직접 연결된 서브넷으로 가는 트래픽이 터널을 우회하도록 허용하며, 클라이언트마다 다르게 동작한다. 원격 사무실로의 전달을 설정하지 않고, 호스트 방화벽이나 앱 자체의 권한을 바꾸지도 않는다. 겹치는 서브넷을 명확하게 만들지도 않는다. 널리 켜기 전에 이 설정이 무엇을 다루는지 클라이언트 문서를 읽어 보자.

신뢰하는 장치 하나에 대한 좁은 예외가 포괄적 허용보다 낫다. 특히 차단이 의도적일 수 있는 게스트 네트워크에서는 그렇고, 사설 주소는 신원 확인이 아니므로 선택은 자신이 있는 네트워크에 달려 있다.

네트워크가 겹칠 때

집 네트워크와 원격 네트워크가 같은 범위를 쓰면 라우팅이 모호해지고, 로컬 접근 토글도 예외도 이를 해결하지 못한다. 같은 주소의 두 서비스에 모두 도달할 수 없고, 어느 쪽이 이기는지는 의도가 아니라 라우트의 구체성과 순서에 달려 있다. 해결책은 주소 계획이지 클라이언트 설정이 아니다. 프린터로 저녁을 보내기 전에 범위를 확인하자.

원격 게이트웨이 뒤의 장치라면 전달, 호스트 정책, 반환 경로는 운영자의 몫이다. 클라이언트의 로컬 체크박스로는 어느 것도 제공할 수 없고, 그것을 요구하는 편이 토글을 실험하는 것보다 생산적이다.

어느 계층이 실패했고 무엇을 바꿨는지 기록하자. 다음 장치도 같은 세 곳 중 한 곳에서 실패할 것이다.