VPN 제공업체 이동: IP만이 아니라 호스트 이름을 계획하세요

DNS 레코드는 정확하고 대체 서버는 건강한데도 일부 클라이언트는 몇 시간씩 예전 주소로 접속을 시도합니다. 해석은 되지만 절대 응답하지 않는 이름에 몇몇은 즉시 실패합니다. 두 결과 모두 하나의 틈에서 나옵니다: 호스트 이름은 클라이언트가 무엇을 조회하는지를 바꿀 뿐, 언제 조회하는지나 응답이 도착했을 때 무엇을 신뢰하는지는 바꾸지 않습니다.

증상: 올바른 레코드, 낡은 터널

이름을 저장하는 프로필은 그 이름을 계속 해석하는 클라이언트가 아닙니다. 대부분은 설정 적용 시나 터널이 올라올 때 한 번만 해석하고, 세션이 끝날 때까지 그 주소를 재사용합니다. 그 위에 긴 TTL이 겹치는 것이야말로 전환이 DNS 편집이 아니라 재연결을 중심으로 계획되어야 하는 이유입니다.

두 행동 중 어느 것도 결함이 아니며, 바로 그것이 증상을 혼란스럽게 만듭니다. 클라이언트는 이전에 얻은 응답으로 동작하고, 서버 쪽에는 그것이 어느 응답이었는지 보여 주는 것이 없습니다. 재연결을 유지보수 창에 넣고 사용자에게 무엇을 보게 될지 알리거나, 그 창을 티켓 응답에 쓰십시오. 동일한 보고가 줄을 잇는 것이 흔한 결과입니다.

누가 이름을 통제하며, 클라이언트는 무엇을 검증하는가

존에 대한 통제가 마이그레이션이 얼마나 빨리 움직일 수 있는지를 결정합니다. 로그인할 수 있는 등록기관에 레코드를 두고, 누가 또 그것을 바꿀 수 있는지 적어 두십시오.

신뢰는 이름을 따라가지 않습니다. TLS 기반 클라이언트는 인증서 신원이나 고정된 이름을 확인할 수 있지만, WireGuard는 피어의 공개 키를 인증하고 호스트 이름은 완전히 무시합니다. 그 차이가 DNS 편집으로 충분한지, 아니면 모든 프로필에 새 지문이 필요한지를 결정합니다. 레코드 변경이 아무도 승인하지 않은 엔드포인트를 승인해서는 안 됩니다.

관리 및 복구 접근을 공개 클라이언트 이름과 분리하십시오. 호스팅 계정을 잃는다고 해서 클라이언트를 리디렉션하는 레코드까지 잃어서는 안 됩니다. 복구 경로는 떠나는 제공업체에 의존하지 않는 곳에 보관하십시오.

각 클라이언트가 이름을 다시 읽는 시점

해석 시점은 클라이언트마다 다른 속성이므로, 전환 창을 약속하기 전에 실제로 배포하는 구현을 확인하십시오. wg-quick은 인터페이스가 올라올 때 엔드포인트를 해석하고 터널이 다시 시작될 때까지 그 주소를 유지합니다. OpenVPN 클라이언트는 연결할 때 이름을 조회하며, 재연결 시 다시 볼지는 그 옵션에 달려 있습니다.

모바일 클라이언트는 늘 예상 밖입니다: 절전이나 네트워크 변경을 거치면서 해석된 주소를 계속 들고 있을 수 있기 때문입니다. A와 AAAA 레코드는 대체 서버가 두 패밀리 모두에서 응답할 때만 게시하십시오. 한 패밀리에서 응답하는 주소는 다른 패밀리에 대해 아무것도 증명하지 못하며, 죽은 AAAA 레코드는 모든 시도에 시간 초과를 더합니다. 지원하는 각 클라이언트의 해석 동작을 문서화한 뒤 사람들이 실제로 쓰는 기기에서 시험하십시오.

재연결은 대부분의 클라이언트에서 사용자 행동이며 서버가 강제할 수 없습니다. 그 단계를 유지보수 메모에 넣고, 그것이 일어날 때 사용자가 무엇을 보게 될지 한 줄 덧붙이십시오.

증거에 근거해 전환하고, 그다음 오래된 엔드포인트를 퇴역시키십시오

전환 전에 대체 서버에서 각 계층을 증명하십시오: 리스너가 응답하고, 방화벽이 포트를 통과시키며, 경로가 올바르게 돌아오고, 이름이 새 주소로 해석되며, 알려진 신원이 수락되어야 합니다. 연결을 받아들이는 리스너는 핸드셰이크를 완료하는 리스너와 같지 않으므로 포트가 아니라 핸드셰이크를 시험하십시오. 현재 해지 목록을 설정 옆에 두십시오—복원된 백업은 피어 목록을 예전 그대로 다시 만들고 이미 닫은 접근을 다시 열기 때문입니다. 어떤 신원으로 시험했는지 기록하십시오—«작동한다»는 누구도 재현할 수 있는 증거가 아닙니다.

getent hosts vpn.example.com
ss -lunp | grep 51820
wg show wg0 latest-handshakes

전환 중에는 같은 신원에 대해 두 엔드포인트의 연결 시도를 관찰하십시오. 예전 주소에 대해 여전히 인증하는 클라이언트는 결코 옮겨지지 않은 프로필이나 캐시된 응답입니다. 날짜가 정해진 계획에 따라 오래된 엔드포인트를 퇴역시키십시오—하나의 신원을 받아들이는 두 서비스는 두 개의 문을 열어 두기 때문입니다.

전환 시험은 새 엔드포인트를 통한 애플리케이션 세션이며 ping이 아닙니다. 그 세션이 작동하고 오래된 엔드포인트가 전체 재연결 주기 동안 승인된 시도를 하나도 기록하지 않으면 이동은 끝난 것입니다.