VPN 클라이언트 둘, 라우팅 테이블 하나: 기본 경로는 누구에게

두 VPN 클라이언트가 같은 소켓을 두고 다투는 것처럼 보이고, 뻔한 해결책은 하나를 제거하는 것 같습니다. 실제로는 같은 소켓을 건드리는 일이 드뭅니다. 연결할 때마다 운영체제 라우팅 테이블이 다시 쓰이고, 전체 터널 프로필이 기본 경로를 차지합니다. 마지막에 연결한 쪽이 보통 이기며, 그래서 증상이 클라이언트 사이를 옮겨 다니는 것처럼 보입니다.

충돌은 라우팅 테이블 안에 있다

가상 어댑터와 기본 경로의 조합이 전체 터널이 트래픽을 잡는 방식입니다. 두 번째 클라이언트가 자기 기본 경로를 설치하면 기존 항목은 교체되거나 메트릭으로 낮아지고, 모든 목적지가 이제 더 새로운 터널을 지납니다. 첫 번째 클라이언트는 연결된 채로 녹색 아이콘을 계속 보여 주므로 인터페이스는 살아 있는데 경로만 사라집니다. 연결 상태와 라우팅 상태가 분리되어 있다는 점이 이 동작을 헷갈리게 만듭니다.

클라이언트는 하나의 공유 테이블을 편집하는 주체입니다. 어떤 편집이 마지막이었는지 알면 거의 모든 증상이 설명됩니다.

현재 경로를 어느 터널이 소유하는지 읽기

연결되었다고 보고하는 클라이언트를 믿는 대신 실제 결정을 확인합니다. 특정 목적지를 어느 인터페이스가 실어 나를지 시스템에 묻습니다.

ip route get 10.20.0.5
route print -4

첫 번째 명령은 한 목적지에 어느 인터페이스와 원본 주소가 쓰이는지 알려 주므로, 바로 궁금한 질문에 답합니다. 경로 덤프는 Windows에서 경쟁하는 기본 항목과 그 메트릭을 보여 주므로 지금 어느 쪽이 이기는지 알 수 있습니다. 각 원격 네트워크의 호스트에 대해 조회를 실행하십시오. 한 목적지는 맞아도 다른 네트워크는 닿지 않을 수 있기 때문입니다. 답이 잘못된 터널을 가리키면 다시 연결해도 소용없고, 경로 정책을 바꿔야 합니다.

두 번째 클라이언트가 모든 것을 차지하지 못하게 하기

한 클라이언트가 기본 경로를 소유하고, 다른 쪽은 자기 접두사만 실어야 합니다.OpenVPN 클라이언트는 서버가 밀어 넣는 설정을 거부할 수 있습니다.

pull-filter ignore "redirect-gateway"
ip route get 10.30.4.10

route-nopull 는 밀어 넣은 모든 경로를 무시하고, pull-filter ignore "redirect-gateway" 는 기본 경로 지시문만 버리며 밀어 넣은 DNS 와 다른 옵션은 유지합니다. 서버 설정을 얼마나 더 원하는지에 따라 둘 중 하나를 고르고, 두 번째 네트워크에 필요한 구체적 접두사를 추가하십시오. DNS 를 염두에 두어야 합니다. 조회를 실어 나르지 않는 터널이 밀어 넣은 리졸버는 아무것도 돌려주지 않습니다. 각 네트워크에서 알려진 호스트 하나를 시험하고 원격 쪽이 보는 원본 주소를 확인하십시오.

겹치는 서브넷은 우회할 수 없다

두 네트워크가 같은 접두사를 게시하면 커널은 서로 다른 두 장소에 대해 항목 하나를 쥐고 선택해야 합니다. 호스트 경로가 빠진 구분을 만들어 낼 수 없고, 메트릭 조정도 마찬가지입니다. 한쪽 번호를 다시 매기거나, 그 관리자가 원격 대역을 변환해 접두사가 달라지게 하십시오. 클라이언트를 탓하기 전에 실제 서브넷을 확인하십시오. 가정용 라우터의 기본값 192.168.1.0/24 는 생각보다 자주 사무실 대역과 충돌합니다. 두 대역을 티켓에 기록해 다음 변경이 겹침을 다시 만들지 않게 하십시오.

두 목표도 분리하십시오. 두 네트워크에 닿는 것은 라우팅 문제이고, 프라이버시를 위해 터널을 연결하는 것은 경로에 운영자가 하나 더 붙는 다른 설계입니다. 하나로 다른 하나를 해결하지 마십시오.