LAN과 겹치는 VPN 풀은 라우트로 고쳐지지 않는다

앱은 터널이 건강하다고 말하지만, 필요한 목적지의 절반은 결코 응답하지 않습니다. 첫 반응은 라우트를 추가하거나 메트릭을 낮추는 것이고, 바로 그 반응이 가장 먼저 죽여야 할 신화입니다. 클라이언트 자신의 LAN과 터널 풀이 같은 프리픽스를 주장하면, 라우팅 테이블은 양립할 수 없는 두 사실을 안고 있고, 기본 라우트도 메트릭도 그것을 해결하지 못합니다. 수리는 주소 지정에 관한 결정이며, 라우트 편집이 그것을 대신하지 못합니다.

추가 라우트가 하나의 프리픽스를 나눌 수 없는 이유

라우트는 한 프리픽스에 대한 두 주장을 분리할 수 없으므로, 올바른 라우트 행을 찾는 일을 그만두는 것이 현명합니다. 스택은 동일한 프리픽스를 연결된 라우트 앞에 두지 않으며, 더 구체적인 항목은 주소를 붙잡지만, 그 주소를 소유한 로컬 호스트를 도달 불가능하게 만듭니다. 라우팅 문제로 보이는 것은 주소 충돌이며, 두 수리 모두 라우트가 아니라 주소를 바꿉니다. 받아들이기 전에 자기 기계에서 이 주장을 시험해 보세요.

ip route get 192.168.1.50
route -n get 192.168.1.50
Find-NetRoute -RemoteIPAddress 192.168.1.50

시스템에 한 주소를 질의하고 어떤 인터페이스를 지목하는지 보세요. Linux, macOS, Windows는 각각 아무것도 전송하지 않고 선택된 인터페이스와 다음 홉을 보고하는 읽기 전용 조회로 답합니다. 터널이 올라간 상태에서 답이 물리 어댑터를 가리키면, 커널은 그 주소를 터널이 나를 수 있는 것이 아니라 링크 상에 있는 것으로 취급합니다.

공급자가 부여한 프리픽스를 집 라우터가 제공하는 프리픽스 옆에 두고 문자열로 비교하세요. 정확히 일치하는 것이 분명한 경우이고, 집 서브넷을 포함하는 더 넓은 공급자 풀도 똑같이 실패하지만 놓치기 쉽습니다. 비슷해 보일 뿐인 두 프리픽스는 충돌이 아니므로, 무엇이든 바꾸기 전에 둘 다 적어 두세요.

클라이언트가 실제로 받은 풀을 읽으세요

공급자의 마케팅 페이지가 아니라 클라이언트가 받은 것을 읽으세요. OpenVPN 클라이언트의 로그 상세도를 높이면 서버가 밀어 넣은 라우트가 그 안에 나타나 터널 프리픽스를 드러내며, 다른 곳에서는 연결 세부 정보나 어댑터 자체에서 풀이 보입니다. 공급자가 사용하는 모든 사설 범위의 전체 목록을 요청하세요 — 오늘의 /24 하나가 내일 둘이 될 수 있습니다. 흔한 RFC 1918 블록을 피하는 것은 실제로 받은 할당을 피하는 것과 같지 않습니다.

풀은 줄어들거나 지역 사이를 옮길 수 있으므로 목록에는 날짜와 담당자가 필요합니다. 마지막 계획 변경보다 오래된 공급자 답변은 사실이 아니라 추측으로 다루세요. 범위에 확정하기 전에 다시 묻고, 답변을 네트워크 노트와 함께 보관해 다음 사람이 증거를 물려받게 하세요.

다시 번호 매기기가 당신이 할 수 있는 수리입니다

VPN 서버가 당신이 바꿀 수 있는 것이 아니라면, 집 LAN을 옮기는 것이 유일하게 가능한 수리입니다, 그리고 상용 공급자에서는 이것이 일반적인 상황입니다. 공급자 풀 밖이면서 나중에 필요할 수 있는 범위 밖의 범위를 고르고, 터널로 도달하는 다른 모든 사이트와 대조하세요. 짧은 중단과 잊힌 장치들의 더 긴 꼬리를 예상하세요: 옛 주소를 그대로 가진 장치는 게이트웨이가 필요할 때까지 작동하는 것처럼 보입니다.

1. 먼저 목록: 라우터 자체의 주소, DHCP 범위, 예약, 포트 포워딩, 그리고 주소를 손으로 입력한 모든 장치.
2. 그다음 유지보수 창 안에서 라우터의 LAN 프리픽스와 DHCP 범위를 함께 바꾸고, 유선 임대를 무선보다 먼저 갱신하세요.
3. 이어서 고정 주소를 바로잡으세요: 프린터, 네트워크 저장소, 게이트웨이를 직접 적어 둔 모든 것.
4. 마지막으로 VPN 클라이언트를 다시 연결하고 터널 주소가 더 이상 LAN과 충돌하지 않는지 확인하세요.

주소를 한꺼번에가 아니라 그 순서로 처리하고, 옛 범위를 한동안 문서로 남겨 두어 낡은 장치가 미스터리가 아니라 알아볼 수 있게 하세요. 결코 갱신하지 않는 장치는 게이트웨이에 닿지 못해 스스로를 알리며, 이는 지원 전화보다 훨씬 좋은 단서입니다. 라우터가 하루보다 긴 임대를 준다면 창이 열린 동안 그 기간을 줄이세요.

별칭이 할 수 있는 일과 없는 일

서버가 당신의 것일 때, 클라이언트에서 주소를 변환하면 원격 프리픽스를 비어 있는 로컬 범위 안에 드러낼 수 있고, 그래서 같은 호스트가 두 번째 주소로 응답합니다. 커뮤니티 OpenVPN은 이것을 client-nat로 하는데, 이 지시문은 그 클라이언트에 특유한 것이고, 흔히 비교하는 상용 및 모바일 클라이언트에는 없습니다. 이 구성에는 변환에 맞는 라우트, 별칭을 위한 빈 범위, 클라이언트의 변환되지 않은 주소에 응답할 서버가 필요합니다. 클라이언트가 당신이 설정할 수 없는 관리형 공급자의 것이라면 이 중 어느 것도 도움이 되지 않습니다.

변경이 적용되면 먼저 주소로, 다음으로 이름으로 로컬 호스트와 원격 호스트에 도달하고, 시스템이 매번 고르는 라우트를 기록하세요. 이름이 여전히 옛 범위로 해석될 수 있으므로 주소와 이름은 따로 확인할 가치가 있습니다. 변경 내내 켜져 있던 것이 있다면 클라이언트 하나와 서버 측 장치 하나를 다시 시작하세요 — 캐시된 인접 항목은 편집보다 오래 살아남습니다.

정한 프리픽스를 사람들이 실제로 보는 곳에 쓰세요: 네트워크 노트, 라우터 자체의 코멘트 필드, 안내 페이지. 누군가 다시 192.168.1.0/24를 고르고, 충돌은 그와 함께 돌아옵니다.