원격 액세스 클라이언트가 지사 게이트웨이 역할을 해야 할 때

VPN에 연결된 노트북은 본사에 도달할 수 있습니다. 같은 책상의 프린터와 파일 서버는, 아무것도 그들의 패킷을 그 터널로 전달하지 않고 응답을 되돌려 주지 않기 때문에, 도달할 수 없습니다. 클라이언트를 지사 게이트웨이로 바꾸는 것은 구성 결정이기 전에 라우팅과 책임의 결정입니다. 상자에 적힌 프로토콜 이름은 그 역할이 지원되는지 답하지 않습니다.

프로토콜 라벨이 말해 주지 않는 것

OpenVPN 은 커넥터가 전체 서브넷을 전달하는 사이트 간 설계를 문서화하며, Access Server는 게이트웨이 역할과 명시적 라우팅으로 이를 구현합니다. SSL VPN으로 판매되는 다른 제품은 클라이언트 뒤의 네트워크를 알리는 지원되는 방법 없이 원격 사용자 기능만 제공할 수 있습니다. 한 릴리스의 기능이 다른 릴리스에 대한 약속이 아니므로 버전도 중요합니다. 실제로 실행하는 구현을 읽고, 다른 제품용으로 쓰인 레시피는 설계가 아니라 단서로 취급하십시오.

먼저 정해야 할 질문은 VPN 소유자가 전달 역할을 지원하는지입니다. 지원하지 않으면 클라이언트 측 라우팅으로는 지원되게 만들 수 없습니다.

계약의 두 측면: 지사와 본사

지사 측에서는 한 호스트가 전달, 필터링, 복구를 맡습니다. 모든 지사 장치에서 의도된 경로가 필요하며, 터널이 끊긴 동안에도 외부 VPN 연결은 하부 네트워크를 통해 도달 가능해야 합니다. 본사 측에서는 누군가 지사 서브넷을 정의하고 게이트웨이의 신원을 받아들이고 특정 리소스를 허용해야 합니다. 어느 반쪽도 혼자 작동하지 않습니다.

돌아오는 경로가 건너뛰어지는 부분입니다. 클라이언트의 터널 주소는 그 뒤의 서브넷을 알리지 않으므로 본사 라우터에는 해당 프리픽스에 대해 VPN 게이트웨이를 가리키는 경로가 필요합니다.

라우팅 설계에서는 집선기가 지사 프리픽스의 패킷을 전달하고 상위 LAN 라우팅이 응답을 되돌리는 방법을 압니다. 변환 설계에서는 본사가 보는 소스가 다시 쓰이며, 이는 반환 경로 하나의 필요를 없앨 수 있지만 어느 지사 머신이 트래픽을 보냈는지 숨깁니다. 그 트레이드오프는, 변환이 개입되면 애플리케이션 로그와 액세스 규칙이 장치별 신원을 잃기 때문에, 설계 문서에 속합니다.

라우팅이냐 변환이냐: 반환 경로를 의도적으로 고르십시오

장치별 신원과 호스트별 정책이 중요하고 관련된 모든 라우터에서 반환 경로를 유지할 수 있다면 라우팅을 고르십시오.

경로를 추가할 수 없지만 본사가 하나의 소스 주소를 보는 것을 받아들일 수 있다면 변환을 고르십시오. 혼합 설계도 있으며 추론하기 더 어려우므로 어느 프리픽스가 라우팅이고 어느 것이 변환인지 적어 두십시오. 그런 다음 터널 상태를 믿는 대신 양쪽 끝에서 캡처로 선택을 검증하십시오.

유용한 점검은 비대칭으로, 지사 장치에서 리소스를 요청한 뒤 응답이 본사를 떠나 지사 프리픽스로 향하는지 확인하십시오. traceroute -n 10.60.4.20 본사의 호스트에서 그 경로가 VPN 게이트웨이를 지나는지 보여 줍니다.

로그인이 아니라 인프라처럼 운영하십시오

아무도 로그인하지 않은 상태에서 게이트웨이가 어떻게 시작하고 인증하고 업데이트하고 복구되는지 정하십시오. 자격 증명 갱신, 다중 요소 프롬프트, 절전 동작, 지사가 액세스를 잃을 때 누가 응답하는지가 모두 운영 질문이 됩니다. 하나의 네트워크 경로를 공유하는 여러 사람이 게이트웨이 사용자의 개인 권한을 상속해서는 안 되므로 리소스 권한 부여, 로깅 범위, 장애 정책에는 이름이 지정된 소유자가 필요합니다. 장치별 등록을 피하려고 계정을 공유하는 것은 설계가 아닙니다.

이 구성을 지원되는 사이트 게이트웨이 와 같은 요구 사항에서 비교한 뒤 결정하십시오. 오래된 데스크톱을 재사용해도 유지보수나 복구 작업이 사라지지 않으며, 중고 가격은 운영 비용을 설명하지 않습니다.

승인된 계획 아래에서 의도한 지사 애플리케이션, 그 반환 트래픽, 거부되는 한 목적지를 검증하십시오. 성공은 이름이 지정된 지사 신원과 명시적 정책을 갖춘 자체 네트워크 서비스처럼 보이며, 연결됨이라고 표시되는 클라이언트 창이 아닙니다.