서버 2019 RRAS를 사용하여
저는 두 개의 주요 서브넷(그 내부에 많은 작은 곳들도 있음)을 가지고 있습니다.
10.32.0.0/16
10.24.0.0/16
RRAS 랜 케이블은 10.32.8.4에 있으며, 모든 곳을 핑할 수 있습니다. 따라서 서버 OS의 경로 테이블은 ‘괜찮아 보입니다’…
VPN 클라이언트는 서버에 연결했을 때 10.32.x.x로만 핑할 수 있습니다.
그들은 10.24.x.x 및 그 내부의 모든 것을 인지하지 못합니다.
클라이언트의 노트북 VPN 프로파일에 10.24 경로를 추가했지만 아무것도 나오지 않습니다.
RRAS 측에서 트래픽 흐름을 허용하려면 무엇을 변경할 수 있나요?
접근/방화벽 규칙이 이를 방해하나요?
VPN 클라이언트는 새로운 서브넷 마스크를 할당받아야 합니다.
몇 가지 좋은 포인트를 이미 제시했어요. 모든 것은 어떻게 가고 돌려보내는지가 알아야 합니다. 그래서 PC 쪽에 경로를 추가했다고 해서 그것이 전부는 아니에요. 내부 라우팅은 VPN 트래픽을 어떻게 반환할지도 알아야 하고, 종종 방화벽이 자체 풀에서 DHCP 범위를 할당하는데, 이 범위는 3계층 라우팅에서 알려지지 않기 때문에 VPN에서 라우터로 들어가도 라우터는 트래픽을 반환하지 않습니다. 만약 어떤 단계에서 경로가 누락되면, 반환 트래픽이 기본 경로(보통 인터넷으로 나감)로 푸시됩니다. 그리고, 누군가 언급했듯이, VPN 방화벽 규칙이 특정 서브넷으로만 트래픽을 제한했을 수도 있습니다. 그래서 PC 쪽에 경로를 추가하는 것만으로는 여러 관점 중 하나일 뿐입니다.
이 문제를 해결하려면 방화벽을 최소한 구성할 수 있어야 합니다. 인바운드 규칙을 NAT로 설정하고, NAT가 트래픽을 허용된 서브넷에서 오는 것처럼 보이게 만들면, 인바운드 VPN 트래픽이 내부 인터페이스에서 오는 것처럼 보이게 할 수 있습니다. 이렇게 하면 역방향 내부-외부 생성 트래픽은 깨질 수 있지만, 이 문제를 극복하는 데 도움이 될 수 있습니다. 다만, 신중하게 해야 합니다.
전체 경로와 규칙, DHCP, 방화벽 규칙을 도식화하세요. 재미있는 작업입니다.
네!
라우터의 VPN 클라이언트용 경로 테이블이 일부 서브넷만 포함하고 있었어요.
모든 것에 적용하자 모든 것이 원활하게 흐르기 시작했습니다.