오래된 DDNS 레코드와 고장 난 VPN 엔드포인트: 구별하는 방법

밖에서 보면 오래된 호스트 이름과 고장 난 VPN은 똑같아 보입니다. 클라이언트가 이름을 해석하고, 그 이름이 어딘가를 가리키고, 연결은 시간 초과되거나 거부됩니다. 하나는 DNS 갱신 문제이고 다른 하나는 인증이나 전달 문제이며, 그 차이는 공개된 주소와 회선이 실제로 가진 주소를 비교할 때에야 분명해집니다.

같은 방식으로 드러나는 두 고장

첫 번째 고장은 레코드에 아직 어제의 WAN 주소가 적혀 있다는 것입니다. 두 번째는 레코드가 올바르고 터널이 나름의 이유로 연결을 거부한다는 것입니다. 둘 다 클라이언트에 같은 메시지를 내보내며, 인증서를 다시 만들기 시작하고 싶어집니다.

여기서는 순서가 중요합니다. DNS 확인은 일 분이면 되고 되돌릴 수 있습니다. CA 재생성은 둘 다 아닙니다.

무엇보다 먼저 주소를 비교하십시오

회선이 지금 어떤 주소를 가지는지 네트워크 소유자에게 묻고, 그다음 DNS가 무엇을 공개하는지 물으십시오. dig +short vpn.example.com은 클라이언트가 받을 답을 주고, dig @1.1.1.1 vpn.example.com은 다른 리졸버가 다른 것을 보는지 보여 줍니다. 이 둘이 서로 다르다면, 고장 난 갱신기가 아니라 캐시 동작을 보고 있는 것입니다.

재귀 응답은 자기 TTL만큼 갱신보다 뒤처질 수 있으므로, 권한 있는 레코드와 노트북이 캐시한 내용을 별도의 상자에 보관하십시오.

갱신기의 자격 증명은 실제로 무엇인가

오래된 DDNS 장치는 계정 비밀번호 자체로 인증하는 경우가 많고, 그래서 그 비밀번호를 바꾸면 조용히 망가집니다. 장치는 예전 값으로 계속 재시도하고 쓸모 있는 것은 아무것도 보고하지 않습니다. No-IP의 장치 비밀번호 안내는 오래된 하드웨어에서 바로 이 호환성 문제를 문서화하며, 합리적인 대응은 더 약한 계정 비밀번호가 아니라 범위가 제한된 갱신 자격 증명입니다.

더 새로운 방식은 자체 수명 주기를 가진 별도의 갱신 토큰이나 키를 발급합니다. 그것이 라우터로 교체해 넣어야 할 값이고, 자격 증명 목록에 기록해야 할 값입니다. 디버깅하는 동안 채팅 스레드에 붙여 넣을 값도 아닙니다.

갱신기의 비밀이 아닌 상태를 확인하십시오. 마지막 성공 시각, 응답 분류, 그리고 자기가 소유한다고 생각하는 호스트 이름입니다. 자격 증명 거부와 연결성 장애는 서로 다른 수정이 필요합니다.

DNS 수정으로 할 수 없는 일

레코드를 바로잡아도 인바운드 도달 가능성은 생기지 않습니다. 회선이 통신사 수준 NAT 뒤에 있다면 어떤 호스트 이름도 인바운드 연결을 되게 하지 못합니다. 방화벽 규칙을 열지도 않고 포트를 전달하지도 않습니다. 그리고 클라이언트의 서버 검증을 끄는 이유가 되어서는 결코 안 됩니다. 인증서가 원인이라고 단정할 때 사람들이 하는 행동이 바로 그것입니다.

반대로 VPN 비밀번호 변경은 오래된 DNS의 수정이 아닙니다. 같은 티켓에 두 번째 고장을 더할 뿐입니다.

다시 연결하고 처음부터 끝까지 증명하십시오

권한 있는 레코드가 올바르게 되면, 클라이언트가 아직 오래된 조회 결과를 들고 있을 수 있습니다. 지원되는 다시 연결이나 엔드포인트 갱신을 사용하고, 연결을 계속 누르는 대신 잠깐 기다리십시오. 그다음 경로를 네 단계로 증명하십시오. 이름을 해석하고, 주소를 확인하고, 리스너에 닿는지 확인하고, 인증하십시오. 네 가지 별개의 결과, 네 가지 별개의 답입니다.

갱신기를 VPN 계정 옆의 교체 점검 목록에 두십시오. 의도된 단일 레코드 소유자, 유효한 자격 증명, 그리고 관찰 가능한 성공이 이 티켓의 다음 판을 막습니다.