데스크톱 한 대에 VPN 클라이언트 두 개: 무엇이 충돌하고 무엇이 작동하는가

두 번째 클라이언트가 연결되면 첫 번째의 리소스가 더 이상 확인되지 않고, 티켓에는 업무용 VPN이 개인용을 망가뜨렸다고 적혀 있습니다. 고장이라는 의미에서 아무것도 망가지지 않았습니다. 두 클라이언트 모두 설계된 대로 동작했고, 기계에는 라우팅 테이블이 하나뿐입니다. 충돌은 각 클라이언트가 자기 것이라고 가정하는 네 가지 리소스를 둘러싼 것입니다. 순서대로 처리하면 수정은 보통 수리가 아니라 설계 선택이 됩니다.

1단계: 어느 클라이언트가 출구를 소유하는지 찾기

무엇이든 바꾸기 전에 현재 출구 결정을 읽으십시오. 공인 주소에 대한 경로 조회는 패킷이 지금 어느 인터페이스와 다음 홉을 사용할지 알려 주며, 그것이 누가 이겼는지에 대한 답입니다. 이를 클라이언트가 만든 인터페이스 이름과 비교하십시오. 이름에는 보통 제품이나 프로토콜 이름이 들어 있습니다. 조회가 예상하지 못한 터널을 가리킨다면 이미 충돌을 찾은 것입니다.

ip route get 1.1.1.1
ip route show default
route print

일부 클라이언트는 기본 경로를 아예 교체하지 않고, 주소 공간의 아래쪽 절반과 위쪽 절반에 각각 하나씩 두 조각을 추가해 둘이 합쳐 전체를 덮습니다. 그러면 원래 기본 경로가 보이는 채로 남고 수동 수리가 올바른 것처럼 보이지만 트래픽은 여전히 터널로 나갑니다. 기본 항목의 존재만이 아니라 메트릭과 프리픽스 길이를 읽으십시오.

두 클라이언트가 같은 메트릭으로 같은 프리픽스를 주장하면 멈추십시오. 커널은 하나를 고르고, 다른 하나는 아무것도 나르지 않은 채 연결된 것으로 보일 것입니다.

2단계: 리졸버와 겹치는 프리픽스 확인

DNS는 두 번째 충돌이며 독특한 증상을 만듭니다. 주소는 작동하는데 이름이 실패합니다. 각 클라이언트가 자기 리졸버를 밀어 넣고, 뒤따르는 질의에서는 마지막에 쓴 쪽이 이깁니다. 클라이언트의 설정 페이지를 읽는 대신 리졸버 서비스에 링크마다 무엇을 쓰는지 물어보십시오.

resolvectl status
Get-DnsClientServerAddress
dig +short intranet.corp.example

그다음 두 네트워크가 사용하는 사설 프리픽스를 비교하십시오. 양쪽이 같은 범위에서 할당하면 클라이언트 측 조정으로는 고칠 수 없습니다. 기계는 어느 10.0.0.0/8 목적지가 어느 터널에 속하는지 구분할 수 없기 때문입니다. 한쪽을 다시 번호 매기거나 변환해야 하며, 그것은 설정 변경이 아니라 네트워크 소유자와의 대화입니다. 겹침은 정직한 답이 “설계를 바꿔야 한다”인 유일한 충돌입니다.

프리픽스가 겹치면 여기서 멈추십시오. 이 목록의 이후 내용은 모두 겹치지 않는다고 가정합니다.

3단계: 유지되는 분리 패턴 고르기

신뢰할 수 있는 패턴은 같은 라우팅 테이블에 두 클라이언트를 돌리는 것을 피합니다. 두 사설 네트워크 모두에 도달하는 분할 터널 정책을 가진 클라이언트 하나가 가장 간단하며, 목적지가 겹치지 않고 정책 소유자가 동의한다면 충분합니다. 가상 머신이나 네트워크 네임스페이스는 그다음 단계입니다. 각각 자체 테이블과 자체 리졸버를 갖기 때문입니다.

sudo ip netns add vpn2
sudo ip netns exec vpn2 ip link show
sudo ip netns exec vpn2 curl -sI https://intranet.corp.example/

네임스페이스는 두 번째 운영 체제 없이 가상 머신과 같은 분리를 제공하지만 거친 부분이 있습니다. 터널 장치를 그 안으로 옮겨야 하고, 애플리케이션을 그 안에서 시작해야 합니다. 관리되는 업무 클라이언트와 함께 개인 VPN을 쓸 때는 별도의 물리 장치가 흔히 가장 덜 놀라운 선택입니다. 터널을 다른 터널 안에 겹쳐 쌓는 것은 분리 패턴이 아닙니다. 안쪽 엔드포인트는 바깥 터널을 통해 계속 도달 가능해야 하고, 이런 구성은 위에 MTU와 지연 문제를 더합니다.

패턴 하나를 고르고 이유를 적으십시오. 한 애플리케이션에는 네임스페이스를, 나머지에는 분할 터널을 섞으면 원래 충돌이 디버그하기 더 어려운 형태로 다시 생깁니다.

4단계: 같은 세션에서 두 네트워크 검증

각 사설 네트워크의 리소스 하나를 애플리케이션이 실제로 실행되는 환경에서 시험하십시오. 앱이 네임스페이스 안에서 실행된다면 자기 셸에서 하지 마십시오. 출구 인터페이스, 확인된 주소, 응답 코드를 함께 점검하십시오. 셋 중 하나의 성공이 다른 것의 실패를 가릴 수 있기 때문입니다. 재부팅 후에도 반복하십시오. 클라이언트가 시작되는 순서가 누가 이기는지를 결정합니다. 사람들이 기록하기를 잊는 부분이 바로 그 순서입니다.

curl -sI https://intranet.corp.example/
curl -sI https://files.personal.example/
ip route get 10.20.30.40

각 네트워크의 클라이언트 버전, 인터페이스, 리졸버 상태, 프리픽스를 기록하십시오. 클라이언트가 업데이트되어 경로 동작이 바뀌면 그 기록이 오 분짜리 수정과 재구축의 차이입니다. 다음 사람은 어느 터널이 먼저 올라왔는지에 대한 당신의 기억을 공유하지 않습니다.

기본 경로를 소유한 인터페이스, 각 이름이 사용하는 리졸버, 두 번째 터널을 분리하는 패턴, 재부팅 후 네트워크마다 한 번의 요청 결과를 말할 수 있으면 목록은 완성됩니다. 그보다 적으면 오늘 우연히 작동하는 설정일 뿐입니다.