VPN을 통한 SMB 게스트 로그온: Windows는 여전히 ID를 요구한다

사무실 VPN에 연결하면 파일 서버에 닿기는 하지만 공유가 계속 접근을 거부하므로 터널이 고장 났다는 결론으로 이끌린다. 대개 그렇지 않다. SMB는 세션마다 따로 인증하며, Windows는 익명 로그온으로 무엇을 받아들일지 계속 엄격하게 만들어 왔다. 네트워크 경로와 사용자 ID는 서로 다른 요구 사항이다, 그리고 오류가 말하는 것은 두 번째다.

터널이 SMB ID를 대신할 수 없는 이유

서버와 서브넷을 공유해도 그 파일을 읽을 권한이 생기는 것은 아니며, 라우팅 문제만 없어진다. 클라이언트가 안전하지 않은 게스트 로그온을 차단하면 Windows는 이벤트 31017을 기록하는데, 이는 서버가 아니라 사용자 PC에서 내려진 결정이다. 터널은 SMB 패킷을 충실히 옮기지만 게스트 세션은 거부된다. 같은 홈 네트워크에서 한 노트북은 되고 다른 노트북은 안 되는 이유가 여기에 있다.

이벤트를 네트워크 결함이 아니라 정책의 증거로 다루어야 한다. 해결책은 ID나 장치 쪽에 있다.

클라이언트 정책과 거부 이벤트를 읽는다

두 가지 출력, 즉 유효한 클라이언트 구성과 최근 거부 이벤트가 문제를 빠르게 정리한다.

Get-SmbClientConfiguration | Select-Object EnableInsecureGuestLogons, RequireSecuritySignature
Get-WinEvent -LogName Microsoft-Windows-SmbClient/Operational -MaxEvents 20 | Where-Object Id -eq 31017

잘못된 게스트 설정과 서명 요구가 겹치면 더 조사하기 전에 실패가 설명되며, 이벤트 로그는 서버가 자격 증명을 거부한 것이 아니라 클라이언트가 세션을 거부했음을 확인해 준다. 다른 PC에서 성공한 시도에 쓴 공유 경로와 계정을 적어 두어라. 캐시된 세션 때문에 같은 것이 아닌 두 시험이 같아 보일 수 있다. 비교 전에 기존 연결을 net use 로 지워 새 세션 대신 옛 세션이 응답하지 않게 한다.

이름 있는 계정을 쓰고 서명은 유지한다

오래 가는 해결책은 서버가 아는 계정을 명시적으로 제공하는 것이며, 서명과 암호화 정책은 그대로 둔다. 대화 상자에 아무 이름이나 입력하는 대신 연결에서 자격 증명을 준다.

net use \\fileserver.example\share /user:DOMAIN\alice *
Get-SmbConnection

이름 있는 로그온은 서버가 감사할 수 있는 세션을 만들고, Get-SmbConnection 는 다이얼렉트와 서명이 활성인지 보여 준다. 게스트 세션은 서명이나 암호화 요구를 만족할 수 없으므로 게스트 플래그를 켜도 그 요구를 강제하는 정책을 구제할 수 없다. 구형 장치에 계정 모델이 없다면 게스트 접근을 교체 계획이 있는 명시적인 문서화된 예외로 다루어야 한다. 장치 하나에 맞추려고 모든 연결에서 서명을 약화시키지 마라.

장치가 게스트만 아는 경우

일부 소비자용 NAS는 계정 개념이 없는 공유를 노출하며, 이는 장치를 격리하거나 교체하는 두 가지 정직한 선택을 남긴다. 민감한 것에 이르는 경로가 없는 세그먼트에 두고, 편의를 위한 예외가 클라이언트 전체의 기본값이 되지 않게 하라. 백업이나 자격 증명이 담긴 게스트 공유는 Windows의 불편이 아니라 데이터 노출 문제다. 펌웨어 업데이트가 사용자 계정을 추가한다면 그것이 더 저렴한 장기 답이다.

받아들인 계정과 정책 값을 티켓에 기록한다. 그렇지 않으면 다음 사람이 터널 시험을 다시 돌리고 같은 거부에 도달한다.