VPN은 연결됐지만 한 서비스만 실패한다: 단계를 분리하라

VPN 티켓에서 «연결됨»은 가장 정보가 적은 사실이다. 두 피어가 핸드셰이크를 마쳤다는 것만 기록하고, 질의한 이름, 패킷이 나간 인터페이스, 그 크기, 또는 원격지가 받아들였는지에 대해서는 아무것도 말하지 않는다. 그래서 같은 노트북의 다른 모든 앱이 동작하는데도 한 서비스만 실패할 수 있다. 단계를 순서대로 밟으면 처음 실패한 단계가 결함을 지목한다.

이름에서 시작하라, 터널이 아니라

라우팅 전에 이름을 해석하라. 나쁜 응답은 이후의 모든 시험을 무의미하게 만들기 때문이다. 시스템 리졸버로 이름을 질의하고 그 응답을 애플리케이션이 실제로 사용한 주소와 비교하라. 사설 이름이 공인 주소로 돌아온다면 질의가 답할 자격이 없는 리졸버로 간 것이다. 해석되지 않는 이름도 같은 범주이며, 다만 더 요란할 뿐이다.

resolvectl query host.internal
getent hosts host.internal

자체 보안 DNS 설정을 가진 브라우저는 여기서 실패하고 나머지 시스템은 동작한다. 그래서 브라우저만의 불만은 누군가 경로를 건드리기 전에 먼저 이 단계에 속한다. 하나가 아니라 두 명령을 모두 비교하라. getent 은 NSS 경로를 따르고 리졸버 질의는 따르지 않는다.

커널에 어느 경로를 골랐는지 물어라

라우팅 테이블은 선호 순서이고, 커널이 고르는 경로가 항상 도식에 그려진 것은 아니다. 해당 목적지에 대해 커널에 직접 물어라. 응답은 인터페이스, 다음 홉, 사용할 소스 주소를 지목한다. 패킷은 원격지가 거부하는 소스 주소를 지닌 채 터널로 나갈 수 있고, 물리 테이블의 더 구체적인 항목이 대신 Wi-Fi 인터페이스로 내보낼 수 있다.

ip route get 10.20.30.40
ip -brief address show

dev, via, src 필드를 이 순서로 읽어라. 각각이 다른 의심을 지우기 때문이다. 이 단계는 비정상 종료 후에도 방화벽 규칙과 경로가 남을 수 있어 클라이언트가 설치한 상태도 담당하며, 그래서 «터널 없이는 인터넷 없음»과 «클라이언트가 실행되지 않으면 인터넷 없음»은 둘이 아니라 한 결함 계열이다.

패킷 크기를 시험하라

큰 전송이 멈추는 동안 작은 응답이 돌아온다면 먼저 경로 MTU를 의심하라. 터널 안에서 보낸, do-not-fragment 비트를 세운 프로브 하나가 이 단계를 나머지와 분리한다. 프로브가 실패할 때까지 페이로드를 올리면 중요한 숫자를 얻는다.

ping -M do -s 1400 10.20.30.40

디렉터리 목록이나 업로드가 멈춰 있는 동안 작은 프로브가 통과하는 것이 이 단계의 서명이다. 불만은 자격 증명이나 방화벽 규칙처럼 들리지만 둘 다 아니다.

그 숫자는 클라이언트가 아니라 경로의 속성이므로 사무실 연결에서 통하는 값이 모바일 링크에서는 실패할 수 있다. 프로브 명령을 티켓과 함께 남겨라. 다음 사람도 같은 측정이 필요하다. 더 작은 페이로드가 통과한다면 해법은 clamp 또는 더 낮은 터널 MTU이지 새 암호가 아니다.

원격지를 시험하라

목적지를 그 주소로 시험하고, 그다음 그곳에서 무엇이 리스닝하는지 보라. 거부된 연결과 결코 응답하지 않는 연결은 다른 발견이다. 전자는 무언가 동작 중이고 그 포트를 서비스하지 않는다고 말하고, 후자는 아무것도 돌아오지 않았다고 말한다. 둘 다 기본적으로 클라이언트 문제가 아니다.

curl -sv http://10.20.30.41:8080/health
nc -vz -w 3 10.20.30.41 3389
ss -lnt 'sport = :8080'

터널로 도달할 수 있는 무엇도 127.0.0.1 에서만 리스닝하는 서비스일 수 없다. 리스너는 패킷을 결코 보지 못하기 때문이다. 원격 호스트의 방화벽이 사무실 서브넷을 허용하고 터널 풀을 거부하면 결과는 클라이언트 결함처럼 보이지만 아니며, 웹 트래픽은 살아 있는데 원격 데스크톱이나 파일 공유가 깨지는 경우는 대개 여기로 떨어지고, 사용자가 어떻게 표현하든 마찬가지다.

불만을 한 단계에 대응시켜라

대부분의 보고는 다섯 가지 형태 중 하나로 모이고, 각 형태가 한 단계를 지목한다. 터널로만 동작하는 사이트 하나는 이름 응답이거나 소스 주소에 묶인 정책이다. 터널 없이 업데이트가 실패하고 탐색은 동작한다면 그 클라이언트의 이름이나 경로 문제다.

공급자 클라이언트가 시작될 때 모든 것이 멈추는 것은 설치된 상태, 즉 경로와 방화벽 문제다. 나머지는 정상인데 한 서비스에 닿지 못하는 것은 원격지다. 전송이 몇 초 만에 멈추는 것은 패킷 크기다. 명령을 실행하기 전에 형태를 맞춰라. 어떤 증거를 먼저 모을지가 여기서 정해진다.

첫 실패를 만든 단계를 명령 출력과 함께 기록하라. 소스 주소가 틀렸다고 말하며 경로 줄을 첨부한 티켓은 조치할 가치가 있지만, VPN이 망가졌다고 보고하는 티켓은 그렇지 않다.