VPN 엔드포인트 이름과 프라이빗 서비스 이름: 두 명의 소유자

두 이름은 같은 지점을 설명하면서 전혀 다른 질문에 답할 수 있습니다. vpn.branch.example 는 원격 피어에게 VPN 엔드포인트를 어디서 찾을지 알려 주며, 어떤 터널이 생기기 전에 확인되어야 합니다. inventory.branch.example 는 권한 있는 사용자에게 프라이빗 애플리케이션이 어디에 있는지 알려 주며, 터널이 올라온 뒤에야 의미가 있습니다. 하나를 유지보수해도 다른 하나에는 아무 효과가 없습니다.

둘 중 하나를 디버깅하기 전에 두 레코드에 이름을 붙이십시오

둘 다 소유자와 함께 적어 두십시오. 엔드포인트의 경우 공용 주소를 누가 업데이트하는지, VPN 클라이언트가 응답을 어떻게 갱신하는지 기록합니다. 서비스의 경우 프라이빗 주소의 소유자, 레코드를 보관하는 존, 응답해야 할 리졸버를 기록합니다.

이 짧은 목록은 이 분야에서 가장 흔한 오진을 막습니다. 즉, 전적으로 그 안에만 존재하는 레코드를 고치려고 정상 동작하는 지점 터널을 재시작하는 일입니다. 터널은 서비스 이름의 전송 수단이며 그 권한이 아닙니다.

변경이 제안되면 두 레코드 중 어느 쪽을 건드리는지 물으십시오. 아무도 답할 수 없다면 그 변경은 일정을 잡을 준비가 되지 않은 것입니다.

엔드포인트는 어떤 터널이 생기기 전에 확인되어야 합니다

지점의 인터넷 연결이 새 공용 주소를 받았다고 가정합니다. 엔드포인트 업데이터가 새 주소를 게시하고, 원격 VPN 구현은 변경된 응답을 읽을 수 있어야 합니다. 그 응답을 제공하는 리졸버는 터널 없이 도달 가능해야 하며, 그렇지 않으면 클라이언트는 찾을 수 없는 것에 연결한 뒤에야 확인할 수 있는 이름을 쫓게 됩니다.

이 부트스트랩 의존성은 분명히 말할 가치가 있습니다. 모든 내부 리졸버가 VPN 뒤에 있으면 실수로 만들기 쉽기 때문입니다. 엔드포인트 조회를 위한 터널 이전 경로를 유지하고, 새 응답이 즉시 반영된다고 가정하지 말고 클라이언트의 재연결 동작을 확인하십시오.

동적 DNS에도 레코드 업데이트가 넘을 수 없는 한계가 있습니다. 레코드를 업데이트해도 방화벽 포트가 열리지 않고, NAT 매핑이 생기지 않으며, 피어 신원이 증명되지 않습니다. 포트가 닫힌 채 게시된 주소는 올바르게 확인되면서도 아무것에도 연결할 수 없는 클라이언트를 만듭니다.

마지막으로, 실행 중인 클라이언트는 재연결할 때까지 캐시된 엔드포인트를 계속 사용할 수 있습니다. 게시, 캐시, 재연결 정책을 메모에서 분리해 두어 오래된 피어를 고장 난 업데이터로 오해하지 않도록 하십시오.

서비스 이름은 애플리케이션이 어디에 있는지 설명합니다

이제 터널은 건강하지만 인벤터리 서버가 172.26.14.20 에서 172.26.14.35 로 이동한다고 가정합니다. 공용 엔드포인트 레코드는 영향을 받지 않고, 프라이빗 서비스 레코드는 변경되어야 합니다. 해당 서비스용으로 예약된 주소나 정적 할당을 쓰면 이런 일이 드물어지며, 의도된 경우에는 권한 있는 업데이트 경로가 처리합니다.

여기서 두 업데이트 메커니즘이 혼동됩니다. RFC 2136 은 존에서 DNS 레코드를 추가하고 삭제하는 프로토콜을 정의하지만, 상용 동적 DNS 제공자는 다른 목적을 위해 전혀 다른 HTTP API를 노출할 수 있습니다. 하나를 쓴다고 다른 하나가 당신의 환경에 있다는 뜻은 아닙니다. 업데이터를 작성하기 전에 당신의 존이 실제로 어떤 메커니즘을 받아들이는지 확인하십시오.

올바른 프라이빗 응답은 첫 번째 조건일 뿐입니다. 원격 호출자가 그것을 쓰려면 클라이언트에 프라이빗 존을 가진 리졸버, 그 리졸버로의 질의를 허용하는 정책, 돌아온 주소에 대한 전달이 필요합니다. 도달할 수 없는 주소로 확인되는 이름은 서버 장애처럼 보이는 타임아웃을 만듭니다.

두 경로를 따로 시험하십시오

터널 밖에서 엔드포인트를, 안에서 서비스를 점검하고 결과를 두 개의 독립된 사실로 유지하십시오:

$ dig +short vpn.branch.example @1.1.1.1
$ dig +short inventory.branch.example @172.26.0.53
$ ip route get 172.26.14.35

첫 질의가 실패하면 문제는 공개 게시나 터널 이전 확인 경로에 있으며 내부 변경으로는 도움이 되지 않습니다. 두 번째가 주소를 반환하지만 세 번째가 터널을 통한 경로를 보여 주지 않으면 DNS 계층은 정상이고 전달 정책은 정상이 아닙니다.

주소가 바뀔 때마다 이 쌍을 실행하고 어느 레코드가 움직였는지 기록하십시오. «DNS를 업데이트했다»고만 적은 인수인계는 두 수명 주기 중 어느 것이 실제로 돌았는지 다음 엔지니어가 추측하게 만듭니다.