어느 링크가 응답하는가: 분할 터널 VPN DNS용 라우팅 도메인

일반 브라우징은 로컬 링크에 두고 회사 이름은 터널이 제공하는 DNS 서버로 해석합니다. VPN의 기본 경로를 끄면 앞부분만 얻고 뒷부분은 만들어지지 않은 채 남습니다. 다음은 빠진 설정, 그 의미를 바꾸는 문장 부호, 어느 링크가 실제로 응답했는지 보여 주는 유일한 명령입니다. NetworkManager와 systemd-resolved를 전제로 합니다. 혼란은 대개 이 조합에서 시작되기 때문입니다.

첫 단계: 경로와 리졸버를 분리하기

ipv4.never-default는 라우팅 질문에 답하며 NetworkManager가 이 연결을 모든 IPv4 트래픽의 경로로 설치하지 못하게 합니다. DNS 라우팅 도메인은 다른 질문에 답합니다. 일치하는 접미사에 대한 쿼리를 어느 링크의 네임서버가 받는가입니다. 둘은 서로를 함의하지 않으며 프로필은 한쪽을 수년간 지니면서 다른 쪽을 빠뜨릴 수 있습니다. 경로만이라는 것은 터널이 회사 서브넷을 나르고 그 리졸버가 회사 이름에 답하며 나머지는 그대로 둔다는 뜻입니다.

경로 속성만 설정하면 내부 이름이 실패합니다. 대개 끊긴 터널처럼 들리는 타임아웃입니다. 도메인만 설정하면 머신의 모든 짧은 이름에 검색 접미사를 조용히 추가한 것입니다. 두 실수 모두 티켓을 VPN 서버로 보내지만, 잘못된 부분이 그곳인 경우는 드뭅니다.

둘째 단계: 프로필에 라우팅 전용 도메인 추가하기

연결 이름이 corp-vpn이고 회사 접미사가 internal.example이며 터널의 리졸버에 이미 접근할 수 있다고 가정합니다. 먼저 현재 값을 읽으세요. 아래 명령은 이미 항목이 있을 수 있는 속성을 바꿉니다.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

연결 이름과 접미사는 자신의 것으로 바꾸세요. 위 값은 예시입니다. 더하기 기호는 보기보다 중요합니다. 붙이면 기존 목록에 값이 추가되고, 붙이지 않으면 속성이 교체되어 어제까지 작동하던 프로필에서 무관한 도메인이 사라집니다. 물결표는 스타일이 아니라 동작을 바꾸며 아래 단락이 무엇을 선택하는지 설명합니다. 쓰기 전에 읽는 순서를 지켜 교체 형식에 놀라지 않게 하세요.

앞의 물결표는 라우팅 전용 도메인을 표시하므로 일치하는 쿼리는 이 링크의 서버로 가고 접미사는 짧은 이름에 붙지 않습니다. 물결표를 빼면 같은 문자열이 검색 접미사도 되어, 사람들이 거의 의도하지 않는 다른 결과가 됩니다. 위 두 설정은 IPv4이므로 이중 스택 프로필에는 ipv6.never-default와 ipv6.dns-search의 같은 라우팅 도메인이 필요합니다. 그렇지 않으면 IPv6 쪽이 기본 경로를 계속 쓰고 거기서 내부 이름이 실패합니다.

셋째 단계: resolvectl로 어느 링크가 응답했는지 묻기

resolvectl status를 실행해 각 링크의 DNS 서버와 도메인을 읽고, 쿼리가 허용된 실제 내부 이름에 대해 resolvectl query host.internal.example를 실행합니다. 두 번째 명령만이 라우팅 도메인이 제 역할을 한다는 직접 증거입니다. 응답한 링크를 지목하기 때문입니다. 상태 목록만으로는 구성이 증명되고, 쿼리가 해석을 증명합니다.

systemd-resolved는 가장 잘 일치하는 라우팅 도메인을 고르므로 다른 링크의 더 구체적인 도메인이 경쟁에서 이길 수 있습니다. 쿼리가 예상하지 못한 링크에서 돌아오면 VPN의 DNS 서버를 건드리기 전에 도메인 목록을 읽으세요. ~. 루트 도메인은 모든 것과 일치하며 이미 있으면 자신의 이름에 대해서는 구체적 도메인이 여전히 이기지만 링크는 요청보다 훨씬 많은 것에 답합니다. 목적이 회사 이름뿐이라면 그 루트 항목을 제거하거나 좁히세요.

VPN 링크가 DNS 서버를 전혀 나열하지 않으면 클라이언트는 한 번도 등록하지 않은 것입니다. 뒤에 서버가 없는 라우팅 도메인은 빠진 도메인과 다른 방식으로 실패하므로 먼저 등록을 고치세요.

넷째 단계: 이름은 해석되지만 서비스는 안 될 때

올바른 응답은 해석이 작동했다는 것만 증명하며 애플리케이션에는 받은 주소로 가는 경로가 여전히 필요합니다. 그 경로는 방금 구성한 분할 기본 경로를 견뎌야 하므로 DNS를 다시 탓하기 전에 확인하세요. 다음으로 서비스 포트의 도달성을 확인하세요. 파일 공유나 디렉터리 서비스는 해석, 라우팅, 인증 어디서든 실패하며 경우마다 매우 비슷한 메시지를 냅니다. 결과를 보고할 때 이 세 계층을 분리하세요. 그렇지 않으면 다음 사람이 이미 올바른 DNS를 다시 확인합니다.

이 질문과 함께 도는 Samba 변경은 접근 계층의 문제이지 DNS 선택이 아닙니다. 이름 해석 장애에 적용하는 것이 작은 문제가 두 번째 문제를 얻는 방식입니다.

다섯째 단계: 빠진 도메인을 고치려고 리졸버를 교체하지 마세요

리졸버 파일을 덮어쓰거나 다른 리졸버 관리자를 설치하라는 조언은 다른 문제를 풉니다. 그것들은 고유한 실패 모드가 있는 시스템 통합 변경이며, 구성된 적 없는 라우팅 도메인을 추가하지 않습니다. 교체하기 전에 머신에서 이름 해석을 소유한 구성 요소를 확정하세요. systemd-resolved가 있는 NetworkManager 데스크톱에서는 그 소유권이 이미 정의되어 있습니다. 그것과 싸우는 것이 작동하는 구성을 아무도 재현할 수 없는 것으로 만드는 길입니다.

작업 순서: 터널이 리졸버를 제공하는지 확인하고, 라우팅 전용 도메인을 추가하고, 프로필 컨트롤로 다시 연결하고, 응답하는 링크를 검증한 뒤 서비스를 그 포트에서 시험하세요. 이 순서는 두 번째 면담 없이 다음 사람에게 넘길 수 있는 결과를 남깁니다.