VPN 연결 후 사내망 접속 안됨: DNS·포트·경로 점검법

AI Editter

회사 VPN에는 ‘연결됨’이라고 뜨는데 그룹웨어는 열리지 않는다. 인터넷은 잘 되고 사내 사이트만 안 되기도 한다. VPN을 여러 번 다시 연결하기 전에 이름을 IP로 바꾸는 과정, 해당 IP까지 가는 경로, 서비스 포트, 로그인 권한을 나눠 확인하면 원인을 좁힐 수 있다.

이 글은 VPN 연결 후 사내망 접속 안됨 문제를 Windows 11에서 점검하는 방법이다. 회사가 허용한 내부 서비스 하나를 대상으로 확인하며, VPN 제품별 정책 변경은 담당 관리자가 처리한다. 아래 명령의 portal.corp.example과 10.20.30.40은 설명용 예시이므로 실제로 안내받은 주소로 바꾼다. 기술 문서 확인일은 2026년 9월 20일이다.

증상에 따라 먼저 볼 곳이 다르다

증상	먼저 확인	아직 단정할 수 없는 것
사내 이름을 찾을 수 없다는 오류	DNS 응답·사내 DNS·이름 접미사	VPN 터널 자체가 끊겼는지 여부
이름은 IP로 바뀌지만 연결 시간 초과	라우팅·서비스 포트·서버 상태	방화벽만의 문제인지 여부
페이지가 열리지만 401·403 또는 권한 오류	앱 로그인·접근 정책·단말 조건	TCP 접속 성공만으로 업무 권한까지 정상인지 여부
VPN을 켜면 외부 인터넷도 안 됨	전체 터널 정책·회사 측 인터넷 경로·프록시	분할 터널로 바꾸면 해결해도 되는지 여부

일단 오류 화면과 발생 시각을 기록한다. 로그인 버튼까지는 보이는지, 주소를 찾지 못하는지, 계속 기다리다 실패하는지에 따라 다음 점검이 달라진다. 주소 전체에 일회용 토큰이 붙어 있다면 문의 자료에는 토큰 부분을 빼고 남긴다.

1. 사내 주소가 올바른 IP로 해석되는지 확인

시작 메뉴에서 Windows PowerShell을 열고 회사에서 알려 준 전체 도메인 이름으로 조회한다. portal 같은 짧은 이름보다 portal.corp.example처럼 끝까지 적은 이름으로 먼저 확인한다.

Resolve-DnsName -Name portal.corp.example -DnsOnly
Get-DnsClientServerAddress

첫 명령은 DNS 응답을, 두 번째 명령은 인터페이스별 DNS 서버 주소를 보여 준다. 응답에 IP가 나와도 회사에서 기대하는 주소와 같은지 확인해야 한다. 사내외에서 다른 주소를 돌려주는 구성이 있을 수 있다. Resolve-DnsName 문서와 DNS 서버 주소 조회 문서에서 출력 의미를 확인할 수 있다.

VPN 프로필은 사내 이름에 적용할 DNS 규칙이나 접미사를 배포할 수 있다. 전체 이름은 되는데 짧은 이름만 실패한다면 접미사를, VPN 연결 전후에 답이 달라지면 DNS 정책을 살펴볼 단서가 된다. Microsoft의 VPN 이름 해석 문서는 NRPT와 DNS 접미사가 이 과정에 관여한다고 설명한다.

사내 DNS를 공용 DNS로 바꾸는 것을 첫 해결책으로 삼지 않는다. 내부 이름을 공용 DNS가 모르면 접속 문제는 그대로 남는다. 관리자가 사내 DNS 서버 주소를 알려 줬다면 그 서버를 지정해 비교할 수 있지만, 임의의 서버나 계정 설정을 입력하지 않는다.

2. 웹사이트가 사용하는 TCP 포트 확인

HTTPS 서비스라면 다음과 같이 443번 포트를 확인한다. 다른 포트를 쓰는 업무 시스템은 담당자가 알려 준 포트로 바꾼다.

Test-NetConnection -ComputerName portal.corp.example -Port 443 -InformationLevel Detailed

TcpTestSucceeded가 True면 해당 목적지의 TCP 포트까지 연결된 것이다. 앱 로그인, HTTP 응답, 인증서 정상 여부까지 검증한 것은 아니다. False면 경로·차단 정책·서버에서 포트를 받는지 등을 추가 확인한다. 자세한 출력의 RemoteAddress와 InterfaceAlias도 함께 기록한다. 출처: Test-NetConnection 문서.

DNS 실패와 네트워크 실패를 분리하려면 관리자가 확인해 준 서버 IP로 같은 포트를 한 번 더 검사한다.

