VPN 게이트웨이는 Windows XP 안이 아니라 옆에 두십시오

건물 어딘가에 아무도 바꿀 수 없는 애플리케이션을 아무것에도 연결해서는 안 되는 운영 체제에서 실행하는 기계가 있다. 그 호스트의 네트워크 어댑터에서 바깥으로 나가 보는 것이 터널이 어디에 속하는지 보는 가장 빠른 방법이다. 대부분의 설계에서 터널은 호스트에 속하지 않는다. 유지 관리되는 게이트웨이로 한 걸음 옮기면 오래된 문제는 시작된 애플리케이션으로 줄어든다.

VPN 클라이언트가 아니라 호스트 어댑터에서 시작하십시오

어댑터 속성을 열고 호스트에 작은 전용 세그먼트의 고정 주소를 주며 게이트웨이를 기본 경로로 삼으십시오. 그러면 호스트에는 터널 클라이언트도, 터널 자격 증명도, 더 넓은 기업 네트워크로 향하는 라우팅 테이블 항목도 필요 없다. 애플리케이션에 원격 서브넷 하나가 필요하면 정확히 그 경로 하나만 추가하십시오.

C:\> route add 10.20.30.0 mask 255.255.255.0 192.168.50.1 -p

그 명령은 하나의 목적지만 게이트웨이에 고정하고 나머지는 모두 라우팅되지 않게 두는데, 그것이 원하는 형태다. 종료 코드를 믿는 대신 route print 로 결과를 확인하십시오. 그다음 애플리케이션이 여전히 서버 이름을 확인하는지 점검하십시오. 해석기가 망가진 오래된 호스트는 네트워크 장애와 똑같이 보이며, 해석기를 고치는 것은 오 분 작업이지만 잘못된 네트워크 변경 뒤에 애플리케이션을 다시 만드는 것은 그렇지 않다.

호스트가 도달할 수 없는 목적지마다 오래된 네트워크 스택을 공격하도록 설득할 수 있는 대상이 하나씩 줄어든다.

업데이트할 수 있는 하드웨어에 터널을 두십시오 게이트웨이에는 두 인터페이스가 필요하다. 하나는 호스트 세그먼트를 향하고 다른 하나는 애플리케이션이 사는 곳을 향하며, 터널은 두 번째에서 끝난다. 그 장치는 펌웨어 업데이트를 받고 암호 구성를 교체하며 흐름을 기록할 수 있고, 아무도 오래된 기계를 건드리지 않는다. 공급업체는 터널 구현에 대한 수정도 제공한다. 호스트는 결코 받지 못한다.

기계 두 대와 마감 기한은 포럼 게시물의 정적 비밀 조리법을 복사할 이유가 아니다. 하나의 클라이언트 구성을 전체 함대에 복제하는 대신 각 게이트웨이에 고유한 피어 ID를 주십시오. 장치를 교체할 때 새 장치를 온라인으로 올리는 바로 그 순간에 이전 ID를 폐기하십시오. 그렇지 않으면 같은 끝점에 인증하는 통제되지 않은 복사본 두 개가 남는다.

키는 게이트웨이의 관리 평면이 기대하는 곳에 저장하고, 구성 백업을 비밀로 취급하며, 누가 그 구성을 밀어 넣을 수 있는지 검토하십시오. 이제 그것이 오래된 호스트의 도달 범위를 결정한다.

네트워크가 아니라 서비스를 허용하십시오 정책은 두 연결 사이의 프로토콜, 포트, 방향으로 작성하십시오. 하나의 애플리케이션 주소에 하나의 허용 포트가 일반적인 답이며, 점프 호스트를 통한 관리 경로가 나머지를 덮는다.

오래된 호스트의 원격 관리는 애플리케이션과 같은 규칙을 타서는 안 되며, 거부를 시험하는 것은 규칙을 쓰는 것만큼 중요하다. 호스트에서 거부될 것으로 예상하는 목적지로 요청 하나를 보내고 거부가 빠진 경로가 아니라 정책에서 오는지 확인하십시오. 설계가 새로운 동안 허용한 흐름을 기록하여 애플리케이션이 문서가 주장하는 것이 아니라 실제로 무엇을 쓰는지 보십시오. 브리지 튜토리얼이 더 짧아 보여 두 서브넷을 합치는 것이 오래된 세그먼트가 조용히 발판이 되는 길이다.

게이트웨이를 우회하는 지름길로 오래된 리스너를 인터넷에 직접 노출하지 마십시오. 관리 경로를 애플리케이션 경로와 분리하여 하나의 침해가 다른 하나를 넘겨주지 않게 하십시오. 결코 실행되지 않는 규칙은 아무도 검증하지 않은 규칙이며, 그래서 거부된 목적지는 승인 시험에 들어간다.

복구는 터널 없이 작동해야 합니다

첫 장애 전에 누가 게이트웨이를 업데이트하고 복구할지 정하고, 그 사람이 게이트웨이가 끝내는 터널 없이도 거기에 도달할 수 있게 하십시오. 콘솔 접근, 로컬 관리 포트, 대역 외 경로가 모두 답이 된다. 자기가 제공하는 터널을 통해서만 구성할 수 있는 게이트웨이는 나쁜 펌웨어 푸시를 참을성 있게 기다리는 함정이다.

실제로 마주칠 장애에 대한 런북을 쓰십시오. 터널 중단, 게이트웨이 사망, 호스트 디스크 소실이다. 호스트 복구 이미지는 아직 존재하는 지원 계약 아래에 두고, 복원이 그 이미지 안의 소프트웨어 상태와 자격 증명도 되돌린다는 점을 기억하십시오.

먼저 격리된 세그먼트로 복원하고 애플리케이션이 시작하는지 확인한 뒤에야 무엇이든 다시 연결하십시오. 게이트웨이가 바뀌면 같은 자리에서 런북과 인벤터리를 갱신하십시오.

인증서, 시계, 서명 경고 설치 프로그램 인증서의 만료가 오늘 서명 검사가 무엇을 말할지 스스로 예측하지는 않는다. Microsoft의 Authenticode 타임스탬프 지침은 서명 인증서가 만료된 뒤에도 타임스탬프가 서명을 검증 가능하게 유지할 수 있으며, 검증은 여전히 서명, 신뢰 체인, 작업을 수행하는 검증자에 달려 있다고 설명한다. 따라서 신뢰 저장소가 다른 두 기계는 같은 파일에 대해 의견이 다를 수 있다. 만료된 서명자는 바이너리가 악성이라는 증거가 아니며, 유효한 서명은 소프트웨어가 유지 관리된다는 증거도 아니다.

오래된 설치 프로그램을 실행하려고 시스템 시계를 뒤로 돌리거나 서명 검사를 끄지 마십시오. 애플리케이션을 아직 지원하는 곳에서 승인된 산출물을 받고 플랫폼이 무엇을 받아들이는지 그들이 말하게 하십시오. 특정 빌드가 XP용 마지막이었다는 게시물은 설치 대상이 아니라 역사로 취급하십시오. 실제 요구 사항은 애플리케이션에 달려 있으며, 보존 작업이 정말 필요하면 생산 접근에서 떨어진 격리 세그먼트에 두고 왜 존재하는지 문서화하십시오.