VPN을 통한 NAS 접속 불가: 주소, 반환 경로, 아니면 서비스?
사설 터널에는 NAS로 가는 경로, 응답 경로, 허용된 서비스가 필요합니다. 자격 증명을 바꾸기 전에 세 가지 중 무엇이 실패했는지 판단하세요.
터널은 올라오고 클라이언트는 주소를 받는데 NAS는 아무 응답도 하지 않습니다. 이 하나의 증상은 서로 무관한 세 가지 고장을 덮고 있으며, 어떤 순서로 시험하느냐가 복구 시간을 결정합니다. 주소 지정이 먼저입니다. 겹치는 서브넷이 요청을 엉뚱한 장치로 보낼 수 있기 때문입니다. 반환 경로가 두 번째입니다. 응답 없이 도착한 요청은 닫힌 서비스와 똑같이 보이기 때문입니다. 서비스와 권한은 마지막이며, 앞의 두 가지가 증명된 뒤에만 확인합니다.
모두 도달 불가로 읽히는 세 가지 고장
주소 선택, 반환 라우팅, 서비스 권한 부여는 모두 같은 사용자 메시지를 만듭니다. 아무 일도 일어나지 않는다는 메시지입니다. 증거도 담당자도 해결책도 다르므로 이들을 분리하는 것이 작업의 전부입니다. 실패한 ping만으로는 증명할 수 있는 것이 거의 없고, TCP 거부가 돌아오는 것은 오히려 좋은 소식입니다.
| Observation | Most likely conclusion |
|---|---|
| Route to the NAS address leaves the wrong interface | Overlapping or missing private route |
| Request visible on the server, no reply seen | Return path, gateway forwarding or translation |
| TCP connection refused rather than dropped | Reachable host, service not listening or filtered |
| TCP works, login or file access fails | Share permission, account or protocol version |
표를 원인 목록이 아니라 시험 순서로 읽으세요. 거부가 돌아왔다면 주소 지정과 반환 경로는 이미 동작이 증명된 것이므로 각 행은 다음 행을 제한합니다. 경로가 어느 인터페이스를 골랐는지 확인하기 전에 방화벽 규칙 안에서 이십 분을 보내는 것이 오후를 잃는 가장 흔한 방법입니다. 위에서 아래로 진행하고 처음 일치하는 행에서 멈추세요.
조건 하나: 그 주소가 올바른 장치인가?
NAS 서브넷과 VPN이 클라이언트에 주는 범위를 적고, 둘 다 지금 노트북이 연결된 네트워크와 비교하세요. 이 절차에서 NAS는 10.40.7.25에 있고 VPN 풀은 10.40.9.0/24입니다. 하나의 사이트 계획 안에 있는 별개의 사설 범위이며, 192.168.0.0/24나 10.0.0.0/24를 쓰는 가정은 둘 중 하나와 충돌할 가능성이 훨씬 높습니다.
로컬 네트워크와 NAS 네트워크가 겹치면 클라이언트는 그 트래픽을 자기 게이트웨이로 보내고, 우연히 같은 주소를 가진 무관한 장치에 도달할 수 있습니다. 응답하는 무엇이든 자격 증명을 입력하기 전에 경로를 확인하세요.
ip -4 route get 10.40.7.25
traceroute -n -m 5 10.40.7.25첫 번째 명령은 커널이 사용할 인터페이스와 게이트웨이를 알려 주고, 두 번째는 실제로 응답하는 첫 홉을 보여 줍니다. 둘이 어긋나면 경로 조회를 믿으세요. 패킷은 그 길로 가기 때문입니다. NAS 한 홉 앞에서 멈추는 홉 목록도 실패가 아니라 발견입니다. 터널이 아니라 물리 어댑터로 해석된다면 그 지점에서 조사는 끝납니다.
조건 둘: 응답이 돌아오는가?
클라이언트에는 NAS로 가는 경로가 필요하고, NAS 네트워크에는 VPN 풀로 가는 반환 경로가 필요합니다. 게이트웨이 전달, 방화벽 규칙, 의도적인 주소 변환은 각각 이 쌍에 영향을 줍니다. strongSwan의 전달 관련 노트는 게이트웨이 뒤의 사설 서브넷에 대한 반환 경로와 변환 선택지를 설명합니다.
요청이 도착하고 응답이 다른 게이트웨이로 나가면 어떤 DNS 변경도 그 비대칭을 고치지 못합니다. 양쪽에서의 캡처가 한 번에 판정하며, 변환이 NAS가 응답한 출발지를 다시 썼는지도 보여 줍니다. 관리자는 그 경계의 책임자입니다. 필요한 서비스와 VPN 클라이언트 범위만 허용하고, 라우팅과 변환 중 무엇을 골랐는지 기록하세요.
조건 셋: 서비스가 있고 허용되어 있는가?
관리 페이지와 파일 공유 서비스는 같은 기기의 다른 종단이며, 한쪽이 연결을 받아들이는 동안 다른 쪽은 호스트 방화벽, 서비스 설정, 공유 권한 때문에 막혀 있을 수 있습니다. 거부로 응답하는 장치는 이미 첫 두 조건을 증명한 것이므로 세 번째는 크게 좁혀집니다.
설치할 때 쓴 관리자 계정이 아니라 실제로 파일이 필요한 계정으로 시험하세요. 관리자 권한은 빠진 경로를 고칠 수 없고, 경로는 공유 권한을 줄 수 없습니다. 이름도 여기에 포함되며, 집에서 발견되는 NAS 이름은 흔히 로컬 멀티캐스트에 의존하고 라우팅된 터널은 그것을 나르지 않으므로 공급자가 문서화한 사설 호스트 이름이나 주소 자체를 시도해 이름 해석과 접근을 분리하세요.
NAS 네트워크 바깥에서 시험하고, 그다음 조금씩 넓히세요
같은 LAN에서 하는 시험은 원격 경로의 불완전한 부분을 모두 감춥니다. 그래서 처음 성공한 원격 시도는 변경 기록에 남길 가치가 있습니다. NAS에 터널로만 닿는 클라이언트에서 점검을 실행하고, 각 시도의 원래 오류 텍스트를 보관하세요.
nc -vz 10.40.7.25 445
smbclient -L 10.40.7.25 -U guest경로가 동작하면 무해한 파일을 전송하고 실제로 필요한 읽기나 쓰기 동작을 확인하세요. 큰 전송이 멈추고 작은 전송이 통과한다면 남은 문제는 패킷 크기 처리나 연결 안정성이며 주소 지정이 아닙니다.
설명되지 않는 고장을 피하려고 파일 공유나 관리 포트를 인터넷에 공개하지 마세요. 사설 경로를 고치고, NAS 소프트웨어를 지원되는 상태로 유지하고, 그 백업에 의존하기 전에 그것을 통해 뜬 백업의 복원을 시험하세요.