resolvectl 출력에서 링크별 VPN DNS 라우팅을 읽는 방법

resolvectl status 를 실행하면 링크별 블록이 벽처럼 늘어서고, 각 블록에는 고유한 서버와 고유한 도메인 줄이 있습니다. 라우팅을 결정하는 줄은 도메인 목록이며 이름 서버 주소가 아니라, 로컬 스텁이 그 이름을 주장하는 링크로 모든 질의를 전달하기 때문입니다. 응답을 읽기 전에 그 주장을 읽고, 그다음 이름을 질의해 어느 링크가 그것을 만들었는지 확인하십시오. 올바른 링크에서 나온 잘못된 응답은 잘못된 링크에서 나온 올바른 응답과 다른 문제입니다.

링크별 각 블록이 알려 주는 것

각 블록은 리졸버가 그 인터페이스에 사용할 서버, 도메인 목록, 그리고 그 링크가 기본 경로인지 보여 줍니다. 도메인 목록은 주장의 집합이고 리졸버는 가장 긴 접미사 일치를 적용하므로, host.corp.example 에 대한 질의는 기본 경로만 가진 링크보다 corp.example 을 가진 링크가 먼저 주장합니다. 같은 접미사를 주장하는 두 링크는 결과를 우선순위와 순서에 맡기므로, 중복에 먼저 주의를 기울일 가치가 있습니다. 현재 서버 줄은 나열된 서버 중 어느 것이 그 순간 사용되는지 보여 줍니다.

/etc/resolv.conf 의 127.0.0.53 같은 스텁 주소는 스텁이 앞에 있다는 것만 말합니다. 응답한 상위 원본을 밝히지 않으므로 resolv.conf 만에 근거한 진단은 막힙니다.

세 가지 도메인 항목을 올바르게 읽기

틸데는 검색 동작을 바꾸고 라우팅은 바꾸지 않습니다. 틸데가 없는 항목은 라우팅 도메인이자 검색 도메인이라서, 그 아래 이름은 그 링크로 보내지고 단일 레이블 이름에는 접미사가 덧붙습니다. 틸데 항목은 같은 접미사를 라우팅하면서 검색 목록에서는 제외합니다. 그래서 틸데를 제거하면 어떤 맨이름이 해석되는지가 달라지고, 그래서 틸데가 빠진 것은 검색 문제이지 분할 DNS 의 실패가 아닙니다.

기본 경로 항목은 다른 어떤 링크도 일치하지 않는 모든 것을 주장합니다. 전체 터널 프로필은 보통 그것을 원하고 분할 프로필은 보통 원하지 않는데, 공개 이름이 그러면 사설 리졸버로 가서 거기서 실패할 수 있기 때문입니다. 프로필 사이에서 플래그를 복사하는 대신 프로필의 의도에 비추어 표를 읽으십시오. 두 링크가 같은 접미사를 주장하면 다른 무엇을 편집하기 전에 우선순위 문제를 정리하십시오.

이름을 질의하고 어느 링크가 응답했는지 보기

query 하위 명령은 주소, 프로토콜, 그리고 응답을 만든 링크 또는 범위를 인쇄합니다. 사설 접미사가 주장해야 할 이름 하나와 평범한 공개 이름 하나를 시험하고, 보고된 출처를 비교하십시오. 사설 이름이 무선 링크에서 응답하면 주장이 빠졌거나 터널이 내려간 것이고, 분할 프로필에서 공개 이름이 터널에서 응답하면 기본 경로가 너무 넓습니다. 그 두 실패는 브라우저에서는 같게 보이고 이 출력에서는 반대로 보입니다.

resolvectl status
resolvectl query host.corp.example

보고된 프로토콜도 지켜보십시오. 캐시나 hosts 파일의 응답은 어떤 상위 원본에도 묻지 않고 도착할 수 있고, 캐시의 응답은 그 이름이 언젠가 해석되었다는 것을 증명할 뿐 현재 정책이 그것을 올바르게 라우팅한다는 것은 아닙니다.

이름 라우팅과 패킷 라우팅을 분리하기

리졸버의 결정은 경로를 만들지 않습니다. 선택된 서버에는 여전히 자기 주소로 가는 경로가 필요하고, 돌려받은 주소에는 여전히 사설 네트워크로 가는 경로가 필요하므로, 올바른 DNS 정책은 결코 열리지 않는 연결과 공존할 수 있습니다. 이름이 해석되는데 응용 프로그램이 실패하면 DNS 를 다시 바꾸지 말고 주소와 경로를 점검하십시오. 이름 해석과 도달 가능성은 서로 다른 주인을 가진 두 질문입니다.

응용 프로그램은 자체 보안 DNS 설정이나 함께 제공되는 리졸버를 통해 시스템 리졸버를 완전히 우회할 수 있습니다. resolvectl 결과는 시스템 경로를 설명하고, 그것을 무시하는 브라우저는 당신이 하는 모든 시험과 어긋납니다. 정책이 깨졌다고 결론 내리기 전에 그 설정을 확인하십시오.

이름이 해석된 주소를 링크 옆에 기록하십시오. 잘못된 주소를 가리키는 올바른 이름은 라우팅이 아니라 레코드 문제입니다.

링크가 바뀐 뒤 다시 확인하기

다시 연결하거나 무선을 바꾸면 링크 상태가 다시 만들어지고, 네트워크 관리자가 수동으로 설정한 모든 것 위에 자기 도메인과 서버를 다시 설치할 수 있습니다. 그 뒤 같은 두 이름을 질의하고 기록한 기준선과 비교하십시오. 수동 편집이 사라졌다면, 수정은 연결 프로필에 속합니다 셸 명령이 아닙니다. 전후를 기록하는 것이 그것을 보이게 만듭니다.

내부 접미사는 토폴로지를 드러내므로 보고서에 필요한 이름과 서버 문맥만 공유하십시오. 도메인 라우팅에 관한 systemd-resolved 문서는 가장 긴 일치 규칙과 틸데 동작을 다루며 한 번 읽으면 위 표의 실수 대부분을 막을 수 있습니다: systemd-resolved 의 질의 라우팅.