OpenVPN이 DNS 서버를 밀어 넣었지만 Linux는 이를 무시한다

밀어 넣은 DNS 서버는 로그에 있고 터널은 올라와 있는데 내부 이름은 여전히 실패합니다. 밀어 넣기 자체에는 아무것도 고장 나지 않았고, 설정은 도착한 자리에서 멈췄습니다. 밀어 넣은 DNS 옵션은 클라이언트에게 보내는 메시지이지 운영체제 리졸버에 대한 지시가 아니며, 이 둘 사이의 인계가 이런 사례 대부분이 끝나는 지점입니다. 다섯 가지 확인을 순서대로 하면 일어나지 않은 인계를 찾을 수 있습니다.

확인 하나: 연결은 어떻게 시작되는가

연결의 소유자가 리졸버 설정을 누가 적용할 수 있는지 정합니다. 셸에서 직접 실행한 openvpn 명령은 자기 프로세스 외에는 아무것도 소유하지 않지만, systemd 유닛, NetworkManager, 공급업체 클라이언트는 각자 DNS를 게시하는 방식이 있습니다. 어느 하나를 전제하기 전에 프로세스 목록과 유닛 이름을 읽으십시오.

명령줄 프로세스가 자동으로 NetworkManager 연결은 아니고, NetworkManager 연결이 자동으로 resolv.conf를 쓴 것은 아닙니다. 이 두 가지 가정이 이번 조사에서 낭비되는 시간의 대부분을 설명합니다. 실제로 보고 있는 인터페이스에 어떤 구성 요소가 DNS를 게시하는지 물으십시오.

계속하기 전에 소유자를 적어 두십시오. 이후의 모든 확인이 여기에 달려 있습니다.

확인 둘: 리졸버 링크가 실제로 담고 있는 것

systemd-resolved 호스트에서는 resolvectl status가 각 링크를 DNS 서버와 도메인과 함께 나열합니다. 터널 링크를 찾아 항목을 읽고, 번호가 생성 순서를 따르므로 인터페이스 이름이 tun0라고 가정하지 마십시오. 밀어 넣은 주소가 링크에 없다면 실패한 것은 조회가 아니라 인계입니다.

주소가 있다면 다음 질문은 그 링크가 어떤 도메인을 주장하는가입니다. 도메인 목록이 없는 링크는 직접 질의된 이름에만 응답하며, split-DNS 배포가 원하는 것은 대개 그것이 아닙니다. 주소만으로는 필요하지만 충분하지 않습니다.

어떤 결론을 내리기 전에 리졸버 출력의 링크 이름과 VPN 로그의 인터페이스 이름을 비교하십시오. 거기서 불일치하면 보통 로그 줄이 다른 프로세스에서 왔다는 뜻입니다.

확인 셋: 이름 공간이 그 링크를 선택하는가

리졸버가 올바른 서버를 가지고 있어도 조회되지 않을 수 있습니다. 링크별 도메인이 어느 질의가 어느 링크로 가는지 정하고, 라우팅 도메인이 없으면 사설 이름 공간은 기본 링크가 말하는 것으로 돌아갑니다. 그래서 내부 이름에 대한 resolvectl query는 성공하는데 애플리케이션은 계속 실패합니다. 애플리케이션이 전혀 다른 리졸버 경로를 쓰고 있을 수 있습니다.

서버 주소만이 아니라 도메인 할당을 확인하십시오. ~corp.example로 쓰인 도메인은 라우팅 도메인이고, 물결표는 이름을 맞추는 방식을 바꿉니다.

애플리케이션에 자체 리졸버가 있다면 시스템 도구가 아니라 그것이 쓰는 같은 방식으로 시험하십시오. 시스템 리졸버를 우회하는 조회 도구는 링크 상태와 무관하게 성공합니다.

확인 넷: 소유자는 하나, 둘이 아니다

NetworkManager가 이미 VPN과 리졸버 상태를 관리한다면 관련 없는 훅 스크립트를 추가하는 것은 경쟁하는 작성자를 만듭니다. 패키지가 systemd-resolved용으로 제공하는 훅은 지원되는 통합이며, script-security 2, up 경로, up-restart, down 경로, down-pre이라는 특정한 수명 주기를 기대합니다. 이 옵션들은 등록과 제거가 첫 연결에서만이 아니라 올바른 시점에 일어나게 합니다.

안내서에서 복사한 예시 경로가 아니라 패키지가 설치한 경로를 쓰십시오. 훅은 권한이 내려간 뒤에 실행되므로 권한도 중요합니다.

배포판 리졸버 스크립트를 편집해 출력 대상을 바꾸는 것은 한 호스트의 우회책을 기록할 뿐입니다. 일반적인 수리가 아닙니다.

확인 다섯: 다시 연결한 뒤에도 같은 결과인가

다시 연결하고 링크를 다시 읽으십시오. 한 번 나타났다가 다음 전환에서 사라지는 등록이 바로 이 체크리스트 전체가 존재하는 이유인 고장입니다. 일시 중단 뒤, 강제 재연결 뒤, 리졸버 서비스 재시작 뒤에 시험하십시오. 전환마다 다른 순서 가정이 시험됩니다.

재연결에서 다섯 가지 확인이 모두 통과해야만 밀어 넣은 설정이 쓰이고 있다고 말할 수 있습니다. 그보다 앞선 것은 행운의 순간을 찍은 스냅숏일 뿐입니다.