동적 DNS가 잘못된 공인 IP 주소로 업데이트되는 이유는 무엇인가요?

동적 DNS는 업데이트 프로그램이 원격 클라이언트가 도달해야 하는 인터페이스나 인터넷 출구와 다른 것을 관찰할 때 잘못된 주소를 업데이트합니다.

가정 네트워크에서는 라우터가 다른 게이트웨이 뒤의 사설 WAN 주소를 보고할 수 있고, 서버 측 업데이트 프로그램은 VPN이나 프록시 출구를 볼 수 있으며, IPv6 업데이트 프로그램이 IPv4 레코드를 덮어쓸 수 있고, 두 클라이언트가 서로 다른 위치에서 같은 호스트명을 업데이트할 수도 있습니다. 진단은 하나의 공용 주소 출처를 진실로 선택한 후, 어떤 업데이트 프로그램, 레코드, 주소 체계, 감지 방법이 잘못된 값을 생성했는지 정확히 파악하는 것부터 시작합니다.

세 가지 주소를 동시에 비교하기

DDNS 레코드, 라우터의 WAN 주소, 외부 IPv4 또는 IPv6 서비스가 관찰한 공용 주소를 기록하세요. 최근의 정상적인 변경이 잘못된 업데이트로 오인되지 않도록 타임스탬프를 추가하세요.

TP-Link 커뮤니티 사례에서는 라우터가 제공자 NAT 풀의 주소를 보고하는 반면 외부 인터넷은 다른 주소를 보아 DDNS 호스트명이 잘못된 WAN 측 주소를 가리키는 경우가 있었습니다.

세 주소가 모두 일치하면 문제는 업데이트 값보다는 DNS 캐싱이나 원격 접근성 문제일 가능성이 큽니다. DDNS 레코드가 라우터와 일치하지만 외부 주소와 다르면 상위 NAT를 조사하고, 둘 다 일치하지 않으면 업데이트 프로그램 설정과 로그를 점검하세요.

업데이트 프로그램이 주소를 감지하는 방법 파악하기

DDNS 클라이언트가 명명된 인터페이스를 읽는지, 라우터에 묻는지, 로컬 게이트웨이를 파싱하는지, 업데이트 요청의 출발지 주소를 사용하는지, 아니면 외부 “내 IP가 무엇인가” 서비스에 질의하는지 확인하세요.

Zyxel 커뮤니티 토론에서는 방화벽이 다른 NAT 라우터 뒤에 있을 때 상위 사설 WAN 주소만 알 때 진짜 공용 주소를 자동으로 업데이트할 수 없는 이유를 묻고 있습니다.

업데이트 프로그램이 NAT 뒤에 있고 제공자가 지원한다면 외부 감지를 선택하세요. 해당 인터페이스가 실제로 공용 주소를 소유할 때만 인터페이스 감지를 선택하세요. 그렇지 않으면 완벽히 작동하는 업데이트 프로그램도 설계상 잘못된 값을 게시할 수 있습니다.

이중 NAT 및 CGNAT 확인하기

라우터 WAN 주소가 사설 또는 공유 범위 내에 있는지, 또 다른 모뎀이나 ISP 게이트웨이가 첫 번째 NAT를 수행하는지 점검하세요. 동적 DNS는 주소를 게시할 수 있지만, 제어하지 않는 상위 네트워크를 통한 인바운드 포워딩을 생성할 수는 없습니다.

독일 Synology 지원 포럼 사례에서는 제공자 NAT 때문에 DDNS가 실제 공용 엔드포인트가 아닌 주소를 감지한 경우가 보고되었습니다.

상위 라우터를 제어할 수 있다면 하위 라우터를 브리지 모드로 설정하거나 두 계층 모두를 통해 필요한 경로를 포워딩하세요. ISP가 CGNAT를 사용한다면 공용 주소를 요청하거나 DDNS 클라이언트를 반복 변경하는 대신 아웃바운드 터널이나 릴레이를 사용하세요.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

IPv4와 IPv6 업데이트 분리하기

A 및 AAAA 레코드를 독립적으로 점검하고 각 주소 체계에 대해 외부 테스트와 비교하세요. 하나의 성공적인 IPv6 업데이트가 IPv4 레코드가 올바르다는 증거가 아님을 가정하지 마세요.

한 인터페이스를 모니터링하도록 구성된 클라이언트는 임시 IPv6 주소, 나중에 변경되는 위임 프리픽스 주소, 또는 VPN 출구의 IPv4 주소를 게시할 수 있습니다. 주소 체계별로 업데이트 작업과 제공자 레코드를 분리하세요.

의심되는 주소 체계 업데이트만 비활성화하고 테스트를 반복하세요. 잘못된 AAAA 또는 A 레코드를 제거했을 때 원격 접근이 복구되면, 이 경로를 복구한 후 듀얼 스택 DNS를 복원하세요.

중복 클라이언트 및 잘못된 레코드 대상 찾기

호스트명을 업데이트할 자격 증명이 있는 모든 라우터, NAS, 컨테이너, 스크립트, 클라우드 호스트, 모바일 장치를 목록화하세요. 서로 다른 위치에 있는 두 개의 유효한 클라이언트가 서로를 반복해서 덮어쓸 수 있습니다.

Dynu 사용자들은 한 업데이트 클라이언트가 여러 레코드를 하나의 IP로 덮어쓴 사례를 문서화했는데, 이는 계정이나 클라이언트 설정이 의도보다 더 많은 레코드를 대상으로 했기 때문입니다.

각 위치와 주소 체계에 고유한 호스트명, 토큰, 업데이트 작업을 부여하세요. 사용하지 않는 자격 증명을 취소하고 성공 메시지를 신뢰하기 전에 로그가 변경되는 정확한 레코드를 명시하는지 확인하세요.

실제 주소 변경을 통해 레코드 검증하기

감지 방법과 업데이트 프로그램 소유권을 수정한 후 안전한 WAN 재연결을 강제하거나 다음 정상 주소 변경을 기다리세요. 새 외부 주소, 업데이트 로그, 권한 있는 DNS 응답, 재귀적 해석기 응답, 원격 연결 결과를 기록하세요.

ZimaSpace의 원격 접근이 오래된 IP 상태를 따르는 이유 가이드는 DDNS 값 자체가 올바르게 된 후 다음 단계를 제공합니다.

문제는 승인된 한 개의 업데이트 프로그램이 올바른 IPv4 또는 IPv6 주소를 게시하고, 두 번째 클라이언트가 이를 덮어쓰지 않으며, 권한 있는 응답이 예상 간격 내에 변경되고, 외부 클라이언트가 의도한 가정 서비스를 도달할 때만 해결됩니다.