도메인 기반 VPN 라우팅과 IP 라우트 비교: 무엇이 맞을까?

IP 라우트는 주소 프리픽스와 일치하며, 커널은 더 묻지 않고 이를 적용합니다. 도메인 기반 VPN 규칙은 이름과 일치하므로, 스택 어딘가에서 그 이름이 현재 어떤 주소를 뜻하는지 판단하고 그 판단을 최신으로 유지해야 합니다. 두 가지는 실패 방식이 다른 서로 다른 메커니즘이지만, 공급업체들은 둘 다에 같은 단어를 씁니다. 기능 목록에서 비교하는 것은 핵심을 놓칩니다. 답이 바뀔 때 무슨 일이 일어나는지로 비교해야 합니다.

유용한 구분은 이름을 해석하는 규칙과 해석하지 않는 규칙 사이에 있습니다.

각 규칙이 실제로 무엇과 일치하는가

프리픽스 규칙은 라우팅 테이블의 목적지 주소와 일치합니다. 해석도, 만료도 없으며 모든 패킷에서 일치가 정확합니다. 도메인 규칙은 애플리케이션이 이름을 요청하는 것과 일치하며, 이를 RFC 1034 는 주소가 아니라 레이블의 트리로 정의합니다. 일부 제품은 이름을 한 번 해석하고 그 결과 주소를 라우트로 설치하는데, 그러면 규칙은 갱신 타이머가 붙은 IP 규칙에 불과합니다.

디버깅하기 전에 둘 중 어느 쪽인지 알아두세요. 실패 양상이 경우마다 전혀 다르게 보이기 때문입니다.

도메인 규칙은 스택 어디에 있는가

제품이 로컬 프록시로 도메인 규칙을 구현한다면 트래픽이 그 프록시에 도달해야 하며, 시스템 프록시를 무시하는 애플리케이션은 규칙을 완전히 우회합니다. 이름을 해석해 라우트를 추가하는 방식이라면 주소는 마지막 갱신 시점만큼만 최신입니다. 리졸버에 훅을 걸면 DNS 동작이 라우팅 정책의 일부가 되고, 대체 리졸버가 조용히 이를 무효화할 수 있습니다.

설정 라벨이 아니라 공급업체의 모델을 읽으세요. Split Tunnel이라는 상자가 있어도 두 클라이언트가 세 가지 다른 일을 하고 있을 수 있습니다.

무엇이 깨지는지 비교하기

세 가지가 서로 다르게 깨집니다. 주소 변동: CDN 호스트 이름은 몇 분 만에 다른 주소 집합으로 해석될 수 있어 복사한 목록은 빠르게 낡습니다. 하위 도메인 범위: example.com 규칙이 api.example.com을 포함할 수도, 하지 않을 수도 있으며 문서에 보통 어느 쪽인지 명시되어 있습니다. 해석 실패: 리졸버가 실패하면 이름을 해석하는 클라이언트는 트래픽을 터널링하거나 직접 보내는 쪽으로 넘어갈 수 있습니다.

설정 문제인 것은 두 번째뿐입니다. 나머지 둘은 제품이 어디까지 추측할지에 관한 설계 문제입니다.

프리픽스가 더 나은 답일 때

안정적인 사설 서브넷에는 명시적 프리픽스가 더 명확하고 빠르며 감사하기 쉽습니다. 해석할 것이 없으므로 리졸버 장애도 견딥니다. 서비스가 호스팅되어 있거나 주소가 자주 바뀌거나 목적지 집합을 정말 열거할 수 없을 때 도메인 규칙을 쓰세요. 우연히 호스트 이름만 알고 있다는 이유로 선택해서는 안 됩니다.

추측으로 만든 정적 목록은 둘 중 최악입니다. 관리되는 것처럼 보이지만 공급자가 호스트를 추가하는 날 조용히 트래픽을 놓칩니다.

새 요청으로 검증하기

정상 재연결 후 콜드 요청으로 시험하기, 캐시된 페이지는 규칙을 아예 건드리지 않을 수 있기 때문입니다. 이름을 해석한 다음 연결이 실제로 어디로 갔는지 확인하세요. dig +short app.example.com 는 현재 주소 집합을 알려 주고, 클라이언트의 연결 목록은 어느 인터페이스가 흐름을 실어 날랐는지 보여 줍니다.

제품이 문서화한 갱신 간격이 지난 뒤 다시 해보세요. 주소 집합이 달라졌는데 규칙이 따라가지 않는다면 실제 동작을 찾은 것입니다.

리졸버 정책도 따로 두세요. 도메인 규칙에는 올바른 이름 데이터가 필요하지만, 어느 리졸버가 질의에 답하는지는 그 규칙만으로 정해지지 않습니다.