터널은 올라와 있는데 프라이빗 이름은 왜 여전히 실패할까?

연결은 모든 면에서 정상으로 보입니다. 터널은 올라와 있고 콘솔은 프라이빗 엔드포인트를 보여 주지만, 모든 요청이 이름 확인에서 실패합니다. 자연스러운 행동은 터널을 탓하는 것이지만, 보통 터널은 결백합니다. 질의는 프라이빗 영역에 대해 아무것도 모르는 서버로 전송되고 있습니다. 어떤 라우팅 변경도 그 응답을 바꾸지 못합니다. 문제는 누구에게 물었는가이기 때문입니다.

질의는 어느 리졸버에 도달했는가?

터널을 보기 전에 각 링크에 연결된 리졸버를 찾으십시오. Linux는 리졸버 상태 명령으로 링크별 서버를 보여 주고, macOS는 DNS 구성 덤프에서 범위가 지정된 리졸버를 보여 줍니다. 응답이 여전히 집 라우터에서 온다면 터널 링크는 한 번도 사용되지 않은 것입니다.

resolvectl status
scutil --dns | head -40
dig +short internal.example.com

여기서 두 단계가 뒤섞입니다. 리졸버 주소를 밀어 넣는 서버와, 그것을 활성 링크에 설치하는 클라이언트입니다. 프로필에 옵션이 있고 로그에 도착이 보여도, 운영 체제는 계속 예전 서버를 사용할 수 있습니다. 로그와 링크가 보고하는 내용을 비교하고, 링크를 신뢰하십시오.

클라우드 네트워크가 실제로 응답하는 주소를 사용하십시오

클라우드 네트워크는 보통 범위의 기준에서 두 칸 떨어진 예약 주소로 프라이빗 이름에 응답하므로, 10.0.0.0에서 시작하는 네트워크는 10.0.0.2에서 응답합니다. 일부 공급자는 범위를 몰라도 작동하는 링크 로컬 리졸버도 게시하며, 네트워크를 다른 사람이 구축했을 때 도움이 됩니다. 후보 주소를 누구에게 밀어 넣기 전에 직접 질의하십시오. 리졸버가 아닌 주소는 방화벽 드롭과 똑같이 보입니다. 질의가 결코 응답을 받지 못하기 때문입니다.

직접 질의가 네트워크 내부에서는 응답하지만 터널을 넘어서는 응답하지 않는다면, 리졸버는 정상이고 두 지점 사이의 경로가 정상이 아닙니다. 그 결과는 조사를 클라이언트 프로필이 아니라 라우트, 전달, 액세스 규칙으로 옮깁니다.

터널은 이름 공간을 운반하지 않습니다

패킷은 지나가지만 이름은 지나가지 않습니다. 각 측에 어느 이름 공간이 상대 측에 속하는지 알려야 하며, 그것은 영역을 가진 사람이 소유하는 별개의 객체입니다. 보통의 형태는 하나의 이름 공간에 대한 전달을 터널을 통해 도달 가능한 리졸버로 향하게 하는 것입니다.

실제로 각 방향에는 자체 규칙이 필요합니다. 영역을 소유한 측이 질의를 보내야 하기 때문입니다. 두 방향 모두 질의 원본이 라우팅되고 허용되어야 하며, 응답하는 측은 응답을 인터넷이 아니라 터널을 통해 돌려보내야 합니다. 전달을 좁게 유지하여 프라이빗 이름 공간만 링크에 의존하게 하십시오. 모든 질의를 그리로 보내면 터널이 끊어지는 순간 작은 의존성이 전면 중단으로 바뀝니다.

경계를 순서대로 짚어 보십시오

활성 링크에 설치된 리졸버, 그다음 그 리졸버로의 직접 질의, 그다음 반대편에서의 같은 질의, 마지막으로 같은 이름을 쓰는 애플리케이션을 시험하십시오. 각 단계는 하나의 경계를 분리하므로, 실패하면 조사를 다시 시작하는 대신 어디를 봐야 하는지 알려 줍니다. 애플리케이션이 실패하는데 응답이 성공한다면 DNS가 아니라 인증서 신뢰나 API 정책을 가리킵니다. 그 장애는 실제이며 어떤 리졸버 변경으로도 고쳐지지 않습니다.

어느 단계가 실패했는지 적으십시오. 그 한 줄이 다음 사람에게 필요한 것이며, 기록하는 데 십 초면 충분합니다.

다음 사람이 찾을 수 있는 곳에 연쇄를 남기십시오

밀어 넣은 리졸버, 전달 규칙, 허용된 질의 원본, 응답하는 엔드포인트를 한곳에 기록하십시오. 프라이빗 이름이 다시 실패하면, 기록은 터널이 이동했는지, 리졸버 주소가 바뀌었는지, 규칙이 좁아졌는지 보여 줍니다. 그것이 없으면 모든 장애가 처음부터 시작해 같은 세 가지 추측으로 끝납니다.

기록은 정확하게 유지될 만큼 짧게 쓰십시오. 네 줄, 날짜, 각 부분의 소유자 이름입니다. 오래된 기록은 없는 것보다 나쁩니다. 틀렸는데도 권위 있어 보이기 때문입니다.