집과 사무실이 모두 192.168.1.x를 쓴다면: 이제 어떻게 할까

네 가지 확인을 차례로 하십시오. 이름이 어느 주소로 해석되는지, 로컬 네트워크가 어느 프리픽스를 쓰는지, 커널이 그 목적지에 어느 경로를 고르는지, 그리고 먼 쪽에서 무엇이 응답하는지입니다. VPN 로그인은 여기에 속하지 않습니다. 어느 네트워크가 이기든 로그인은 완료되기 때문입니다. 확인을 순서대로 하면 중복은 네 번째가 아니라 두 번째 단계에서 드러납니다.

로그인 성공은 터널이 올라왔다는 뜻일 뿐, 특정 주소가 어디를 가리키는지는 말해 주지 않습니다.

하나의 주소, 두 대의 기기

호스트는 목적지 주소를 사용해 라우팅 테이블과 정책 규칙에서 경로를 고릅니다. 192.168.1.20 홉으로 가는 요청이 옆방 기기가 아니라 사무실 서버를 위한 것이라는 정보는 어디에도 없습니다. 두 네트워크가 같은 사설 대역에 있으면 가장 구체적인 경로가 이기고, 나머지는 재접속이 우연히 어떤 항목을 설치했는지에 달려 있습니다. 주소 자체에는 그 구분을 담은 것이 없습니다.

ip route get 192.168.1.20

그 조회는 커널이 고른 인터페이스와 다음 홉을 알려 주며, 이것이 목록의 두 번째 확인입니다. 다른 일을 하기 전에 로컬과 원격 프리픽스를 비교하십시오. 로컬 LAN이 192.168.1.0/24이고 원격 사이트도 192.168.1.0/24라면 중복이 바로 그 발견이며, 어떤 클라이언트 옵션도 이를 고치지 못합니다.

본인이 관리하는 쪽의 번호를 다시 매기십시오

개인 공유기는 보통 옮기기 쉬운 쪽입니다. 실제로 쓰는 원격 네트워크와 충돌하지 않는 범위를 고르고, 10.x.x.x도 자동으로 비어 있지는 않다는 점을 기억하십시오. 많은 사이트가 이 대역을 씁니다. 변경을 계획하십시오. DHCP 임대, 예약 주소, 인쇄 대기열, 주소가 하드코딩된 모든 것이 손이 필요합니다. VPN 없이 공유기를 복구할 수 있는 시간에 번호를 다시 매기십시오.

원격 프리픽스 목록은 나중이 아니라 먼저 확인하십시오. 다른 사무실 사이트와 충돌하는 새 범위를 고르면 더 많은 수고로 같은 문제가 생깁니다.

어느 쪽도 바꿀 수 없을 때

두 네트워크 중 어느 것도 번호를 다시 매길 수 없다면 남은 선택지는 서버에 있습니다. 게이트웨이는 정책 기반 NAT나 양방향 방식을 사용해 VPN 클라이언트에게 원격 네트워크를 다른 서브넷으로 변환해 줄 수 있어, 클라이언트는 고유한 주소를 봅니다. 그것은 게이트웨이 설계이지 모든 데스크톱 클라이언트가 제공하는 스위치가 아니며, 사용자가 입력하는 주소와 일치해야 하는 이름을 바꿉니다. 포럼에서 복사한 경로는 두 개의 동일한 목적지를 구별하지 못합니다.

사설 주소 대역은 사설로 남습니다. 문제는 범위 자체가 아니라 재사용입니다.

어느 기기가 응답했는지 증명하십시오

openssl s_client -connect 192.168.1.20:443 -servername office.example 2>/dev/null | openssl x509 -noout -subject

변경 후에는 사무실 리소스와 로컬 기기를 함께 시험하십시오. 익숙한 집 기기가 사무실 서버가 있어야 할 곳에서 응답하거나, TLS 인증서가 잘못된 호스트를 가리키면 멈추고 계속하기 전에 목적지를 확인하십시오. 그 주소에서 응답을 받았다고 해서 어느 기기가 보냈는지 증명되지는 않습니다. 인증서 주체를 확인하는 것은 그 시점에서 쓸 수 있는 몇 안 되는 신뢰할 만한 신호 중 하나입니다.

사무실의 사설 주소를 관리하지 않는 임의의 공인 주소로 바꾸지 마십시오. 중복을 더 나쁘고 설명하기 어려운 라우팅 및 소유권 문제와 맞바꾸는 셈입니다.

로컬 프리픽스, 원격 프리픽스, 그리고 문제를 해결한 변경을 기록하십시오. 다음 중복은 달라 보이겠지만 같은 패턴을 따릅니다.