사무실 네트워크에서 Always On VPN이 자동 연결되지 않는 이유

노트북이 사무실 Wi-Fi에 연결되면 집에서 연결되던 Always On 프로필은 내려간 상태로 남습니다. 이벤트 로그는 클라이언트 입장에서 네트워크가 신뢰되었고 터널이 필요 없었으므로 이를 실패라고 부르지 않습니다. 이 판단을 내리는 기능이 신뢰할 수 있는 네트워크 감지이며, 익숙한 SSID를 인식하는 대신 특정 값을 비교합니다. 판단이 잘못되었을 때는 어떤 비교가 통과했는지 확인해야 합니다.

트리거가 실제로 비교하는 것

클라이언트가 네트워크를 신뢰할 수 있다고 보기 전에 세 가지가 맞아떨어져야 합니다. 첫째, Windows가 실제 어댑터에 기록하는 연결별 DNS 접미사가 프로필의 접미사 목록에 있어야 합니다. 둘째, Windows가 해당 네트워크에 대해 유지하는 연결 프로필이 정책이 기대하는 프로필이어야 합니다(일치 여부는 그 프로필을 기준으로 판단하며, 무선 대화 상자에서 사용자가 입력한 이름을 기준으로 하지 않습니다). 셋째, 네트워크가 정책이 요구하는 방식으로 분류되어야 합니다. 이는 실제로 도메인 네트워크나 개인 네트워크, 또는 관리 경로로 정책이 도달한 장치를 뜻하며, 하나라도 빠지면 트리거가 작동합니다.

이는 VPN의 공인 출구 주소를 비교하는 것보다 좁은 검사이고, SSID를 신뢰하는 것보다 훨씬 좁습니다. 회사 이름을 되풀이하는 액세스 포인트만으로는 접미사와 프로필 비교를 만족하지 못합니다. 또한 이 기능은 네트워크가 안전한지에 대해서는 아무 말도 하지 않으며, 이 장치가 이미 집에 있다고 보는지만 알려 줍니다.

프로필을 바꾸기 전에 현재 상태를 읽으세요

Windows가 지금 무엇을 믿는지부터 시작합니다. 연결 프로필 cmdlet은 네트워크 이름, 인터페이스, Windows가 지정한 범주를 보고하며 이것이 위의 세 번째 비교입니다. 그다음 VPN 프로필을 읽고 신뢰할 수 있는 접미사 목록을 찾되, 속성 이름을 추측하지 말고 전체 속성 덤프를 사용하십시오:

Get-NetConnectionProfile
Get-VpnConnection -Name "Corp VPN" | Format-List *

그 덤프가 빌드에서 신뢰 접미사를 드러내지 않으면, 버전 간에 속성 표면이 다를 때 권위 있는 사본인 프로필 XML로 돌아가십시오. 관리 정책이나 모든 사용자 프로필 저장소에서 XML을 읽고, 그 접미사 항목을 위에서 보고된 어댑터 접미사와 비교하십시오. 둘 중 하나를 건드리기 전에 두 값을 모두 기록하십시오.

경계를 양방향으로 시험하세요

의도한 회사 연결과 승인된 다른 네트워크에서 시험하고 터널이 올라왔는지 적으십시오. 그다음 네트워크를 떠난 뒤 같은 장치를 시험하십시오. 집에서는 작동하고 사무실에서는 억제되는 노트북은 설계대로 동작하며, 어디서도 작동하지 않는 노트북은 다른 결함이 있습니다. 작동한 경우 터널 뒤의 리소스에 접근할 수 있는지 확인하십시오(터널이 시작되었다는 것이 동작하는 경로의 증거는 아닙니다).

알림을 없애기 위해 넓은 접미사를 추가하지 마십시오. 많은 네트워크에 나타나는 접미사는 거의 모든 곳에서 터널을 억제하도록 클라이언트를 가르치며, 그 뒤에 따르는 지원 부담은 알림보다 나쁩니다. 기준은 프로필 소유자를 통해 바꾸십시오(관리되는 집합에서는 노트북 앞의 사람이 아니라 MDM 관리자가 소유자입니다).

두 시험 네트워크를 결과와 함께 기록에 남기십시오. 한 번도 시험하지 않은 경계는 주장일 뿐입니다.

억제와 차단을 구분하세요

시작되지 않은 터널은 차단된 연결이 아닙니다. 신뢰할 수 있는 네트워크 감지는 자동 트리거를 제어하고, 트래픽 필터링과 킬 스위치 동작은 자체적인 실패 모드를 가진 별도의 정책 설정입니다. 신뢰 네트워크의 장치가 터널 밖으로 트래픽을 보내는 것은 정당할 수 있으며, 정책을 읽지 않고 이를 유출이라고 부르면 두 설계를 혼동하는 것입니다. 유출의 책임을 감지에 돌리기 전에 프로필의 트래픽 규칙을 확인하십시오.

같은 구분이 반대의 불만을 설명합니다. VPN이 무작위로 멈췄다고 보고하는 사용자는 대개 기준을 충족한 네트워크 변경을 설명하는 것이지 서비스 장애가 아닙니다. 일치한 접미사와 네트워크 범주가 수집해야 할 증거이며 둘 다 위의 출력에 나타납니다.

정책을 바꾸기 전에 그 증거를 모으십시오. 증상을 숨기는 토글은 원인도 숨깁니다.

판단이 무엇에 근거했는지 기록하세요

일치한 접미사, 연결 프로필 이름, 네트워크 범주를 각 사이트의 배포 노트에 적으십시오. 터널이 올라오지 않을 때 이 기록은 수수께끼를 비교로 바꿉니다(세 값 중 하나가 바뀌었는지, 아니면 정책이 바뀌었는지가 드러납니다). 또한 티켓을 닫기 위해 감지를 끄는 대신 다음 엔지니어가 설계를 확인할 방법을 제공합니다.

사이트 이름이 바뀌거나 도메인이 통합될 때는 오래된 항목이 조용히 터널을 계속 억제하므로 접미사 목록을 검토하십시오. Microsoft의 신뢰할 수 있는 네트워크 감지 참조에는 프로필 요소와 배포 전제 조건이 정리되어 있으며, 누군가 목록 확장을 제안할 때 인용해야 할 문서입니다.