SMB 공유가 VPN에서만 실패할 때: 서명 문제인가, 서브넷 충돌인가?

사무실에서는 되는데 집에서 시간 초과가 나는 매핑 드라이브는 그 자체로는 거의 쓸모 있는 정보를 주지 않는다. 터널이 패킷을 나르고 있는 것은 분명하다. 그렇지 않으면 서버에 아무것도 닿지 않았을 것이다. 실패한 것은 세 계층 중 하나다. 이름이 잘못된 주소로 확인되었거나, 클라이언트가 세션 서명을 거부했거나, 오래된 세션이 그 세션을 실어 나른 연결보다 오래 살아남았다. 각각 고치는 방법이 다르고, 셋 중 둘은 클라이언트 쪽에 있다.

세 가지 고장이 같은 오류를 입는다

드라이브 문자는 어느 계층이 깨졌는지 알려 주지 않고, 오류 문구는 대개 셋 모두에 들어맞을 만큼 일반적이다. 두 가지 빠른 질문으로 나눈다. 서버가 자기 IP 주소에서 응답하는가, 445 포트가 연결을 받아 주는가?

그 답은 추측이 아니라 판단 표가 된다. IP는 되고 이름이 안 되면 이름 확인을 가리킨다. 둘 다 되는데 로그온이 거부되면 서명을 가리킨다. 둘 다 되는데 터널이 끊긴 뒤 파일 읽기가 멈추면 오래된 세션을 가리킨다.

그 순서대로 짚어 나가야 한다. 잘못된 호스트로 확인되는 이름은 이후의 모든 시험을 무의미하게 만들기 때문이다.

공유를 건드리기 전에 이름을 확인한다

서버가 자기 주소에서 응답하는데 공유 이름이 시간 초과가 나면 터널은 제 일을 하고 있고 클라이언트가 엉뚱한 곳을 보고 있다. 원격 접속에서는 대개 두 가지 원인이 이 대부분을 설명한다.

첫째는 주소 겹침이다. 사무실이 192.168.70.0/24를 쓰고 집 라우터가 같은 범위를 나눠 주면, 192.168.70.20으로 확인되는 호스트 이름이 터널 건너편 서버가 아니라 로컬 장치를 가리킬 수 있다. 그러면 Windows는 요청을 로컬로 보내거나, 경로를 거부하거나, 마침 그 주소를 가진 프린터로 확인해 버릴 수 있다. 고치는 방법은 한쪽 번호를 다시 매기는 것이지 경로를 하나 더 넣는 것이 아니다.

둘째는 DNS 범위다. 내부 DNS 서버가 없거나 터널로 닿을 수 없는 DNS 서버를 쓰는 VPN 어댑터는 짧은 이름을 공용 해석기로 흘려보낸다. 공유를 건드리기 전에 어댑터의 DNS 항목을 읽고 내부 이름을 직접 질의한다:

> ipconfig /all | findstr /i "DNS Servers"
> nslookup files.corp.internal
Server: 10.90.0.2
Address: 10.90.0.2
Name: files.corp.internal
Address: 10.90.0.15

그 질의가 기대한 주소를 돌려주면 이름 확인은 정리된 것이고 문제는 스택 위쪽에 있다.

양쪽 끝에서 서명 요구를 읽는다

닿기는 하는데 모든 로그온을 거부하는 서버는 네트워크 고장이 아니라 정책 불일치의 표시다. Windows는 클라이언트에 SMB 서명을 요구할 수 있고, 서명하지 않는 서버나 NAS는 터널이 아무리 건강해도 세션을 끝낼 수 없다.

정책 편집기를 뒤지지 않고도 클라이언트 설정을 읽을 수 있다:

> Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
RequireSecuritySignature
-------------------------
True
> Get-SmbConnection

서버 쪽 대응 값은 서버의 SMB 구성에 있고, 둘은 서로 맞아야 한다. 보고된 한 사례에서는 클라이언트가 로컬 정책으로 요구를 켜 두었는데 서버는 아예 서명하지 않았다. 그 요구를 끄고 gpupdate /force을(를) 실행하자 공유가 곧바로 되살아났다. 이것은 원인을 확인하는 진단 단계이지 영구적인 수정이 아니다.

서버가 지원하는 곳에서는 양쪽 끝에서 서명을 켜는 편을 택한다. 공유가 되게 하려고 보안 설정을 바꾼다면 이전 값과 이유를 함께 기록해, 다음 감사에서 누구도 그것을 다시 발견하지 않게 해야 한다.

타이머를 만지기 전에 오래된 세션을 지운다

VPN이 끊겼다가 다시 붙은 뒤에만 멈추는 공유는 대개 서버가 이미 버린 세션을 붙들고 있다. 서버는 LanmanServer\Parameters 아래의 Autodisconnect 타이머에 따라 유휴 SMB 세션을 닫는데 기본값은 15분이고, 클라이언트는 LanmanWorkstation\Parameters 아래에 자기 SessTimeout을 따로 둔다. 그 값보다 긴 단절은 양쪽 끝에 세션에 대한 서로 다른 생각을 남긴다.

결과가 의미를 가지려면 정해진 순서로 재현한다. 터널을 연결하고, 공유를 열고, 터널을 잠시 끊고, 되살린 다음 파일을 읽어 본다. 마운트가 스스로 회복되면 타이머는 건드리지 않는다. 다시 마운트할 때까지 멈춰 있으면 터널이 올라온 뒤 공유를 다시 연결한다. 터널이 생기기 전에 마운트하는 대신에, 그리고 마운트 도우미가 재시도하는지도 확인한다.

불안정한 회선에서는 시간 제한을 늘리는 것이 합당한 마지막 수단이지만, 그것은 증상만 다스린다. 서버가 잊은 세션을 더 오래 기다리는 클라이언트는 여전히 기다리고 있다.

마지막으로 마운트를 통해 파일 하나를 읽고, 터널을 한 번 더 끊었다가 되살린다. 그 인수 시험은 세 계층을 한 번에 덮고, 사용자가 실제로 하는 일과 맞는 유일한 시험이다.