Windows VPN이 로컬 프린터를 죽이는 이유와 막는 방법

VPN에 연결하면프린터가 사라지고, NAS 공유가 열리지 않으며 옆에 있는 PC로의 원격 데스크톱 세션이 시간 초과됩니다. 고장 난 것은 없습니다. 클라이언트가 기본 경로를 추가했고 이제 노트북이 이름을 댈 수 있는 모든 목적지를, 삼 미터 떨어진 곳까지 포함해 소유합니다. 이것이 전부이며, 이를 VPN 결함이라고 부르는 것이 한 줄 수정을 지원 케이스로 만듭니다.

먼저 라우팅 테이블을 읽으십시오

무엇이든 바꾸기 전에 IPv4 테이블을 다음으로 캡처하십시오: route print -4 그리고 출력을 보관하십시오. 연결한 뒤 다시 캡처하고 이 줄들을 비교하십시오: 0.0.0.0활성 기본 경로가 인터페이스를 지목하며, 그 인터페이스가 터널이면 로컬 인쇄와 탐색이 먼저 사무실로 전송됩니다.

두 번째 열의 인터페이스 번호가 바로 영구 경로가 나중에 참조해야 하는 값이므로 터널이 켜져 있을 때 적어 두십시오. 이 값은 어댑터가 다시 만들어질 때 바뀌는 값이기도 하므로, 여기에 고정된 경로는 조용히 유효 수명을 넘길 수 있습니다.

기본 경로를 제거하는 세 가지 방법

내장 Windows 프로필에서는 컨트롤이 확인란입니다. 연결 속성을 열고 IPv4, 그다음 고급으로 가서 Use default gateway on remote network 항목을 지우십시오. 더 새로운 설정 앱은 같은 대화 상자를 한 단계 더 깊이 숨기지만, 관리자 권한 명령 프롬프트에서는 같은 변경이 cmdlet 하나입니다:

Set-VpnConnection -Name "Corp" -SplitTunneling $true

OpenVPN 프로필은 다르게 동작하므로 확인란을 기대하는 사람을 혼란스럽게 합니다. 그 redirect-gateway def1 지시문은 기본 경로를 전혀 대체하지 않고, 절반 범위 경로 두 개를 설치합니다: 0.0.0.0/1 및 128.0.0.0/1, 이 둘은 함께 기본 경로를 삭제하지 않고 이깁니다. 원래 기본 경로가 살아남으므로, net_gateway 를 가리키는 프리픽스를 추가하면 그 프리픽스만 로컬 라우터로 돌아갑니다. 이 세부 사항이 def1 프로필의 해결책이 아무도 찾지 못하는 확인란이 아니라 프리픽스 경로인 이유입니다.

업무에 속한 것만 되돌려 놓으십시오

기본 경로가 없으면 터널은 아무것도 나르지 않으므로 업무 프리픽스를 명시적으로 지정해야 하며, 프리픽스를 연결에 묶는 cmdlet은 영구 경로보다 안전합니다. 그 연결이 켜져 있는 동안에만 설치되고 인터페이스 번호에 의존하지 않기 때문입니다:

Add-VpnConnectionRoute -ConnectionName "Corp" -DestinationPrefix 172.20.0.0/16

더 오래된 방법도 여전히 작동하며 여전히 모든 점검 목록에 있습니다: route -p add 172.20.0.0 mask 255.255.0.0 172.20.0.1 if 14, 터널 자체의 인터페이스 인덱스와 게이트웨이 주소를 사용합니다. 재부팅을 넘겨 유지되며, 다음 부팅에서 그 인덱스가 다른 것의 것일 수 있기 때문에 그것이 목적이자 위험이기도 합니다.

나머지는 메트릭이 결정합니다. 물리 어댑터와 터널 어댑터가 같은 프리픽스의 경로를 주장하면 낮은 메트릭이 이기며, 터널 메트릭을 높이는 것은 해킹이 아니라 클라이언트 측의 정당한 제어입니다.

서버가 대신 결정할 때

확인란을 무시하는 클라이언트는 보통 정책을 따르고 있습니다. Cisco 프로필에는 Allow Local LAN Access 설정이 있고, 헤드엔드는 클라이언트가 원하는 것을 덮어쓰는 tunnel-all 정책을 밀어 넣을 수 있으며, 강제 터널 배포에서는 뒤집을 로컬 스위치가 없습니다. 같은 대화 상자를 다시 확인하는 대신 클라이언트 로그에서 밀려온 경로와 정책 줄을 읽으십시오.

다음으로, 라우팅과는 별개의 스위치인 이름 확인을 보십시오. 분할 터널은 여전히 내부 리졸버와 검색 접미사를 받을 수 있으므로, DNS 측도 고쳐질 때까지 로컬 장치는 주소로는 닿지만 이름으로는 찾을 수 없습니다.

겹침은 다른 문제입니다

집 LAN과 사무실 LAN이 192.168.0.0/24 같은 프리픽스를 공유하면 어떤 경로도 둘을 구분할 수 없습니다. 그 범위의 모든 패킷은 조회 결과가 하나뿐이며, 해결책은 한쪽의 번호를 다시 매기거나 풀에서 변환된 주소로 사무실에 도달하는 것입니다. 더 구체적인 경로를 추가하는 것은 네트워크의 어느 절반이 깨지는지만 옮깁니다.

다섯 번이 아니라 한 번의 검증으로 끝내십시오: 연결한 다음 tracert 를 내부 호스트와 공용 호스트에 대해 실행하십시오. 첫 홉이 달라야 하며, 그렇지 않다면 클라이언트가 무엇을 보고하든 분할은 적용되지 않습니다. 밀려온 경로가 세션마다 돌아오므로 그다음 한 번 다시 연결해 반복하십시오.