DNS 변경 후에도 WireGuard가 이전 엔드포인트를 계속 사용함

서버의 DNS 레코드가 옮겨진 뒤 터널이 트래픽을 전달하지 못했지만, 같은 머신에서 이름은 올바르게 확인됩니다. 이 두 사실은 서로 모순되지 않습니다. WireGuard 구성은 엔드포인트를 담고 있고, 도구는 그 구성을 적용하는 순간 이름을 확인하므로 실행 중인 인터페이스는 몇 시간 전에 조회한 주소를 계속 사용할 수 있습니다. 키를 바꾸거나 터널 범위를 건드리기 전에 인터페이스가 무엇을 쓰는지 확인하세요.

이름은 한 번만 확인되며 계속 확인되지 않음

WireGuard 기본 구성은 엔드포인트를 주소와 포트로 받고, 인터페이스를 올리는 도구는 그 시점에 호스트 이름을 확인합니다. 기본 프로토콜에는 DNS를 일정에 따라 조회하는 동작이 없으며, 클라이언트 애플리케이션이 그 위에 자체 갱신 동작을 추가할 수 있습니다. 확인된 주소와 주소 체계, 포트를 이름 옆에 기록하면 그 간극이 드러납니다. 그 기록이 없으면 인터페이스가 다른 곳과 통신하는 동안 구성은 올바르게 보입니다.

실제 자동 갱신이 하나 있는데, DNS 갱신처럼 보이지만 그렇지 않으므로 알아 둘 만합니다. 올바르게 인증된 트래픽이 새 주소에서 도착하면 피어 엔드포인트가 이동할 수 있으며, 이것은 이름 확인이 아니라 로밍입니다. 피어를 따라가므로 이전 엔드포인트가 한 번도 접촉한 적 없는 무관한 새 서버를 발견할 수 없습니다.

레코드와 사용 중인 주소를 비교하세요

클라이언트가 사용하는 리졸버로 문서화된 이름을 조회한 다음, 인터페이스에 어떤 엔드포인트를 보유하는지 물어보고, 이 두 응답을 이 페이지의 나머지를 결정하는 비교로 삼으세요.

dig +short vpn.example.net
wg show wg0 endpoints
wg show wg0 latest-handshakes

이 줄들이 사용하는 show 하위 명령은 wg(8) 매뉴얼에 문서화되어 있습니다. 주소뿐 아니라 주소 체계도 비교하세요. IPv6 항목이 추가된 레코드는 IPv4 주소가 바뀐 레코드와 다른 비교이기 때문입니다. 엔드포인트가 레코드와 다르면 인터페이스는 오래된 정보로 동작하는 것이고 이름은 문제가 아니었습니다. 둘이 일치하는데도 터널이 계속 실패하면 프로필이 아니라 리스너와 규칙으로 넘어가세요.

핸드셰이크 타임스탬프가 그 블록에 있는 이유는 엔드포인트만으로는 피어에 도달할 수 있는지 알 수 없기 때문입니다. 올바른 엔드포인트 옆의 오래된 타임스탬프는 경로 문제이지 확인 문제가 아니며, 이 구분이 다음에 무엇을 건드릴지 바꿉니다.

인터페이스 관리자를 통해 다시 시작하세요

엔드포인트가 오래된 것으로 확인되면, 인터페이스를 소유한 메커니즘을 통해 갱신하세요. 실행 중인 구성을 직접 편집하는 대신에, wg-quick로 시작한 인터페이스라면 내렸다 올리고, systemd 유닛이라면 재시작하며, 관리자가 소유한 인터페이스라면 그 관리자에서 변경하며 — 실행 중 편집은 다음 적용 때 덮어써지기 때문입니다:

wg-quick down wg0 && wg-quick up wg0
systemctl restart wg-quick@wg0

그다음 교체된 리스너와 그 정체가 의도한 서비스인지 확인하세요. DNS 이동은 정체 변경이 아니므로 검증하지 않은 키를 신뢰할 계기여서는 안 됩니다. 인터페이스가 이제 새 주소를 보고하는데도 핸드셰이크가 생기지 않는다면, 결함은 새 네트워크 경로나 리스너로 옮겨간 것이며 이는 같은 결함의 반복이 아니라 진전입니다.

먼저 핸드셰이크, 그다음 데이터 경로

점검 목록을 고르기 전에 두 결과를 분리하세요. 실패하는 애플리케이션 아래에서 성공하는 핸드셰이크는 데이터 경로 문제입니다. 라우트, 허용된 프리픽스, 터널 내부의 DNS 같은 것입니다. 핸드셰이크가 전혀 일어나지 않는다면 엔드포인트의 도달 가능성이나 정체 문제입니다. 둘을 섞으면 아무도 재현할 수 없는 보고서와 서로 무관한 편집 세 개가 담긴 변경 기록이 나옵니다.

이름, 확인된 주소, 사용 중인 엔드포인트, 핸드셰이크 완료 여부를 기록하세요. 이 네 가지 사실이 이 결함이 계속 던지는 질문에 답하며, 다음 발생을 몇 분짜리 점검으로 바꿉니다. 이름 유지보수와 클라이언트 도입은 별개의 작업으로 남습니다. 레코드를 고쳐도 도입이 이루어지지 않고, 인터페이스를 다시 시작해도 여전히 잘못된 레코드는 고쳐지지 않습니다.