회사 VPN 연결 후 사내 사이트 접속이 안 되면, 전체 주소부터 조회해요
회사 VPN 연결 후 사내 사이트 접속이 안 되면 Windows에서 회사가 안내한 전체 주소의 이름 조회부터 확인해요. 짧은 이름만 실패하는지, 전체 이름도 실패하는지, 조회는 되는데 웹페이지만 안 열리는지를 나누면 설정을 바꾸기 전에 다음 확인 대상을 좁힐 수 있어요.
VPN 앱이 연결 완료 상태인 회사 노트북을 기준으로 설명해요. DNS는 사이트 이름에 맞는 IP 주소를 찾는 과정이에요. 이름을 찾았다고 그곳의 웹페이지까지 정상으로 열리는 것은 아니므로 두 결과를 따로 남기는 게 중요해요.
VPN은 연결됐는데 무엇부터 확인하나요?
회사 안내에 적힌 전체 주소와 현재 오류 문구를 먼저 확인해요. 그다음 VPN 연결을 유지한 채 DNS 서버와 주소 뒤에 붙는 도메인인 DNS 접미사를 읽어보세요.
화면 캡처: learn.microsoft.com 원문
예를 들어 전자결재를 열려는데 즐겨찾기의 짧은 주소만 실패하는 상황을 생각해 볼 수 있어요. 회사 안내에 더 긴 전체 주소가 있다면 그 주소와 비교할 수 있죠. 기억으로 회사 도메인을 덧붙이지 말고 안내문이나 담당자가 제공한 주소를 사용하세요.
Windows 검색에서 명령 프롬프트를 열고 다음 조회 명령을 입력해요. 회사 정책으로 실행이 막히면 그 사실을 담당자에게 전달하면 됩니다.
ipconfig /all
- 어댑터 이름: 어느 연결 아래 나온 값인지 함께 적어요.
- DNS 서버: 표시된 주소를 순서대로 기록해요. 여러 개라면 첫 주소만 남기지 마세요.
- 연결별 DNS 접미사·DNS 접미사 검색 목록: 표시된 값이나 비어 있는 상태를 기록해요.
값이 맞는지는 회사 배포 기준과 대조해야 해요. Microsoft의 DNS 클라이언트 확인 절차도 서버 주소와 연결별 접미사를 확인하도록 안내해요. 다만 Azure VPN Client에는 이 출력에 회사 DNS가 보이지 않는 예외가 있어요.
VPN이 아직 연결 중이거나 인증에 실패했다면 공용 와이파이 인증과 VPN 연결부터 나눠 확인하기가 먼저예요. 일반 웹사이트까지 전혀 안 열린다면 와이파이 연결과 인터넷 사용 가능 여부를 나눠 확인하기도 함께 참고하세요.
짧은 이름과 전체 이름의 결과가 다른가요?
전체 이름은 조회되는데 짧은 이름만 실패하면 접미사를 확인할 단서가 돼요. 전체 이름도 실패하면 오류 문구와 조회에 사용된 DNS 서버를 기록하세요. 어느 경우든 결과 하나로 원인을 확정하지는 않아요.
화면 캡처: learn.microsoft.com 원문
아래의 app1과 app1.corp.contoso.com은 설명용 예시예요. 회사가 안내한 사내 사이트 이름으로 바꿔 한 줄씩 실행하세요. 조회 명령에는 https://나 뒤쪽의 /login 같은 경로를 넣지 않아요.
nslookup app1
nslookup app1.corp.contoso.com.
nslookup bing.com
둘째 줄 끝의 점은 전체 이름을 명확히 지정하기 위한 표기예요. 셋째 줄은 외부 이름 비교용이며 회사에서 허용한 외부 도메인을 써도 돼요. 내부 이름은 회사 PC의 조회 도구에서 확인하고 공개 DNS 검사 사이트에 입력하지 마세요.
출력 위쪽의 Server와 Address는 질문을 받은 DNS 서버예요. 아래쪽 답변에 나오는 대상 이름과 주소를 구분해서 읽으세요.
- 짧은 이름만 실패: 조회가 성공한 전체 이름과 실패한 짧은 이름을 함께 전달해요. 접미사 누락이나 검색 순서를 확인할 자료가 됩니다.
- 내부 이름은 실패하고 외부 이름은 성공: 내부 이름을 처리하는 DNS 설정·정책·경로·레코드를 확인할 단서예요. 외부 조회 성공만으로 사내 DNS까지 정상이라고 볼 수는 없어요.
- 시간 초과: 응답을 받지 못한 상태예요. DNS 서버에 닿지 못하거나 중간에서 통신이 막힌 경우 등을 관리자가 구별해야 해요.
- 존재하지 않는 이름이라는 응답: 입력한 이름과 응답한 서버를 확인해요. 다른 DNS에 물었을 가능성이 있으므로 사내 사이트가 삭제됐다고 단정하지 마세요.
- 대상 IP 주소가 나옴: 그 조회에서 주소를 받았다는 의미예요. 올바른 회사 주소인지는 별도 대조가 필요하고 웹페이지 접속 성공까지 입증하지는 않아요.
결과가 실제 웹 접속 상태와 맞지 않으면 Windows PowerShell에서 같은 전체 이름도 조회해 보세요.
Resolve-DnsName app1.corp.contoso.com.
Microsoft는 여러 DNS 서버 중 일부가 응답하지 않는 사례에서 nslookup과 Windows 이름 조회의 결과가 달라질 수 있다고 설명해요. 두 명령의 결과가 다르면 둘 다 남기세요. 캐시나 Hosts 파일 같은 로컬 정보도 조회에 영향을 줄 수 있어요. 근거는 Windows Client 이름 조회 문제 안내에서 확인할 수 있어요.
Azure VPN이나 웹 포털 방식이면 확인 대상이 달라요
VPN 제품과 접속 방식에 따라 DNS 정보를 볼 곳이 달라져요. Azure VPN Client의 특정 인증 방식은 Windows 정책을, FortiGate 웹 모드는 VPN 장비 쪽 조회를 확인해야 해요.
화면 캡처: learn.microsoft.com 원문
Azure VPN Client에서 회사 DNS가 안 보일 때
Microsoft Entra ID 인증을 사용하는 Azure VPN Client는 이름별 조회 규칙인 NRPT를 사용해요. 이 경우 회사 DNS 서버가 ipconfig /all 출력에 표시되지 않을 수 있어요. 표시가 없다는 이유만으로 DNS 배포 실패로 판단하지 마세요.
해당 환경이라면 VPN 연결 상태에서 PowerShell로 다음 정책을 조회해요. 결과를 직접 수정하지 말고 회사 도메인과 DNS 서버에 해당하는 항목을 담당자에게 전달하세요.
Get-DnsClientNrptPolicy
인증 방식을 모르거나 명령이 차단되면 VPN 앱 이름과 오류를 남기면 돼요. 이 예외는 Azure VPN Client의 선택적 DNS 설정 안내에 나온 조건이며 다른 제품에 그대로 적용하지 않아요.
FortiGate 웹 포털의 링크만 안 열릴 때
FortiGate SSL VPN은 터널 모드와 웹 모드의 확인 대상이 달라요. 터널 모드는 사용자에게 배포하는 내부 DNS를 확인하지만 웹 모드는 FortiGate가 대신 목적지에 접속하면서 이름을 조회해요. 내 PC에서 조회가 된다는 사실만으로 웹 포털 쪽 조회까지 정상이라고 판단할 수 없어요.
담당자에게 앱으로 터널을 연결한 것인지, 웹 포털 안의 링크를 누른 것인지 알려주세요. 각각 터널 모드의 내부 DNS 안내와 웹 모드의 FortiGate DNS 안내가 해당해요. 장비 설정과 버전별 적용 여부는 관리자가 확인할 항목이에요.
DNS 캐시는 바로 지워도 되나요?
먼저 기록하고 필요할 때만 지우세요. 캐시는 이전에 조회한 답을 잠시 보관한 것으로, 조회와 초기화는 다른 행동이에요.
현재 캐시는 다음 명령으로 읽을 수 있어요.
ipconfig /displaydns
nslookup은 PC의 DNS 캐시를 사용하지 않아요. 서버 조회는 성공하는데 캐시에 해당 이름이 없다는 이전 응답이 남아 있다면 초기화를 검토할 수 있어요. Microsoft의 캐시 확인·초기화 안내도 이런 상황을 설명해요.
ipconfig /flushdns는 캐시를 지우는 변경 명령이에요. 읽기 전용 확인을 마친 뒤 회사 지원 안내에 따라 실행 여부를 정하세요. 실행했다면 같은 전체 주소를 다시 조회하고 원래 열려던 사내 페이지도 재확인해요.
캐시 초기화로 회사 DNS 배포나 VPN 경로가 고쳐지는 것은 아니에요. 조회가 계속 실패하면 반복 초기화보다 기존 결과를 전달하는 편이 낫습니다. 공용 DNS로 강제 변경하거나 Hosts 파일을 고치고 보안 프로그램을 끄는 조치는 이 확인 순서에 포함하지 않아요.
관리자에게는 무엇을 보내면 되나요?
“VPN은 연결되지만 사이트가 안 열려요”에 발생 시각, 접속 방식, 이름 조회 결과, 웹 오류를 붙여 보내세요. 실제로 확인한 칸만 채우고 모르는 항목은 미확인으로 남기면 됩니다.
- 발생 시각·환경: 날짜와 시각, 집 와이파이·공용 와이파이·유선 등 현재 연결 환경
- VPN 상태: 앱 이름과 확인 가능한 버전, 연결 완료 표시, 터널 접속인지 웹 포털 이용인지
- 대상: 회사가 안내한 전체 주소와 실패한 짧은 이름
- DNS 정보: 어댑터 이름, DNS 서버·접미사, 해당하는 경우 NRPT 조회 결과
- 조회 결과: 실행한 명령, 반환 주소 또는 오류 문구, 내부·외부 이름의 차이
- 웹 접속 결과: 사용 브라우저와 화면의 정확한 오류, 특정 사내 사이트만 실패하는지 여부
- 변경 여부: 설정을 바꾸지 않았는지, 회사 안내로 캐시 초기화를 했다면 전후 결과가 어떻게 달랐는지
내부 주소와 단말 정보가 담긴 출력은 회사가 지정한 지원 창구로 전달하세요. 전체 출력을 공개 게시판에 올릴 필요는 없어요.
조회가 성공했는데 웹사이트가 계속 안 열리면 담당자에게 반환 주소가 맞는지와 접속 경로·웹서비스·권한을 확인해 달라고 요청해요. Microsoft의 Azure P2S 문제 해결 문서도 내부 이름 조회 문제와 연결 후 경로 수신 문제를 따로 다뤄요. 이 사례를 모든 VPN의 같은 원인으로 보지는 마세요.
이미 ping을 해봤다면 결과를 보조 자료로 남길 수 있어요. 다만 회사에서 ICMP 응답을 막을 수 있어 ping 실패만으로 DNS 서버 장애를 확정할 수는 없어요. 조치 뒤에는 같은 전체 주소로 원래 업무 페이지가 열리는지까지 확인하세요.
공식 출처
확인한 기준: 2026년 9월 23일. Microsoft Learn과 Fortinet 직원 작성 기술 문서에서 조회 명령, 결과 해석의 한계, 제품별 DNS 처리 차이를 대조했어요. 회사 단말에서 직접 장애를 재현하거나 복구한 사용기는 아니에요.
- Microsoft: DNS 클라이언트 확인 절차 — Windows Server 문서의 DNS 서버·접미사·캐시 확인 항목
- Microsoft: Windows Client 이름 조회 문제 — 서버 도달 실패, 로컬 정보, 조회 도구의 차이
- Microsoft: Azure VPN Client DNS·경로 설정 — Entra ID 인증의 NRPT 예외
- Microsoft: Azure P2S 연결 문제 — 연결 후 이름 조회와 경로 문제 구별
- Fortinet: SSL VPN 터널 모드의 내부 DNS — 관리자 측 DNS 배포 확인
- Fortinet: SSL VPN 웹 모드의 내부 DNS — FortiGate가 목적지 이름을 조회하는 구조
Windows 조회 절차를 기준으로 하며 macOS·스마트폰의 설정 경로에는 그대로 적용하지 않아요. 회사별 정상 DNS 주소와 VPN 정책은 담당자가 확인해야 합니다.
댓글
댓글 쓰기
질문은 자유롭게 남겨주세요. 광고성 댓글, 비방, 개인정보가 포함된 댓글은 삭제될 수 있습니다.