Checkpoint Endpoint Connect VPN을 통해 연결할 때 Windows 7 클라이언트(Windows 10에서도 작동)에 간헐적으로 연결 문제가 발생하는 상황이 있습니다. 이 문제는 VPN 외부로 트래픽을 라우팅하려고 시도하는 내부 네트워크의 특정 호스트에 대한 보다 구체적인 경로 추가로 나타납니다.
사용자 A는 개인 네트워크 192.168.1.100의 집에 있습니다. 이 사용자는 해당 Checkpoint VPN을 통해 회사 네트워크에 연결하고 해당 터널에 대한 개인 네트워크 주소 10.1.7.100을 얻습니다. 이 연결 인스턴스화는 공용 IP 공간으로 향하는 트래픽이 192.168.1.0/24 네트워크를 통해 흘러나와 공용 IP 공간으로 NAT되고, 개인 리소스로 향하는 트래픽이 VPN을 통해 흐르는 하이브리드 유형입니다. 이는 하나의 .net 애플리케이션을 제외하고 우리가 사용하는 거의 모든 것에 적용됩니다. 해당 애플리케이션은 HTTP REST를 사용하여 10.1.4.50의 내부 서버와 통신합니다.
10.1.4.0/24에 대한 VPN 클라이언트 구성에는 모든 10.1.4 트래픽을 메트릭 1의 터널 반대편에 있는 VPN 게이트웨이 주소로 보내는 경로가 있습니다.
문제가 발생하면 메트릭이 11이고 게이트웨이가 192.168.1.1인 대상 서버 IP 전용(이 경우 10.1.4.50)에 대한 보다 구체적인 경로를 삽입하는 라우팅 테이블 변경이 표시됩니다(이는 기본 gw입니다. 터널이 위에 있는 기본 인터페이스). 이 경로가 활성화되면 터널 외부로 라우팅되기 때문에 해당 대상 서버에 대한 모든 것이 실패합니다. 내부 네트워크의 다른 호스트로 향하는 다른 트래픽은 10.1.4.0/24의 다른 호스트를 포함하여 여전히 정상적으로 작동합니다.
우리는 Checkpoint와 상의한 결과 터널이 설정된 후에는 클라이언트가 IP 스택에 이와 같은 가짜 경로를 삽입하지 않으므로 다른 경로가 필요하다고 말했습니다. 그러나 해당 경로를 삽입하는 내용과 그 이유를 찾는 것은 매우 어렵습니다.
실시간 경로 변경을 보기 위해 NirSoft의 일부 유틸리티를 사용해 왔으며 경로 변경 활동을 표시하기 위해 NotifyRouteChange를 사용하는 일부 C++ 유틸리티도 탐색했지만 이들 중 어느 것도 실제로 필요한 세부 수준을 제공하지 않습니다. 프로세스가 실제로 경로를 삽입했습니다.
경로 수정을 수행하는 프로세스 이름이나 ID를 찾는 방법을 알려주실 수 있나요? 아니면 어떤 프로세스가 실제로 내 라우팅 테이블에 나쁜 일을 하고 있는지 확인하기 위한 대안을 추천하시겠습니까? 그것이 정말로 Checkpoints VPN 소프트웨어라면 강제로 문제를 해결할 수 있습니다. 그러나 다른 증거가 없으면 다소 막히게 됩니다.
어떤 도움을 주셔서 감사합니다!