OpenVPN LAN 접속이 끊겼나요? 영역, 경로, 반환 경로를 확인하세요

터널은 연결 성공을 알리고 라우터 자체 페이지도 열리는데, 그 뒤 컴퓨터로의 드라이브 매핑은 여전히 시간 초과됩니다. 이 조합에는 모순이 없습니다. 라우터는 자기 자신으로서 응답하고, 그 뒤의 무언가에 닿는 것은 다른 곳에서 내려지는 다른 결정입니다. 아래 점검을 순서대로 수행하고 첫 실패에서 멈추세요. 각 점검은 앞의 점검 위에 서 있습니다. 네 가지가 모두 통과하면 결함은 터널 안이 아니라 위에 있습니다.

LAN으로 가는 패킷을 어느 필터가 보는가

라우터로 향한 패킷은 로컬에서 소비되고, 그 뒤의 호스트로 향한 패킷은 전달되어야 하며, 방화벽은 이 두 경우를 따로 판정합니다. 따라서 라우터에 닿을 권한은 라우터를 지날 권한에 대해 아무것도 말하지 않습니다. 규칙 집합을 숨기는 펌웨어도 둘 다 구현하며, 보통 LAN, 인터넷 또는 둘 다를 제공하는 선택기로 제시합니다. 선택기가 LAN을 빼면 이후의 어떤 점검도 의미가 없습니다.

OpenWrt는 이 구분을 검사 가능하게 만들며, 그 차이는 한 번 읽을 가치가 있습니다. 터널을 끝내는 영역에는 LAN 영역을 향한 전달 규칙이 필요하고, 입력 규칙은 라우터 자체의 서비스만 통제합니다. 관리 페이지가 열리는데 LAN이 죽어 있는 것은 그 빠진 전달 규칙의 흔한 결과입니다.

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

터널을 나르는 영역의 전달 대상을 보세요. accept가 이 사다리에 필요한 값이고, reject는 아래의 모든 시간 초과를 설명합니다. 인접한 두 설정이 같은 증상을 만들므로 여기서 함께 배제하세요. 무선 격리는 유선 호스트를 무선 클라이언트에서 숨기고, 유휴 LAN 호스트를 오프라인으로 취급하는 라우터는 전달이 동작한 뒤에도 응답을 버릴 수 있습니다.

분할 터널에 푸시된 프리픽스가 필요한 이유

모든 트래픽을 터널로 보내는 클라이언트는 기본 경로를 통해 이미 LAN 프리픽스를 가지고 있으므로 더할 것이 없습니다. 분할 터널이야말로 프리픽스를 명시해야 하는 경우이며, 설정의 다른 어디에도 그것이 나오지 않기 때문입니다. 지시문을 서버 설정에 추가하고 서비스를 다시 불러오세요.

push "route 192.168.50.0 255.255.255.0"

다음을 포함한 프로필은 route-nopull 푸시된 경로를 무시하므로 같은 프리픽스는 클라이언트 파일에 들어가야 합니다. 어느 경우든 항목이 도착했다고 가정하지 말고 확인하세요. 조용한 덮어쓰기는 방화벽 문제와 똑같이 보입니다.

ip route show | grep 192.168.50

사이트 간 피어는 푸시보다 많은 것을 요구합니다. 서버는 그 피어 뒤에 어떤 프리픽스가 있는지 배워야 하며, 그것을 client-config-dir 파일의 iroute 줄이 합니다. 또한 서버 자신의 테이블에도 터널로 들어가는 대응 경로가 필요합니다.

응답에는 도달할 수 있는 주소가 필요하다

요청을 전달하는 것은 교환의 절반일 뿐입니다. LAN 호스트가 터널 풀의 주소로 응답해야 하기 때문입니다. 소형 라우터는 보통 터널 영역에서 출발지를 변환하여 그것을 처리하므로 응답은 라우터로 향하고 다른 곳에는 설정이 필요 없습니다. 그 변환을 없애면 호스트는 풀로 가는 자체 경로가 필요하며, 라우터가 기본 게이트웨이일 때 그것을 공짜로 얻습니다. 주소를 수동으로 설정하고 다른 게이트웨이를 둔 호스트는 그 게이트웨이로 응답하고, 클라이언트는 세션이 열렸다가 멈추는 것을 봅니다.

tcpdump -ni tun0 host 192.168.50.20

클라이언트가 요청을 반복하는 동안 라우터에서 이것을 실행하고, 요청 자체가 아니라 응답의 목적지를 읽으세요. 풀로 향한 응답은 반환 경로가 동작하고 결함이 더 안쪽에 있음을 뜻합니다. 응답이 전혀 없으면 호스트가 패킷을 받아들이지 않은 것이므로 규칙 집합으로 돌아갑니다.

올바른 곳에서 끝나는 사다리

네 점검이 계층을 찾아내며, 각각은 판단이 아니라 단일 명령입니다. 순서대로 실행하고 첫 실패에서 멈추세요. 순서가 명령보다 중요합니다. 뒤 단계가 통과하면 앞 단계가 실패한 이유가 가려지기 때문입니다.

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

이름은 사다리의 끝에 두고 결코 처음에 두지 않습니다. 192.168.50.20으로는 응답하지만 nas.local로는 응답하지 않는 공유는 이름 확인이나 검색 접미사를 가리키며, 방화벽 편집으로는 둘 다 바꿀 수 없습니다.

처음 실패한 단계를 기록한 다음 서비스 포트에 별도의 점검을 주세요. 리스너와 호스트 권한은 별개의 요구 사항입니다. 파일 공유, 원격 데스크톱, 카메라 스트림은 모두 둘 다 필요하며, LAN 서브넷은 신뢰하지만 터널 풀은 신뢰하지 않는 호스트 방화벽은 ping이 통해도 클라이언트를 떨어뜨립니다. 모든 점검이 통과하는데 애플리케이션이 여전히 실패하면 결함은 터널 위에 있습니다. 하나의 인터페이스에 묶인 서비스이거나 클라이언트에 설정된 프록시입니다.