VPN 이 연결된 상태에서 로컬 네트워크에 접속할 수 없다면? 네 가지 점검

터널이 올라오고 인트라넷이 보이는데 프린터가 응답을 멈춘다. LAN 에서 고장 난 것은 없고, 클라이언트가 더 이상 로컬로 취급하지 않는 주소에 쓰는 경로를 바꾼 것이다. 같은 증상에는 흔한 원인이 넷 있고 그중 VPN 설정을 고쳐 해결되는 것은 하나뿐이므로, 아래 네 가지 점검을 순서대로 진행하고 구체적인 불일치가 나오는 지점에서 멈춰라.

먼저 클라이언트가 넣은 라우팅 테이블을 본다

VPN 이 연결된 상태에서 클라이언트의 라우팅 테이블을 열어라. Linux 에서는 ip route, Windows 에서는 route print 또는 Get-NetRoute, macOS 에서는 netstat -rn 을 쓴다. 터널을 지나는 기본 경로와 물리적 기본 경로에 무슨 일이 생겼는지 확인하는 것이다.

전체 터널 클라이언트는 0.0.0.0/0 을 대체하는 대신 흔히 두 개의 반쪽 기본 경로 0.0.0.0/1 과 128.0.0.0/1 을 추가한다. 원래 기본 경로는 그대로 보이지만 모든 조회에서 지므로, 테이블은 멀쩡해 보이는데 서브넷 밖 트래픽만 전부 옮겨간다. VPN 클라이언트에 스플릿 터널 옵션이 있고 정책이 허용한다면 그것이 가장 깔끔한 수리다.

터널이 기본 경로로 남아야 한다면 대신 로컬 서브넷을 고정하라. Linux 에서는 경로가 물리 인터페이스와 게이트웨이를 지정하고, Windows 에서는 -p 를 붙여 영구적으로 만든 뒤 인터페이스 번호를 추측하지 말고 route print 에서 읽어라:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

고정 경로는 그것이 지정한 주소가 그대로인 동안만 유효하다. 접속할 때마다 Wi-Fi 어댑터 번호가 바뀌는 노트북에서는 규칙이 다시 깨지므로, 수리가 실패했다고 판단하기 전에 인터페이스 주소를 확인하라.

둘째, 그 주소가 애초에 로컬이었는지 확인한다

목적지가 연결된 서브넷 안에 있다면 터널의 기본 경로는 결코 적용되지 않으며 VPN 은 원인이 아니다. 192.168.1.0/24 인 클라이언트에서 192.168.1.40 프린터라면 연결 경로를 쓰므로, 그 주소가 안 되면 VPN 이 아니라 장치나 스위치, 클라이언트의 방화벽을 봐야 한다.

사람을 헷갈리게 하는 경우는 로컬 서버에 공인 주소를 준 때다. LAN 안에서 공유기의 WAN 주소로 나갔다 돌아오려면 헤어핀 NAT 가 필요하고, 많은 공유기는 포트 포워딩에 대해 그것을 아예 구현하지 않는다. 사설 주소를 공인 주소 옆에서 시험하라. 사설 주소는 되고 공인 주소가 안 된다면, VPN 은 원래 있던 NAT 한계를 드러낸 것뿐이다.

호스트 이름이 있으면 더 나빠진다. 로컬 이름이 이제 공인 주소로 해석되면 클라이언트는 되돌아올 수 없는 경로를 계속 시도한다. 시험에는 사설 주소를 쓰고, 포트 포워딩을 하나 더 추가하는 대신 이름을 고쳐라.

셋째, 이제 누가 이름에 답하는지 본다

기업용 리졸버는 인트라넷은 알지만 NAS 호스트 이름, 프린터의 Bonjour 이름, 공유기의 로컬 별칭은 보통 전혀 모른다. VPN 이 자기 DNS 서버를 밀어 넣으면 주소는 여전히 닿는데도 그 이름들이 해석되지 않는다. 이름을 직접 질의하고, 장치가 가지고 있다고 아는 주소와 답을 비교하라.

Linux 에서는 resolvectl query nas.local 이 어느 리졸버가 답했는지 보여 준다. Windows 에서는 nslookup nas.local 이 서버를 밝히고 ipconfig /all 이 리졸버 순서를 보여 준다. 로컬 접미사를 이제 기업용 리졸버가 맡는다면 그 접미사를 로컬 리졸버로 되돌리거나 장치에는 IP 주소를 써라.

발견은 별개의 계층이다. mDNS 와 브로드캐스트는 라우팅되는 터널을 넘지 않으므로 장치는 주소로 닿아도 이름은 보이지 않을 수 있다. 리플렉터나 로컬 DNS 항목이 그것을 해결하고, 경로는 해결하지 못한다.

넷째, 상대 머신도 VPN 에 있는지 확인한다

접속하려는 머신도 VPN 클라이언트를 돌리고 있다면 세션은 도착하는데 응답이 다른 터널로 나갈 수 있다. 그러면 연결이 맺어진 뒤 멈추거나, RDP 와 SSH 시도가 이쪽에 오류도 없이 시간 초과된다. 내 클라이언트를 탓하기 전에 상대 호스트의 라우팅 테이블과 기본 경로를 확인하라.

서비스가 어느 주소에서 듣는지도 확인하라. 터널 주소에만 묶인 리스너는 VPN 에서 오는 연결은 받고 LAN 에서 오는 연결은 거부하며, 라우팅이 완벽해도 그렇다. 이것은 네트워크 경로가 아니라 서비스 설정이며, VPN 주소로 잠근 관리 인터페이스에서 흔하다.

터널에 의존하지 않는 관리 경로, 곧 원본 네트워크를 지정한 정적 경로나 LAN 에 붙은 다른 인터페이스, 터널을 완전히 우회하는 콘솔을 유지하라. 세션이 끊긴 뒤에 그 경로를 설계하는 것은 다음 접속 전에 미리 넣는 것보다 훨씬 어렵다.

실패한 점검에 맞는 수리를 적용한다

라우팅 테이블에 반쪽 기본 경로 탈취가 보였다면 정책이 허용할 때는 스플릿 터널을, 허용하지 않을 때는 고정 로컬 경로를 고른다. 주소가 공인으로 밝혀졌다면 시험과 이름을 사설 주소로 바꾼다. 리졸버가 주인이 바뀌었다면 로컬 접미사로 한정하거나 주소를 쓴다. 상대 호스트가 터널 안이라면 그 반환 경로나 리스너 바인딩을 고친다.

한 가지만 바꾸고 같은 점검을 다시 하라. 잘못된 서브넷에 넣은 경로, 오타가 있는 리졸버 접미사, 번호가 바뀌는 인터페이스에 고정한 경로는 모두 원래 고장처럼 보인다. 수리와 우연을 가르는 것은 반복이다.

VPN 이 연결된 상태에서 통했던 경로와 주소, 리졸버를 적어 두라. 다음 재접속은 그중 최소 하나를 바꿀 것이고, 이 메모는 다음 장애를 새 조사가 아니라 짧은 비교로 바꿔 준다.