Access Server 게이트웨이 사용자: 클라이언트 지사 LAN 라우팅

OpenVPN 클라이언트의 터널 주소로 ping은 되지만 그 뒤 LAN의 어떤 호스트에도 닿지 않습니다. Access Server는 클라이언트에 VPN 풀 주소를 주며, 풀 주소는 서버가 자기 것이라고 아는 전부입니다. 지사 프리픽스는 따로 선언해야 하고, 선언한 뒤에도 지사에는 전달자가, 본사에는 반환 경로가 필요합니다. 잘못된 위치의 경로는 해결책처럼 보이지만 아무것도 바꾸지 않습니다.

두 주소, 두 가지 소유 주장

클라이언트가 연결하면 Access Server는 설정된 VPN 풀에서 주소를 할당합니다. 예를 들어 10.90.0.0/24입니다. 그 할당은 호스트 하나의 임대입니다. 같은 클라이언트가 10.60.0.0/24 앞에도 있다는 정보는 연결에 없고 서버는 추측하지 않습니다. LAN 프리픽스는 관리자가 선언할 때만 특정 클라이언트를 통해 도달합니다.

그래서 다른 장비의 정적 경로는 소용없습니다. 경로는 10.60.0.0/24를 이 주소로 보내라고 하지만, 그 주소가 게이트웨이로 표시된 적 없는 클라이언트의 것이면 서버가 그 패킷을 보낼 이유가 없고 클라이언트 스택이 버릴 수 있습니다. 선언과 경로는 한 메커니즘의 두 절반입니다.

게이트웨이 설정이 실제로 설치하는 것

Admin Web UI에서 선언은 사용자 속성입니다. 커넥터 사용자에서 Configure VPN gateway를 켜고 실제 지사 프리픽스를 Network on the VPN client side에 입력합니다. 그 사용자도 인증되므로 무인 장치에 맞는 자격 증명 정책이 필요하고, 자동 로그인 프로필은 편의 파일이 아니라 비밀입니다.

그 체크박스 뒤에서 서버는 프리픽스를 그 클라이언트의 풀 주소로 도달 가능하다고 보고, Access Controls의 라우팅 구성이 다른 클라이언트에 무엇을 알릴지 정합니다. 일반 클라이언트에 밀어 넣는 경로와 본사 네트워크에서 클라이언트 주소와 서브넷으로 가는 트래픽을 허용하는 접근 규칙입니다. 지사에 도달해야 하는 네트워크에만 라우팅을 켜고 허용 목록은 짧게 두십시오.

생성된 파일에 붙여 넣은 Community 스타일 지시문은 이 모델에 참여하지 않습니다. 제품이 밀어 넣는 라우팅 테이블은 제품 소유이며 손으로 고친 줄은 다음 생성에서 덮어써지거나 무시됩니다.

두 네트워크의 반환 경로를 완성하십시오

구체적 계획: 본사 10.40.0.0/24, 지사 10.60.0.0/24, VPN 풀 10.90.0.0/24, Access Server는 본사 쪽 사설 주소에서 도달 가능합니다. 본사 라우터에는 지사 프리픽스와 풀 경로가 모두 Access Server를 향해야 합니다. 없으면 터널이 요청을 나르고 응답은 기본 게이트웨이로 나가 반쯤 열린 연결이 됩니다.

지사에서 커넥터는 자신에게 향하지 않은 패킷을 전달해야 합니다. 운영체제의 IP 전달과 터널 및 LAN 인터페이스로 한정된 전달 허가입니다. Linux는 net.ipv4.ip_forward=1와 forward 체인 규칙, Windows는 routing and remote access입니다. 이어서 지사 호스트에는 반환 경로가 필요합니다. 커넥터가 기본 게이트웨이가 되거나 기존 게이트웨이가 본사와 풀 프리픽스의 특정 경로를 실어야 합니다.

커넥터의 라우팅 테이블은 지사 LAN의 모든 호스트를 다시 구성하지 않습니다. 호스트가 다른 라우터를 가리키면 반환 경로는 그쪽에 속하며, 그 라우터는 자기가 보는 출발지 주소가 로컬 서브넷의 이웃이 아님을 받아들여야 합니다.

실패를 권한이 아니라 경로로 읽으십시오

정해진 순서로 시험합니다. 먼저 Access Server에서 지사 호스트로 허용된 서비스, 다음 본사의 일반 호스트에서 같은 서비스, 정책이 허용하면 반대 방향입니다. 첫째가 통과하고 둘째가 실패하면 밀어 넣은 경로나 접근 규칙이 문제입니다. 둘 다 통과하는데 응답이 없으면 지사의 전달과 본사의 반환 경로를 확인하십시오.

다음 의심은 호스트 방화벽입니다. 라우팅된 접근에서는 목적지가 본사나 풀 주소를 출발지로 보므로 로컬 서브넷용 규칙은 맞지 않고, 라우팅이 완벽히 동작한 뒤에 패킷이 버려집니다.

두 설계에는 더 필요합니다. 사이트 간에 겹치는 프리픽스는 목적지를 모호하게 만들어 재번호나 변환이 필요하고, 클러스터 Access Server는 경로를 한 노드가 쥐는 것이 아니라 모든 노드가 지사 커넥터로 가는 경로를 가져야 합니다. 변경은 제품의 일반 저장 및 업데이트 경로로 적용하고 커넥터를 다시 연결하고 양쪽에서 확인하십시오. 모든 장비의 완전한 재부팅은 절차의 일부가 아닙니다.

Access Server site-to-site 자습서는 같은 설정을 제품 순서로 나열합니다. 설계를 자신의 프리픽스에 맞추기 전에 한 번 따라 볼 만합니다.