두 개의 VPN, 하나의 리졸버: 마지막에 쓴 쪽이 이긴다

VPN 클라이언트 두 개가 연결되어 있습니다. 하나는 업무용, 다른 하나는 랩 네트워크용이며, 내부 이름은 마지막에 연결한 클라이언트에서만 확인됩니다. 이 패턴은 한쪽 클라이언트의 버그처럼 보이지만, 실제로는 어느 이름을 누가 소유하는지에 대한 합의 없이 같은 리졸버 구성을 쓰는 두 프로그램의 예측 가능한 결과인 경우가 대부분입니다.

신화: 최신 VPN이 DNS를 소유한다

가장 최근 연결이 이긴다는 일반 규칙은 없습니다. 무슨 일이 일어나는지는 플랫폼의 방식과 각 클라이언트가 그것을 어떻게 쓰는지에 달려 있습니다. 리졸버 파일을 대체하는 클라이언트는 한 가지 결과를 내고, 링크마다 도메인을 추가하는 클라이언트는 다른 결과를 내며, 아무것도 하지 않는 클라이언트는 이전 상태를 그대로 둡니다.

따라서 관찰되는 동작은 두 구현의 속성이지 문서화된 우선순위가 아닙니다. 시작 순서만으로 추론하면 때로는 맞고 때로는 재현하기 어려운 방식으로 틀립니다. 대신 매핑을 적어 두십시오. 두 클라이언트에 흩어진 설계는 설계가 아닙니다.

이름 공간을 리졸버에 매핑한다

사설 접미사와 각 네트워크가 요구하는 리졸버를 나열한 뒤, 공개 이름을 어디로 보낼지 결정하십시오. 그 목록이 설계입니다. 그것이 없으면 클라이언트가 우연히 결정합니다.

링크별 DNS나 라우팅 도메인을 지원하는 플랫폼이라면 한 도메인은 한 링크로, 다른 도메인은 다른 링크로 보내고 나머지는 모두 명시적인 기본값을 따르게 함으로써 분할을 의도적으로 표현할 수 있습니다. 같은 파일을 덮어쓰는 두 개의 평면 스크립트는 각자 전체 구성을 소유한다고 믿기 때문에 그 설계를 지킬 수 없습니다.

Windows에서는 이름 확인 정책 테이블이 접미사를 특정 서버로 보낼 수 있고, VPN 클라이언트가 거기에 규칙을 설치할 수 있습니다. 어댑터 목록이 아니라 정책을 확인하십시오, 이름을 해석하는 것은 어댑터 목록이 아니기 때문입니다.

부트스트랩 경로를 유지한다

각 클라이언트는 해당 엔드포인트가 제공하는 서비스를 쓰기 전에 자기 엔드포인트를 찾아야 합니다. 엔드포인트 호스트 이름이 터널을 통해서만 확인되고, 터널은 확인된 호스트 이름을 필요로 한다면 연결 시간 초과로 나타나는 순환 의존이 있습니다. 두 터널 밖에 부트스트랩 경로 하나를 두십시오. 그것이 연결을 구하는 날까지 비용은 없습니다.

각 리졸버로 가는 경로를 보십시오, 그에 대해 설정된 이름만이 아니라. 다른 터널로만 도달할 수 있는 리졸버는 없는 것처럼 동작하고, 증상은 라우팅 오류가 아니라 시간 초과입니다.

겹치는 주소는 DNS 문제가 아니다

같은 주소 범위를 쓰는 두 사설 네트워크는 DNS 순서로 고칠 수 없습니다. 두 터널이 모두 10.0.0.0/8을 요구하면, 올바르게 확인된 이름도 호스트가 올바른 터널로 라우팅할 수 없는 주소를 가리킵니다. 여기에는 별도 범위, 이름 공간, 변환 같은 주소 수준의 해결이 필요하며 리졸버 설정을 더하는 것으로는 안 됩니다. 이를 일찍 결정하면 결코 동작하지 않았을 DNS 구성으로 멀리 돌아가지 않아도 됩니다.

이름 확인을 탓하기 전에 두 터널의 주소 할당을 비교하십시오. 양쪽이 같은 접두사를 밀어 넣으면 호스트는 그에 대한 경로를 하나만 유지하고, 두 번째 터널로 확인된 이름도 첫 번째 터널이 가진 주소에 도착합니다. 별도 범위, 네트워크별 이름 공간, 변환이 수정책이며, 각 클라이언트가 연결된 뒤 라우팅 테이블이 의도한 경로를 보여 주는지 확인하십시오.

실제 애플리케이션으로 증명한다

자기 이름 공간 안에만 존재하는 호스트 두 개와 공개 이름 하나를 골라, 각각을 소유해야 할 클라이언트로 확인하십시오. 기대한 리졸버의 올바른 답은 애플리케이션이 호스트에 도달한다는 것을 증명하지 않습니다, 그 주소로 가는 경로가 여전히 실패할 수 있기 때문입니다. 각 조회 뒤에 사용자가 실제로 실행할 프로그램에서 연결 테스트를 하십시오.

자체 암호화 DNS 옵션이 있는 클라이언트는 방금 확인한 정책을 우회할 수 있으므로, 그 설정도 검토의 일부로 확인하십시오. 그다음 공급업체가 지원하는 순서로 두 클라이언트를 다시 연결하고 조회를 반복하십시오. 순서를 바꿀 때 답이 뒤바뀐다면 경쟁하는 작성자가 여전히 구성의 일부를 소유하고 있습니다. 무엇이든 편집하기 전에 어느 구성 요소가 규칙을 설치하는지(클라이언트, OS 프로필, 관리 에이전트) 알아내고, 순서와 소유자를 기록해 다음 사람이 다시 발견하지 않게 하십시오.