Test-NetConnection -ComputerName 10.20.30.40 -Port 443

IP로는 성공하고 이름으로는 실패하면 이름 해석 결과가 중요한 단서다. 다만 이름에 여러 IP가 등록돼 있으면 서로 다른 서버를 검사한 것은 아닌지 비교해야 한다. 브라우저 주소를 IP로 바꿔 접속하는 방식은 인증서 이름이나 가상 호스트가 달라질 수 있으므로 같은 테스트로 취급하지 않는다. Ping이 막혀 있다는 이유만으로 웹 서비스까지 중단됐다고 판단해서도 안 된다.

3. 사내 IP로 가는 경로가 VPN에 있는지 확인

VPN에 접속했다고 모든 목적지가 자동으로 같은 경로를 쓰지는 않는다. 분할 터널은 지정한 대상만 VPN으로 보내고, 전체 터널은 기본 경로를 VPN 쪽으로 보낸다. 회사의 설계와 실제 적용 상태가 일치하는지가 핵심이다. 출처: Windows VPN 라우팅.

route print -4
Test-NetConnection -ComputerName 10.20.30.40 -DiagnoseRouting -InformationLevel Detailed

라우팅 진단에서 선택된 경로와 나가는 인터페이스를 본다. 이 진단은 경로 선택을 보여 주며 서버 포트에 실제 연결됐다는 보장은 아니다. 위의 TCP 검사와 함께 읽는다.

집과 회사가 같은 사설 대역을 쓰는 경우도 있다. 예를 들어 집 공유기의 로컬 네트워크와 접속하려는 사내 대역이 모두 192.168.0.0/24라면 의도하지 않은 인터페이스가 선택될 여지가 있다. 주소 모양이 비슷하다는 사실만으로 확정하지 말고 실제 선택 경로를 확인한다. 경로를 강제로 추가하거나 메트릭을 바꾸기 전에 관리자에게 두 대역과 진단 결과를 전달한다.

이 단계에서는 route add, VPN 분할 터널 변경, 방화벽 해제를 실행하지 않는다. 관리 정책을 바꾸면 당장 한 페이지가 열려도 다른 업무 트래픽이 예상과 다른 경로로 나갈 수 있다.

4. TCP는 성공하는데 브라우저만 실패할 때

이제 오류를 애플리케이션 쪽에서 나눠 본다. 401·403처럼 HTTP 상태가 보이면 응답을 보낸 서버나 프록시까지는 도달한 것이므로, 계정 권한과 접근 정책을 우선 확인한다. 인증서 경고라면 표시된 호스트 이름과 접속 주소가 같은지 기록한다. 경고를 무시하고 로그인 정보를 넣는 방식으로 해결하지 않는다.

특정 계정만 실패: 계정·그룹 권한, MFA 등록, 앱 접근 조건을 담당자에게 확인한다.
특정 PC만 실패: VPN 클라이언트 버전, 단말 등록 상태, 회사 프록시 설정 차이를 확인한다.
모든 사람이 같은 시각에 실패: 서버·인증 시스템·회사 네트워크의 공통 장애 가능성을 확인한다.

이 분류는 원인을 확정하는 규칙이 아니라 점검 우선순위다. 브라우저별 프록시나 보안 DNS 설정이 OS 조회와 다르게 동작할 수도 있으므로, PowerShell 결과와 브라우저 결과가 다르면 그 차이 자체를 문의에 포함한다.

관리자에게 보내면 도움이 되는 점검 기록

“VPN이 안 됩니다” 한 문장보다 아래 항목을 채운 기록이 원인 파악에 도움이 된다. 사내 주소와 네트워크 정보가 들어 있으므로 공개 게시판이 아닌 회사의 지정된 문의 경로로 전달한다.

기록 항목	작성 예시
발생 시각과 범위	오전 9시부터, 사내 포털만 실패, 외부 인터넷 정상
환경	Windows 버전, VPN 제품·버전, 집 Wi-Fi 사용
DNS 결과	전체 이름 조회 성공 여부와 응답 IP
TCP 결과	검사 대상·포트·TcpTestSucceeded
선택 경로	선택된 인터페이스와 경로, 집/회사 대역 중복 여부
화면 오류	이름 해석 실패·시간 초과·403·인증서 오류 중 무엇인지

설정을 수정한 뒤에는 같은 도메인·같은 포트·같은 업무 동작으로 다시 검사한다. TCP 성공만 보고 끝내지 말고 실제 로그인과 필요한 화면까지 열리는지 확인한다. 서버의 SSH 인증 자체가 문제인 경우에는 SSH 키 인증 설정 가이드처럼 인증 계층을 별도로 점검해야 한다.