hosts 파일을 복원하는 VPN 작업이 이후 수정을 지웁니다

연결 작업은 Windows hosts 파일을 복사해 사설 주소 하나를 덧붙이고, 해제 작업은 저장된 버전을 다시 복사합니다. 몇 주 동안 잘 동작하다가 어느 오후 VPN과 아무 관련이 없는 내부 사이트에 접속하지 못합니다. 복원은 시킨 대로 정확히 했습니다: 다른 사람의 수정 이전 파일을 되돌려 놓은 것입니다. 잘못은 모델에 있고 복사 명령에 있지 않습니다.

공유 파일의 스냅숏을 찍고 나중에 복원하는 모든 작업 흐름은 그 사이의 모든 변경을 손실로 물려받습니다.

나중에 복원한 백업은 지금의 백업이 아닙니다

흔한 순서를 따라가 봅니다. 작업이 파일을 저장하고 터널용 항목을 덧붙입니다. 나중에 관리자가 무관한 수정을 추가하고, 두 번째 프로필이 자기 항목을 추가합니다. 해제 시 복원은 원래 스냅숏을 되돌려 두 번째 프로필의 항목과 관리자의 수정을 모두 지웁니다. 둘 다 VPN의 것이 아니었고, 이제 둘 다 사라졌습니다.

고정된 백업 파일 이름 하나가 상황을 더 나쁘게 만듭니다. 이후 연결 이벤트가 이미 수정된 파일을 원래 파일이라 여기고 덮어쓸 수 있어, 복구 기준이 마지막 이벤트 때의 파일 모습 쪽으로 흘러갑니다.

모든 이벤트는 알림이지 트랜잭션이 아닙니다

이벤트로 실행되는 작업은 알림입니다. 재연결, 중단된 종료, 두 번째 프로필은 앞선 작업이 아직 쓰는 중에도 필요한 상태를 다시 만듭니다. 둘을 직렬화하는 것도, 절반쯤 끝난 변경을 되돌리는 것도 없습니다. 또한 이벤트 식별자만으로는 공급자와 그 데이터 없이 어느 프로필의 것인지 알 수 없습니다. 작업을 트랜잭션으로 취급하는 것이 실패하는 가정입니다.

반복되는 연결 이벤트가 나머지 절반입니다: 확인 없는 덧붙이기는 똑같은 항목을 하나 더 만들고, 그러면 일부 리졸버가 한 이름에 두 개의 응답을 봅니다.

각 매핑에 소유자를 두십시오

hosts 파일의 각 줄은 호스트 이름을 주소에 매핑할 뿐 어느 터널이 올라와 있는지는 말하지 않습니다. 자동화를 피할 수 없다면 VPN이 관리하는 매핑에 소유자 하나를 지정하십시오. 그 소유자는 자기 항목만 갱신하고, 무관한 현재 내용을 보존하고, 반복 이벤트에서 중복을 피하고, 기억된 목록이 아니라 실제로 활성인 연결과 맞춰야 합니다.

두 개의 살아 있는 터널이 같은 매핑을 필요로 할 때, 다른 소유자가 아직 그것을 필요로 하는 동안 한 번의 해제가 그것을 지워서는 안 됩니다. 참조 계수나 명시적 소유 기록이 필요하고, 불리언으로는 부족합니다.

백업은 검토된 복구에 여전히 가치가 있습니다. 그것이 정상적인 해제 동작이어서는 안 되고, 파일에 무엇이 있었는지에 대한 유일한 기록이어서도 안 됩니다.

조건부 DNS가 진짜 필요일 때

진짜 요구가 터널이 올라와 있는 동안에만 해석되는 사설 이름 공간이라면 hosts는 잘못된 수단입니다. Windows NRPT는 이름 공간에 대해 리졸버를 고를 수 있고, 주소 레코드를 스스로 만들지는 않으며, 리졸버는 여전히 응답해야 합니다. 이는 소유자가 다른 다른 설계이며, 전환마다 파일을 편집하는 일을 완전히 없앱니다.

hosts를 단일 고정 서비스를 위해 일부러 유지한다면, 그 주소가 의도한 경로로 도달 가능하게 남고 호스트 이름이 안정적으로 유지되는지 확인하십시오: 그래야 애플리케이션의 신원 검사가 계속 동작합니다. DNS 캐시를 지우는 것으로는 다음 조회가 다시 읽을 오래된 항목을 고칠 수 없습니다.

반복 연결, 동시에 두 개의 프로필, 무관한 수정 뒤의 해제를 시험하십시오. 결과는 기계의 나머지를 되감지 않으면서 VPN의 매핑이 소유자를 따르는 것이어야 합니다.