MagicDNS가 기기를 확인하면서 사무실 호스트 이름은 확인하지 못하는 이유

MagicDNS는 tailnet 안의 각 기기에 머신 이름과 tailnet의 DNS 도메인에서 파생된 이름을 부여합니다. 그 이름은 Tailscale이 만들고 Tailscale의 확인자 경로를 따라 응답됩니다. files.office.example 같은 사무실 호스트 이름은 Tailscale이 기록한 적 없는 영역에 속하므로 기기 이름을 바꿔도 만들 수 없습니다. 두 이름 공간은 공존하며, 소유자만 다를 뿐입니다.

그 메커니즘은 아주 흔한 신고 뒤에 있습니다: Tailscale 호스트는 응답하는데 파일 서버는 여전히 확인 오류를 반환합니다.

두 이름 공간, 두 소유자

기기 이름은 머신 자체의 호스트 이름에서 생성되고, 충돌은 Tailscale이 해결하며, 결과는 tailnet 도메인 아래에 있습니다. 사무실 영역은 사무실 확인자를 운영하는 사람이 유지하며, 레코드는 관리자나 동적 등록으로 만들어집니다. 짧은 이름은 차이를 숨깁니다: files은(는) 사무실 DNS가 응답하는 검색 접미사 확장일 수도, tailnet 기기일 수도, 아무것도 아닐 수도 있습니다. 전체 이름을 조회하면 어느 시스템이 실제로 응답했는지 드러납니다.

서브넷 라우터의 머신 이름을 바꾸는 것은 사무실 영역에 아무 효과가 없습니다. Tailscale 기기 하나의 이름만 바꾸고 사무실 서버의 레코드는 그대로 두므로, 이름을 바꾸고 다시 시도해도 결코 일치하지 않습니다.

사무실 영역을 그 확인자로 향하게 하십시오

Tailscale의 분할 DNS는 선택한 도메인의 조회를 지정한 이름 서버로 보내고, 나머지는 남은 정책을 따릅니다. 추가할 것은 사무실 확인자가 실제로 서비스하는 도메인이지, 우연히 입력한 검색 접미사가 아닙니다. 검색 접미사는 클라이언트에 무엇을 덧붙일지 알려 주지만, 확인자에게 어디를 볼지는 알려 주지 않습니다. 이 두 설정은 콘솔에서 비슷해 보이지만 전혀 다르게 동작합니다.

제한된 이름 서버는 연결된 도메인에 대해 권한이 있어야 하며, 그렇지 않으면 응답은 주소가 아니라 위임이 될 것입니다.

접근성이 확인보다 먼저입니다

클라이언트도 그 이름 서버에 도달해야 합니다. 사설 LAN의 확인자라면 서브넷 경로를 광고하고 수락해야 하며, 접근 정책이 조회를 허용해야 하고, 반환 경로가 있어야 합니다. 관리 콘솔의 올바른 DNS 주소는 구성이 저장되었다는 것만 증명합니다. 패킷이 확인자에 도달하지 못하면 증상은 시간 초과이며, 그런 레코드가 없다는 권위 있는 응답과는 다르게 보입니다.

그 차이는 진단적입니다. 시간 초과는 라우팅이나 정책을 가리키고, 즉각적인 부정 응답은 레코드나 영역을 가리킵니다. DNS 설정을 바꾸기 전에 어느 쪽을 받는지 읽어 보십시오.

이름 실패와 서비스 실패를 분리하십시오

리소스가 사설 주소에서는 응답하지만 호스트 이름으로는 응답하지 않으면 조사는 DNS에 머뭅니다. 둘 다 안 되면, 도달할 수 없는 주소로 확인되는 이름은 진전이 아니므로 먼저 라우팅이나 서비스를 고치십시오. 전체 이름을 조회하고 어느 서버가 응답했는지 기록하십시오. macOS에서는 일부 명령줄 도구가 일반 응용 프로그램과 다른 경로를 탑니다, 그래서 터미널 dig과 브라우저가 같은 이름에 대해 의견이 다를 수 있습니다.

기기의 정상 모드가 그것이라면 출구 노드를 선택한 상태로 시험을 반복하십시오. 출구 노드의 DNS 처리는 출구가 없는 구성과 다르며, 한 가지 모드에서만 시험하면 사용자가 실제로 보는 실패를 놓칠 수 있습니다.

영역, 확인자 주소, 조회를 나르는 경로를 기록하십시오. 이 세 가지면 이름 바꾸기를 한 번 더 하지 않고도 대부분의 MagicDNS 의문이 풀립니다.