작동 중인 분할 터널 경로는 그대로 두고 가장 구체적인 양방향 경로를 추가하여 누락된 NAS 서브넷을 복원하세요.
가정용 VPN에서는 터널이 연결되어 있고 다른 사설 서브넷은 접근 가능하지만 한 NAS 네트워크가 사라질 수 있습니다. 일반적인 원인은 NAS 서비스 자체가 아니라 누락된 경로, 더 넓은 로컬 경로가 우선하는 경우, 중복된 가정용 네트워크 접두사, 잘못된 터널 게이트웨이, 또는 VPN 클라이언트에 도달하는 방법을 모르는 반환 경로입니다. 가장 안전한 해결책은 작동하는 서브넷과 숨겨진 서브넷을 비교하고 한 번에 하나씩 경로 결정을 수정하며 터널을 확장하기 전에 순방향 및 반환 트래픽을 모두 확인하는 것입니다.
누락된 NAS 서브넷이 하나뿐임을 증명하기
VPN에 연결한 후 VPN 게이트웨이, 작동하는 알려진 사설 서브넷 하나, 실패하는 NAS 서브넷 세 곳을 각각 테스트하세요. DNS, SMB 검색, 호스트 이름이 라우팅 결과를 흐리지 않도록 먼저 직접 IP 주소를 사용하세요.
분할 터널링은 선택된 목적지 접두사만 VPN을 통해 보내고 다른 트래픽은 클라이언트의 일반 기본 경로를 따릅니다. 서브넷별 분할 경로에 대한 실용적인 설명은 클라이언트가 VPN 네트워크 자체는 도달 가능하다고 여기면서 인접한 사설 서브넷을 잘못된 게이트웨이로 보낼 수 있음을 보여줍니다.
VPN 게이트웨이와 다른 원격 서브넷이 작동한다면 터널과 인증은 이미 설정된 상태입니다. 전체 VPN 구성을 다시 구축하기보다는 누락된 NAS 접두사, 경로 우선순위, 방화벽 정책, 반환 경로에 진단을 집중하세요.
작동하는 주소와 실패하는 주소에 선택된 경로 비교하기
터널 연결 후 클라이언트 경로 테이블을 확인하고 작동하는 원격 주소 하나와 NAS 주소 하나에 대해 선택된 경로를 조회하세요. 각 경로의 목적지 접두사, 접두사 길이, 메트릭, 인터페이스, 다음 홉을 기록하세요.
존재하는 경로가 반드시 우선하는 경로는 아닙니다. 운영 체제는 일반적으로 가장 긴 일치 접두사를 선호하므로 로컬 192.168.1.0/24 경로가 192.168.0.0/16 같은 더 넓은 VPN 경로를 겹치는 정확한 주소에 대해 무시할 수 있습니다.
NAS 주소가 로컬 Wi-Fi 또는 이더넷 게이트웨이를 따른다면 NAS 서브넷에 대해 더 구체적인 VPN 경로를 추가하거나 광고하세요. 이미 터널을 따른다면 중복 클라이언트 경로를 추가하기보다는 VPN 정책, 원격 전달, 반환 라우팅을 계속 점검하세요.
클라이언트 네트워크와 NAS 네트워크 간 중복 제거하기
원격 클라이언트의 현재 위치에서 사용하는 사설 서브넷과 가정용 VPN 뒤의 사설 서브넷을 비교하세요. 호텔, 사무실, 모바일 핫스팟, 다른 가정에서는 흔히 192.168.0.0/24 또는 192.168.1.0/24 같은 공통 범위를 재사용합니다.
현재 GlobalProtect 토론에서는 넓은 분할 경로가 클라이언트의 로컬 사설 네트워크와 충돌하는 사례를 설명합니다. 클라이언트는 NAS 주소가 가까운 Wi-Fi에 있다고 생각하여 패킷을 VPN에 넣지 않을 수 있습니다.
가장 깔끔한 장기 해결책은 가정용 NAS VLAN 또는 원격 LAN을 덜 일반적인 접두사로 재번호 지정하는 것입니다. 재번호 지정이 불가능할 경우, 변환된 VPN 서브넷, 호스트별 경로, 애플리케이션 프록시, 또는 중복 문제를 명확히 해결하는 VPN 설계를 사용하세요. 모호한 사설 주소에 의존하지 마십시오.
분할 터널 접두사와 게이트웨이 수정하기
서버 측 포함 경로나 허용된 서브넷 목록을 검토하여 정확한 NAS 네트워크와 올바른 마스크가 포함되어 있는지 확인하세요. /25 대신 /24 같은 오타는 의도한 주소의 절반만 숨길 수 있습니다.
Cisco VPN 사례에서는 VPN 주소 풀 자체는 올바른데도 잘못된 경로 게이트웨이로 설치된 분할 경로가 발견되었습니다. 이 때문에 구성된 경로 라벨보다 실제 클라이언트 경로가 더 중요합니다.
오래되거나 중복된 경로를 제거하고 VPN을 재연결한 후 NAS 접두사에 대해 권위 있는 경로가 하나만 나타나는지 확인하세요. 전체 터널링이 의도된 설계가 아니라면 터널을 통한 기본 경로는 추가하지 마십시오. 하나의 서브넷 수정이 모든 인터넷 트래픽을 조용히 리디렉션해서는 안 됩니다.
포워딩, 방화벽, 반환 경로 확인하기
클라이언트가 NAS 주소에 핑을 보내는 동안 VPN 게이트웨이에서 트래픽을 캡처하거나 기록하세요. 패킷이 터널에 들어가지만 NAS VLAN 쪽으로 나가지 않는다면 IP 포워딩, 인터페이스 간 방화벽 규칙, VPN 게이트웨이에서 해당 서브넷으로 가는 경로를 점검하세요.
분할 터널 구현 가이드는 경로 설치가 일치하는 포워딩 및 방화벽 정책과 함께 이루어져야 함을 강조합니다. 클라이언트 측 경로만으로는 VPN 게이트웨이가 다른 VLAN으로 트래픽을 전달할 수 없습니다.
그다음 NAS 서브넷의 라우터가 VPN 클라이언트 풀로 돌아가는 경로가 있는지 확인하세요. 응답이 일반 인터넷 게이트웨이를 사용한다면 반환 경로를 추가하거나 VPN 게이트웨이에서 신중하게 범위를 지정한 소스 NAT를 적용하세요. 응답 없이 일방향 캡처가 성공하면 반환 경로 실패이며 클라이언트 경로를 계속 변경할 이유가 아닙니다.
다른 경로를 깨뜨리지 않고 NAS 서비스 재테스트하기
IP 도달 가능성이 확인되면 IP와 호스트 이름으로 실제 NAS 서비스를 테스트하세요. 성공적인 핑이 애플리케이션 경로를 보장하지 않으므로 SMB, 웹 대시보드 또는 필요한 앱 포트를 확인하세요.
ZimaSpace의 VPN에서 LAN 경로 누락 사례 가이드는 터널 연결이 모든 LAN 트래픽 유형이 같은 경로를 따르지 않는다는 인접 교훈을 제공합니다.
수정된 NAS 서브넷, 이전에 작동하던 원격 서브넷 하나, 일반 인터넷 접속을 테스트하며 마무리하세요. 세 가지 모두 설계대로 작동하고 경로가 재연결 후에도 유지되며 클라이언트가 네트워크 변경 시마다 수동 명령을 입력할 필요가 없을 때만 변경 사항을 유지하세요.
지원 및 팁
더 읽어보기

How to Reduce Plex Database Contention on a Busy Docker Host
A Plex configuration guide for busy hosts that treats the database as local application state and reduces I/O contention without inventing a shared DB...

How to Prevent Duplicate Plex Scans and Imports
A prevention guide for duplicate Plex scans and imports that removes overlapping triggers instead of disabling library updates entirely.

How to Recover Plex After Its App-Data Volume Fills Up
A recovery ladder for full Plex app-data volumes that protects the database first and avoids deleting unknown files just to make the service start.

