프라이빗 DNS 이름일까, 그냥 IP일까? 공유하기 전에 결정하라

프라이빗 서비스를 원격 사용자에게 열 때 두 가지 질문이 섞인다. 첫째는 클라이언트가 어떤 이름을 써야 하는가이고, 둘째는 서비스가 어떤 원본을 허용해야 하는가이다. 이 순서대로 답하라, 잘못된 접근 규칙 뒤의 올바른 이름도 여전히 실패하고, 해석되지 않는 이름 뒤의 올바른 규칙은 아예 시험되지 않기 때문이다.

조건 하나: 클라이언트는 어떤 리졸버 경로를 가지는가?

프라이빗 이름은 클라이언트의 리졸버가 답할 수 있을 때만 동작한다. 즉 권한이 부여된 원격 클라이언트는 존을 보유한 DNS 서버에 도달해야 하며, 터널을 통해서든 조직이 이미 원격 사용자를 위해 운영하는 리졸버를 통해서든 가능하다. 터널은 전송 수단이지 디렉터리가 아니다. 클라이언트에게 리졸버로 가는 경로를 줄 뿐, 어느 존을 질의할지는 알려주지 않는다.

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

노트북이 VPN에 연결되었다고 해서 공용 리졸버가 프라이빗 존을 알게 되지는 않는다.

접미사도 같은 주의가 필요하다. 조직이 통제하는 도메인의 하위 도메인을 사용해 소유권과 인증서 계획이 명시적으로 유지되게 하라. .local은 피하라: 멀티캐스트 DNS 명세가 그 접미사를 링크 로컬 해석에 묶어 두며, 라우팅된 터널은 그 동작을 대신 재현해 주지 않는다.

조건 둘: 서비스는 어떤 원본을 받는가?

허용 규칙은 주소를 기준으로 작성되므로 유용한 질문은 라우팅과 변환 후에 서비스가 어떤 주소를 보는가이다. 10.20.30.40의 예시 서비스라면 사무실 클라이언트는 10.20.30.0/24에서 오고 원격 클라이언트는 10.99.0.0/24 같은 별도 풀에서 온다.

게이트웨이가 원격 풀을 변환하면 서비스는 변환기를 보게 되고, 10.99.0.0/24용으로 작성된 규칙은 일치하지 않는다.

이것은 클라이언트 쪽이 아니라 서비스 쪽에서 읽어라. 서비스 호스트의 리스너 로그나 패킷 캡처는 실제로 도착한 원본을 보여주며, 클라이언트 자신의 주소는 경로를 살아남은 것에 대한 추측일 뿐이다.

조건 셋: 이름은 서비스에 묶여 있는가, 호스트에 묶여 있는가?

한 머신의 주소를 가리키는 이름은 모든 클라이언트를 그 머신에 묶는다. 로드 밸런서나 안정적인 서비스 주소를 가리키는 이름은 그 뒤의 호스트가 교체되어도 살아남는다. 의도적으로 선택하라, 나중에 바꾸는 것은 모든 클라이언트의 북마크와 모든 인증서의 주체를 바꾸는 일이기 때문이다.

단일 내부 서비스라면 직접 레코드가 보통 적절하고 생각하기도 더 쉽다.

교체되거나 재구축되거나 확장될 모든 것에는 안정적인 프런트 엔드가 추가 구성에 값한다. 테스트는 간단하다: 사용자에게 알리지 않고 백엔드를 교체할 수 있다면 이름은 서비스에 붙어 있고, 그럴 수 없다면 호스트에 붙어 있다.

두 결정을 따로 테스트하라

먼저 해석하고, 그다음 연결하라. 기대한 주소를 돌려주는 해석 테스트는 이름 경로를 증명하고 허용에 대해서는 아무것도 말하지 않는다. 연결 테스트는 경로와 규칙을 함께 증명하므로 해석이 성공한 뒤에만 실행하라.

curl -sv --max-time 5 https://files.corp.example/health

그다음 금지된 원본을 한 번 테스트하고 결과를 기록하라.

문서에서 두 레코드를 분리해 두라: 이름과 그 존, 허용된 원본과 규칙의 소유자이다. 하나가 바뀌어도 다른 하나는 바뀔 필요가 없다.

결정이 보통 어디서 잘못되는가

흔한 실패는 사무실 네트워크에서만 해석되는 이름 아래 공개된 서비스와 사무실 범위만 허용하는 접근 규칙의 조합이다. 그러면 원격 사용자는 고장 난 서비스를 보고하지만 실제로는 두 개의 별개 누락이다. 두 번째 흔한 실패는 반대다: 이름 문제를 없애려고 넓은 접근 규칙을 추가하면 아무도 의도하지 않은 원본에서 서비스에 닿을 수 있게 된다. 둘 다 구성 누락이며 사용자 자리에서는 똑같아 보인다.

어느 실수도 한 번의 성공한 테스트로는 보이지 않는다. 그래서 두 결정에는 별도의 레코드와 별도의 테스트가 필요하며, 같은 사람이 둘 다 결정하더라도 그렇다.

서비스가 가동되기 전에 둘 다 적어 두라, 다음 변경을 생각하기가 더 쉬워지기 때문이다. 레코드는 짧다: 이름과 그 존에 한 줄, 허용된 원본과 규칙의 소유자에 한 줄이다.