ddclient가 VPN 출구를 게시합니다: 검색 원본을 바로잡으세요
웹 프로브는 자기가 보는 주소를 보고하므로 전체 터널 VPN은 제공자의 출구를 게시할 수 있습니다. 먼저 종단점을 고르고, 그다음 검색을 거기에 맞추세요.
DNS 이름이 이제 VPN 제공자의 주소로 확인되고, 업데이트 로그는 완전히 정상으로 보입니다. 이 조합은 정상입니다. 웹 기반 검색 프로브는 외부 서비스에 어떤 원본이 보이는지 묻고, 요청이 전체 터널 VPN을 통해 나가면 답은 집의 WAN 주소가 아니라 VPN 출구가 됩니다. 업데이터는 제 일을 했고, 그 일은 잘못된 관측을 향해 있었습니다.
이름이 무엇에 도달해야 하는지 확인하세요
들어오는 홈 서비스를 위한 공개 이름에는 승인된 인바운드 연결이 그 서비스에 도달할 수 있는 주소가 필요합니다. 공유 제공자 출구를 게시해도 거기에 인바운드 전달이 마련되지 않으며, 어떤 DNS 설정도 그 전달을 만들어 내지 않습니다. 업데이터를 건드리기 전에 이것을 정하세요. 어느 주소가 올바른지가 여기서 결정됩니다.
VPN 클라이언트의 터널 주소를 위한 사설 이름은 다른 답을 가진 다른 문제입니다. 그것은 사설 DNS에 속하며 공개 검색 서비스가 전혀 필요하지 않습니다. 두 요구를 섞는 것이 바로 동작하는 구성이 아무도 요청하지 않은 주소를 게시하기 시작하는 방식입니다.
인터페이스 주소도 해석이 필요합니다. 홈 라우터 뒤의 노트북 주소는 공인 WAN 주소가 아니며, 라우터의 WAN 주소조차 통신사급 NAT 뒤에 있을 수 있고, 거기서는 게시해도 인바운드 도달성이 생기지 않습니다.
무엇이든 바꾸기 전에 값을 재현하세요
두 경로를 따로 관찰하세요. 터널이 올라가 있으면 프로브는 출구를 보고하고, 터널이 내려가 있거나 프로브가 물리 인터페이스에 묶여 있으면 집 주소를 보고합니다: curl --interface eth0 https://ifconfig.me. 이 두 답이 다르면 업데이터를 건드리지 않고도 결함을 재현한 것입니다.
그다음 업데이트를 수행하지 않고 구성을 점검하는 모드로 클라이언트를 실행하세요. 예를 들어 ddclient -verbose -noexec처럼 하고, 어떤 검색 방법을 골랐는지 읽으세요. 자세한 출력은 방법과 얻은 값을 알려 주며, 그것이 무엇이든 편집하기 전에 필요한 사실입니다.
검색을 선택한 경로로 향하게 하세요
이름이 집의 WAN 주소를 게시해야 한다면 검색은 바로 그 주소를 관찰해야 합니다. 대략 선호 순서로 세 가지 선택지가 있습니다. 라우터가 자체 지원 업데이터로 게시하게 하세요. 라우터가 실제로 제공하는 페이지를 대상으로 ddclient의 라우터 상태 검색을 사용하세요. 또는 웹 프로브를 유지하되 터널 밖으로 나가도록 물리 인터페이스에 묶으세요.
라우터 상태 경로에서는 최신 ddclient가 usev4와 fwv4 옵션 계열을 사용하며, 주변 페이지 텍스트를 위한 선택적 건너뛰기 패턴도 있습니다. 설치한 버전의 README를 확인하세요. 오래된 릴리스는 같은 개념을 use와 fw로 적으며, 잘못된 릴리스에서 복사한 옵션 이름은 시작할 때 실패합니다.
웹 검색을 유지한다면 프로브의 라우팅과 업데이트 API 호출의 라우팅은 별개의 결정임을 기억하세요. 업데이트 호출이 레코드를 전달하고, 프로브가 전달될 값을 정합니다.
비밀과 버전을 정돈하세요
라우터 자격 증명과 제공자 토큰은 보호된 구성 파일에 두어야 하며, 셸 기록에 남는 명령줄에 두면 안 됩니다. 자세한 추적에는 둘 다 들어갈 수 있으니 티켓에 붙이기 전에 가리세요. 인증된 라우터 페이지를 긁어야 하는 검색 방법은 펌웨어 업데이트를 거쳐도 그 자격 증명이 계속 동작해야 함을 요구합니다. 제공자 토큰과 같은 주의로 보관하세요.
ddclient README 는 검색 접근 방식과 그 옵션 이름을 문서화합니다. 한 레코드에 IPv4와 IPv6 결과를 섞지 말고, 한 릴리스에 있는 옵션이 다른 릴리스에도 있다고 가정하지 마세요.
값을 검증하고, 그다음 도달성을 확인하세요
실시간 업데이트를 허용하기 전에 제안된 주소를 의도한 종단점과 비교하고, 승인된 업데이트를 한 번 한 뒤 권한 있는 DNS를 확인하며 리졸버 캐시를 감안하세요. 낮은 TTL은 기다림을 줄일 뿐, 잘못된 값을 옳게 만들지는 않습니다.
레코드가 올바른 뒤에야 필요한 방화벽과 전달이 이미 승인된 상태에서 독립된 네트워크로 인바운드 서비스를 시험하세요. 올바른 A 레코드는 도달 가능한 서비스를 증명하지 않으며, 고정 VPN 임차는 사설 이름 지정을 단순하게 할 수 있지만 잘못된 WAN을 가리키는 공개 호스트 이름을 고치지는 않습니다.