OpenVPN에 연결됐는데 ping도 SMB 공유도 안 될 때? 세 개의 관문을 확인하세요

터널은 올라오고 클라이언트는 주소를 받지만, 원격 LAN에서는 아무것도 응답하지 않습니다. ping은 실패하고, 공유는 열리지 않으며, VPN 로그는 깨끗해 보이는데, VPN의 관점에서는 세션이 정상이기 때문입니다. 그 세션과 서버의 파일 사이에는 포워딩 정책, 서비스가 필요로 하는 포트, 주소 대신 입력한 이름이라는 세 개의 독립된 관문이 있습니다.

각 관문은 서로 다른 증상으로 실패하며, VPN 서버에 있는 것은 첫 번째뿐입니다.

포워딩은 FORWARD 체인의 정책입니다

OpenVPN 리스너의 수락은 INPUT에서 일어나므로, LAN으로 가는 모든 패킷이 버려져도 터널은 연결될 수 있습니다. tun0 로 들어와 LAN 인터페이스로 나가는 트래픽은 FORWARD를 지나며, 그곳에 기본 DROP 정책이 있는 호스트는 그것을 조용히 버립니다. 다른 무엇을 건드리기 전에 sysctl과 체인을 모두 확인하세요 sysctl net.ipv4.ip_forward 그리고 iptables -L FORWARD -v -n.

의도한 방향과 그에 속한 응답을 허용하세요: 터널 인터페이스에서 LAN 인터페이스로 가는 accept 규칙과 established 및 related 트래픽을 위한 stateful 규칙입니다. LAN이 다른 라우터 뒤에 있다면 그 라우터에는 클라이언트 풀로 돌아가는 경로나 VPN 서버의 source NAT가 필요합니다. 도달할 수 없는 규칙은 카운터에 절대 나타나지 않으므로, 규칙을 더 추가하기 전에 ping 한 번으로 그 경로를 확인하세요.

SMB에는 포트 하나로 충분하지 않습니다

파일 공유는 TCP 445 대화 하나가 아닙니다. 검색은 UDP 137과 138을 쓰고, 오래된 NetBIOS 세션은 TCP 139를, 현대 SMB 세션은 TCP 445를 씁니다. 445만 여는 규칙은 매핑된 드라이브는 되는데 네트워크 찾아보기는 안 되거나 그 반대인 골치 아픈 상황을 만듭니다.

터널을 지나는 큰 전송은 공유가 깨진 것처럼 보이는 MSS 문제도 만납니다. LAN의 전체 세그먼트 크기를 알리는 SYN은 터널의 더 작은 MTU 때문에 버려지고, 핸드셰이크 후에 연결이 멈춥니다. 포워딩 경로에서 MSS를 클램프하는 것, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, 이 그런 종류의 멈춤을 없앱니다. 큰 전송이 통하지 않을 때도 작은 응답은 통과하므로 디렉터리 목록 대신 몇 메가바이트 복사로 확인하세요.

터널 어댑터는 새 네트워크 프로필로 나타납니다

Windows는 각 어댑터를 네트워크 프로필로 분류하며, 새 터널 어댑터는 보통 파일 및 프린터 공유 규칙이 차단된 Public에 들어갑니다. 이것은 파일 서버의 호스트 방화벽 결정이며, VPN 서버의 라우팅 문제가 아닙니다. 정책이 허용하는지 확인한 뒤, 범주가 어떤 인바운드 규칙이 적용되는지도 바꾸므로, 의도적으로 Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private 로 범주를 바꾸세요.

같은 프로필이, Public에서 에코 요청이 기본으로 버려지기 때문에 TCP 445는 성공하는데 ping은 실패하는 이유를 설명합니다.

이름은 라우팅된 터널을 스스로 넘지 않습니다

NetBIOS 이름 확인과 로컬 검색은 라우팅된 터널이 전달하지 않는 브로드캐스트에 의존합니다. 그래서 서버의 짧은 이름을 입력하면 실패하지만 주소는 작동하며, 조회만 깨졌는데도 공유가 깨진 것처럼 보입니다. 터널이 배포하는 리졸버에 서버의 DNS 레코드를 추가하거나, 바로 가기에 주소를 사용하세요.

배포가 아직 WINS에 의존한다면 브로드캐스트 트래픽이 나타나기를 기대하지 말고 클라이언트에 구성하세요. 이름 실패를 방화벽 실패로 오해하지 않도록 먼저 주소로 테스트하세요.

한 번에 한 계층씩 테스트하고 첫 실패를 읽으세요

아래에서 위로 진행하며, 터널 게이트웨이에 ping하고, 주소로 LAN 호스트에 ping한 다음, Test-NetConnection -ComputerName 10.8.0.5 -Port 445 로 서비스 포트를 열고, 그다음에야 공유에 인증합니다. 처음 실패한 단계가 고쳐야 할 계층이며, 그 뒤의 모든 단계는 그것이 통과할 때까지 잡음입니다. 포트가 닫힌 채 ping이 응답하면 파일 서버 자체의 방화벽을 가리키고, ping이 조용한데 포트가 열리면 ICMP 필터링을 가리킵니다. 두 번째 변경이 첫 번째의 결과를 가리기 때문에 무언가를 바꾸기 전에 첫 실패 단계를 적어 두세요.

VPN 서버가 LAN의 라우터가 아니라면, 그 라우터에서 돌아오는 경로를 확인한 뒤 서버에 규칙을 더 추가하세요. 그것이 없으면 요청은 호스트에 도달하고 응답은 기본 경로로 인터넷 쪽으로 나가며, 클라이언트 쪽에서는 방화벽 드롭과 똑같이 보입니다.

성공한 터널은 파일 권한에 대해 아무것도 말해 주지 않으므로, 메모에서 공유 계정을 VPN 로그인과 분리해 두세요. 빠진 규칙을 피하려고 SMB를 인터넷에 노출하는 것은 해결책이 아닙니다.