Windows 연결을 공유하고 있나요? 그 아래에서 VPN 경로가 달라집니다

노트북이 Wi-Fi를 공유하고, 호스트는 불평 없이 터널을 통해 브라우징하며, 그 공유 위의 태블릿은 아무것도 도달하지 못합니다. 공유가 켜진 순간 호스트는 더 이상 클라이언트만이 아니었고, 이제 라우터이며 전달된 패킷은 다른 규칙 집합을 만납니다. 호스트에서 되는 것은 그 뒤의 기기에 대해 아무것도 말해 주지 않습니다. 하위 클라이언트에서 점검을 실행하면 이 구분은 더 이상 이론이 아닙니다.

호스트의 성공은 아무것도 증명하지 않는다

연결 공유는 한 대의 기계에 주소 할당, 전달, 변환, 필터링이라는 네 가지 일을 맡깁니다. 로컬에서 생성된 트래픽을 보호하는 VPN 클라이언트는 전달된 트래픽을 자신의 범위 밖으로 볼 수 있습니다, 또는 누출로 간주해 의도적으로 차단할 수 있습니다. 어느 행동도 버그가 아니며, 어느 것도 공유를 켠 화면에 적혀 있지 않습니다. 어느 쪽인지는 하위 테스트만이 알려 줍니다.

많은 클라이언트는 호스트 트래픽만 전달하고 그 외에는 아무것도 하지 않으므로, 터널이 태블릿을 위해 라우팅해 주리라 믿는 대신 클라이언트 문서의 공유 항목을 확인하세요. 눈에 보이는 증상은 연결되고 주소를 받은 뒤 첫 요청에서 실패하는 기기입니다. 전달을 거부하는 클라이언트도 호스트에서는 여전히 완전히 건강해 보입니다.

어느 어댑터가 공유되고, 어느 것이 클라이언트를 처리하는가

서로 다른 주소와 서로 다른 필터를 가지며 잘못된 쪽에서의 변경이 많은 혼란스러운 결과를 설명하므로 두 어댑터를 모두 기록하세요. 공유 호스트는 보통 하위 쪽에서 고정 주소를 갖고 그곳에서 작은 DHCP 및 DNS 서비스를 실행합니다. Windows는 전달을 전역이 아니라 어댑터별로 유지하므로 상태를 인터페이스마다 읽어야 합니다.

Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object Name,InterfaceIndex,LinkSpeed
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias,IPAddress,PrefixLength
Get-NetIPInterface | Select-Object InterfaceAlias,Forwarding,ConnectionState
Get-NetConnectionProfile

공유 어댑터에서 전달이 사용 안 함으로 표시되면 터널이 무엇을 하든 하위에서는 아무것도 작동하지 않습니다. 다른 기기를 위해 라우팅하도록 정책이 허용하는 기기에서만 활성화하세요.

전달, 변환, 필터링

전달된 패킷은 터널에 도달하고, 원격 쪽이 받아들이는 형태로 변환되고, 같은 변환을 거쳐 돌아와야 합니다. 이 세 단계 중 어느 것이든 깨질 수 있고, 모든 고장은 같은 브라우저 시간 초과를 만듭니다. 패킷 캡처, 경로 조회, 원격 쪽의 로그는 공유 대화 상자를 다시 검토하는 것보다 가치가 있습니다. 어느 단계가 실패하는지가 누구의 변경이 필요한지를 알려 줍니다.

원격 쪽은 VPN 서버가 본 적 없는 범위인 공유 서브넷을 위한 반환 경로도 필요할 수 있습니다. 클라이언트가 변환하는 곳에서는 서버가 터널 주소만 보고 반환 경로가 필요하지 않습니다. 변환하지 않는 곳에서는 게이트웨이를 소유한 사람이 그 경로를 의도적으로 추가해야 하며, 그것은 클라이언트 설정이 아니라 변경 요청입니다.

점검은 호스트가 아니라 클라이언트에서

모든 점검을 작동하는 호스트가 아니라 실패하는 클라이언트에서 실행하세요. 한 시간 간격으로 수집한 결과가 세 가지의 결합에 대해 아무것도 말해 주지 않으므로 송신 주소, 리졸버 응답, 애플리케이션 테스트를 같은 세션에 유지하세요.

Resolve-DnsName intranet.example.net -Type A
Resolve-DnsName intranet.example.net -Type AAAA
Invoke-RestMethod https://api.ipify.org
Test-NetConnection intranet.example.net -Port 443 -InformationLevel Detailed

송신 주소를 호스트 자신의 주소와 비교하고 둘이 일치하는지 기록하세요. 다른 응답은 전달 경로가 터널을 우회한다는 뜻이며, 이는 빠른 수정이 아니라 책임자가 있는 정책 문제입니다. 실패하는 애플리케이션 옆에 일치하는 응답이 있으면 작업은 이름 해석이나 원격 쪽 정책으로 옮겨집니다. IPv4 결과에서 멈추지 말고, 공유가 모든 IPv4 점검을 통과해도 IPv6는 다른 출구로 나갈 수 있으므로 AAAA 레코드와 상세 연결 테스트로 이름과 송신 점검을 반복하세요.

관리되는 기기에서는 다른 기기에 대한 접근을 여는 것이 편의 스위치가 아니라 관리 결정이므로 공유가 애초에 허용되는지 확인하세요. 지원되는 변경 후에는 다시 연결할 때와 장애 중에 점검을 반복하세요. 호스트가 깨끗하게 다시 연결되어도 클라이언트가 지원한 적 없는 전달 경로는 복구되지 않습니다.