VPN 엔드포인트 허용 목록: 잊고 있던 DNS 새로 고침

방화벽 예외에 vpn.example.com을 입력하는 것은 DNS를 구독하는 듯한 느낌을 줍니다. 보통은 로드 시점에 변환이 일어나고, 그 뒤 규칙은 주소를 보관하며 아무것도 이를 갱신하지 않습니다. 이제 두 구성 요소가 작업을 나눕니다. 응답하는 확인자와 저장하는 방화벽입니다. 대부분의 엔드포인트 중단은 이 인계가 설계된 적 없는 곳에서 시작됩니다.

규칙 속 호스트 이름은 살아 있는 구독이 아니다

일부 도구는 구성이 로드될 때 이름을 확인하고, 다른 도구는 호스트 이름을 유지하며 자체 일정에 따라 다시 확인하며, 또 다른 도구는 주소만 받아들입니다. 보이는 구성이 어느 것인지 밝히는 경우는 드뭅니다. 문서 예제는 보통 로드 시점 사례를 가정하므로, 마이그레이션 중에 그 차이가 사람들을 놀라게 합니다. 주소 변경이 감지될 것이라고 가정하기 전에 구현의 동작을 읽으십시오. 왜냐하면 낡은 허용 목록은 엔드포인트가 옮겨지기 전까지는 작동하는 목록과 똑같이 보이기 때문입니다.

올바른 호스트를 지목하는 규칙도 잘못된 주소를 허용할 수 있습니다. 그 간극이 신화이며, 철자 실수가 아닙니다.

캐시 TTL은 방화벽의 타이머가 아니다

DNS 레코드에는 수명이 있고, 확인자는 그 기간 동안 응답을 캐시합니다. DNS 사양 이 캐시 동작을 정의하지만, DNS 데이터를 규율할 뿐 방화벽의 별도 주소 저장소를 규율하지는 않습니다. 짧은 TTL은 없는 곳에 갱신 작업을 만들지 않습니다. 캐싱은 여러 계층에서도 일어나므로 터미널이 보는 응답이 방화벽이 본 응답과 다를 수 있습니다.

실제 제품에 세 가지를 물으십시오. 언제 확인하는지, 결과를 어디에 저장하는지, 무엇이 갱신을 촉발하는지. 답이 부팅 시점뿐이라면, 장수 세션은 자신이 허용된 주소보다 오래 살 수 있습니다.

dig +short vpn.example.com
resolvectl query vpn.example.com

갱신과 실패를 하나의 정책으로 설계하라

유지되는 예외에는 명시적 답이 필요합니다. 클라이언트가 새 주소를 고르기 전에 무엇이 갱신을 촉발하는지, 넓은 임시 창을 열지 않고 허용 집합이 어떻게 바뀌는지, 오래된 항목이 언제 제거되는지. 그 답을 규칙 옆에 적으십시오.

실패 동작을 의도적으로 선택하십시오. 이전 주소를 유지하면 세션을 보존하고 낡은 허용을 남길 수 있고, 집합을 비우면 복구가 좌초될 수 있습니다. 어느 쪽도 실패한 조회의 우연한 결과여서는 안 됩니다. 선택한 동작을 런북에 적어 다음 운영자가 압박 속에서 즉흥적으로 판단하지 않게 하십시오.

부트스트랩 DNS도 좁게 유지하십시오. 공용 확인자에 대한 무조건적 예외는 일치하는 모든 것에 대한 직접 DNS 경로이며, 엔드포인트 이름만을 위한 것이 아닙니다.

엔드포인트 변경을 증명하십시오, 첫 연결이 아니라

클라이언트의 지원 관리자가 이미 확인과 차단을 조정한다면 그것을 사용하십시오. 사이트가 관리하는 PF 호스트에서는 수명 주기 동작이 다른 플랫폼에서 호스트 이름 테이블 구문을 복사하는 대신 사이트의 소유권과 복구 계획을 유지하십시오.

승인된 무해한 테스트로 통제된 변경 전후에 클라이언트가 선택한 주소를 활성 허용 집합과 비교하십시오. 실패한 조회, 더 이상 유효하지 않은 항목 삭제, 지원되는 경우 다른 주소 패밀리를 포함하십시오. 의도한 터널은 복구되어야 하고, 무관한 직접 트래픽은 정책 아래에 남아야 합니다. 성공한 첫 연결은 초기 변환이 우연히 맞았음을 증명할 뿐입니다.