VPN 클라이언트 모드의 라우터: LAN 장치가 사라지는 이유
라우터가 VPN 클라이언트 모드로 전환된 뒤 LAN 장치가 사라집니다. 먼저 전달 경로의 검사 기능을, 다음으로 펌웨어가 바꾼 LAN 범위를 확인하세요.
클라이언트 모드 자체가 LAN 접근을 죽인다는 믿음은 사람들을 잘못된 설정 메뉴로 보냅니다. 실제 원인은 보통 두 가지입니다. 터널은 LAN 브리지를 제거하지 않고 유선 및 무선 클라이언트가 서로 도달하는 것도 막지 않습니다. 로컬 접근을 끊는 것은 라우터의 전달 경로에 있는 검사 기능이거나 펌웨어가 바꾸면서 이동한 LAN 주소 범위입니다. 둘 다 같은 불만을 만들고, VPN 프로필을 다시 설치해도 어느 쪽도 고쳐지지 않습니다.
신화, 그리고 클라이언트 모드가 실제로 바꾸는 것
클라이언트 모드는 터널 인터페이스와 그를 지나가는 기본 경로를 추가한 뒤 LAN 트래픽을 그 터널로 전달합니다. 유선 포트와 무선 라디오 사이의 브리지는 그대로이고 로컬 스위칭도 마찬가지입니다. 바뀌는 것은 정책입니다. 어떤 트래픽이 전달되는지, 어디서 변환되는지, 클라이언트가 어떤 리졸버를 받는지입니다.
이 구분이 중요한 이유는 LAN이 끊겼다는 것이 보통 그 세 정책 중 하나가 바뀌었다는 뜻이지 라우터가 스위치를 그만두었다는 뜻이 아니기 때문입니다. 자기 관리 페이지에 여전히 응답하는 라우터는 LAN 인터페이스가 살아 있다는 증거입니다. 아무것에도 응답하지 않는 라우터는 다른 문제가 있으며, 예를 들어 LAN 주소가 바뀌었거나 클라이언트가 잘못된 서브넷에 있는 경우입니다.
따라서 유용한 첫 단계는 어느 계층이 끊겼는지 찾는 것이지, 의심하는 계층을 바꾸는 것이 아닙니다.
설정을 건드리기 전에 세 대상을 시험하세요
유선 클라이언트에서 세 대상을 따로 시험하고 각 결과를 적으세요. 라우터 자체의 LAN 주소, 같은 스위치에 있는 다른 장치의 IP, 그리고 터널을 통해서만 닿을 수 있는 것입니다. 이 순서로 하세요. 각 결과가 서로 다른 계층을 배제하기 때문입니다. 첫 회에는 이름 대신 주소를 사용하세요. 이름 실패는 DNS를 연결 문제에 섞기 때문입니다.
응답 패턴이 진단입니다. 로컬 장치는 응답하지 않는데 라우터가 응답하면 라우팅이 아니라 로컬 스위칭이나 필터링 기능을 가리킵니다. 터널 쪽은 응답하지 않는데 로컬 장치가 응답하면 터널 경로나 원격 방화벽을 가리킵니다. 주소로는 모두 응답하지만 이름이 실패하면 리졸버 문제이며, 경로 편집으로는 고칠 수 없습니다.
| What answers | What it points at |
|---|---|
| Router only | LAN-side filtering or a broken bridge |
| Router and local hosts, not remote | Tunnel route, NAT or remote firewall |
| Addresses yes, names no | DNS handed to clients by the router |
| Nothing at all | Client subnet or router LAN address changed |
표를 시험 결과 옆에 두세요. 모호한 불만을 실행 가능한 한 줄로 바꿔 줍니다.
전달 경로 안의 보안 계층
소비자 라우터에는 전달되는 트래픽을 감시하는 검사 기능이 점점 더 많이 들어가며, 이는 LAN에서 터널로 패킷을 나르는 같은 경로에서 실행됩니다. 그 검사가 터널 트래픽을 분류하지 못하면 터널 자체는 올라가 있고 라우터는 건강한 연결을 보고하는데도 전달이 멈출 수 있습니다. VPN 로그에는 이것이 보이지 않습니다. VPN은 실제로 연결되었기 때문입니다.
진단은 영구 변경이 아니라 통제된 실험입니다. 현재 설정을 적고, 한 번의 시험 동안 기능을 끄고, 터널을 다시 올리고, 주소로 로컬 호스트 하나를 시험하세요. 전달이 돌아오면 필요한 증거가 확보되며, 그때 트레이드오프는 추측이 아니라 결정이 됩니다. 아무것도 바뀌지 않으면 즉시 다시 켜고 주소 지정 원인으로 넘어가세요.
터널이 계속 작동하도록 유료 보안 기능을 꺼 둔다는 것은 의도적으로 하고 기록해야 하는 트레이드오프입니다. 터널이 다른 장치에 있어야 하는지도 물을 가치가 있습니다. 모든 것을 검사해야 하는 라우터와 모든 것을 전달해야 하는 라우터는 다른 일이기 때문입니다.
두 번째 원인: LAN 범위가 움직였다
펌웨어 업데이트는 LAN 주소를 제조사 기본값으로 되돌리는 일이 잦고, 일부 라우터에는 LAN이 사설 범위를 유지할지 상위 장치에서 하나를 상속할지 정하는 명시적 모드 스위치가 있습니다. 192.168.8.x 을 기대하는 클라이언트가 10.64.0.x 에 오게 될 수 있고, 그러면 터널이 완전히 건강해도 호스트로의 SSH 세션이 시간 초과됩니다.
ipconfig /all
ip addr show
ip route get 192.168.8.20
라우터 페이지를 열기 전에 임대에서 프리픽스와 게이트웨이를 읽으세요. 처음 두 명령은 클라이언트가 실제로 받은 것을 보여 주고, 세 번째는 로컬 주소에 어떤 인터페이스를 쓸지 보여 줍니다. 남은 경로나 오래된 서브넷은 이렇게 드러납니다. 그런 다음 LAN 페이지와 라우터의 모드와 비교하세요.
범위를 되돌릴 수 없으면 그것을 이름 붙이는 모든 객체를 갱신하세요. DHCP 예약, 이전 서브넷으로 향하는 모든 정적 경로, 이전 프리픽스를 가진 모든 방화벽 규칙입니다. 터널의 원격 서브넷과 충돌하는 범위는 더 나쁜 형태입니다. 로컬 장치는 계속 닿지만 원격 대상은 조용히 LAN으로 잘못 라우팅되기 때문입니다.
다시 연결하고 패킷 순서로 다시 시험하세요
두 변경 중 하나를 한 뒤 터널을 다시 연결하고 시험을 패킷 순서로 반복하세요. 라우터, 로컬 호스트, 원격 호스트, 다음 이름, 다음 애플리케이션입니다. 애플리케이션을 먼저 시험하면 어느 계층이 아직 끊겼는지 가려집니다. 캐시된 이름에 대한 브라우저 재시도는 라우팅 실패처럼 보일 수 있습니다.
VPN 프로필 옆에 펌웨어 버전, LAN 프리픽스, 검사 기능 상태를 기록하세요. 셋 다 다음 업데이트가 덮어쓸 수 있는 구성이며, 두 줄의 메모가 방금 쓴 한 시간을 아껴 줍니다.