Ipsec vpn 클라이언트 서브넷 분리 방법

VPN
1

수정: IKE Peer ID를 지정하는 것이 동일 인터페이스에서 모든 터널을 작동시키는 데 효과적이었습니다. 모두의 조언에 감사드립니다!

저는 Fortinet에 익숙하지 않아 현재 VM 어플라이언스를 시험 중이며, 우리의 ASA를 FortiGate로 교체하기 전에 테스트하고 있습니다. 클라이언트 VPN 옵션에 대해 많은 자료를 읽었고, SSL VPN의 취약점 때문에 IPSEC 클라이언트 VPN이 보안에 가장 적합하다고 느꼈습니다. 또한 Fortinet 자체가 최신 펌웨어에서 SSL VPN을 권장하지 않는 것 같습니다.

제가 구현하려는 것은 다음과 같은 3단계 VPN 솔루션입니다:

  • IT VPN
    • VPN 클라이언트는 IT VPN 서브넷 내 IP를 할당받으며 효과적으로 제한 없는 내부 접근 정책을 가집니다.
    • SAML 인증을 사용하여 신뢰받는 장치 + 사용자 인증 + 2FA만 허용
  • 일반 직원 VPN
    • VPN 클라이언트는 직원 VPN 서브넷 내 IP를 할당받으며 그룹 기반 접근 정책을 따릅니다.
    • IT와 유사한 SAML 인증 정책 사용
  • 계약자 VPN
    • VPN 클라이언트는 계약자 서브넷 내 IP를 할당받으며 최소한의 필수 액세스 정책을 제공합니다.
    • 역시 SAML 인증을 사용하지만 장치 검증 없이

저는 Duo를 SAML IdP로 사용하는 IPSEC를 통해 각 VPN 단계의 인증과 정책을 시험했으며, 세 터널 다 구현하는 이상적인 방법은 찾지 못했습니다. 제가 이해한 옵션은 다음과 같습니다:

  1. 각 터널에 서로 배타적인 IKEv1/2 암호 스위트 설정하여 협상을 강제하는 것. (매끄럽지 않고 이상적이지 않음)
  2. 각 IPSEC 터널을 외부 IP로 NAT하는 다른 VIP에 매핑하는 것. (가능하지만 제한된 외부 IP를 낭비하고 싶지 않음)
  3. RADIUS 인증으로 전환하고 RADIUS 응답을 통해 IP 할당하는 것. (SAML 인증이 더 사용자 친화적이고 구성도 쉽기 때문에 고려하지 않음)

우리가 원하는 VPN 계층 구조를 구현하는 더 나은 방법이 있을까요? 서브넷 기반 필터링/보고 가능성을 유지하려면 VPN 터널을 결합하는 것은 원하지 않습니다.

Fortinet이 앞으로 그룹 기반 IPSEC 클라이언트 IP 주소 할당을 지원할 계획이 있는지도 궁금합니다.

2

사용자들을 다른 IPsec 다이얼업 터널로 유도하는 데 peerid와 localid를 사용할 수 있다고 생각합니다: Technical Tip: Use of PeerID and LocalID in IPsec ... - Fortinet Community

예를 들어, “IT VPN” 터널은 Fortigate에서 peerid 'IT-VPN’으로 구성됩니다. VPN 클라이언트는 localid 'IT-VPN’을 설정하여 원하는 터널에 연결할 수 있음을 Fortigate에 알립니다.

제 Forticlient VPN에는 “remote access” > 햄버거 아이콘 > “새 연결 추가” > “IPsec VPN” > 고급 옵션 > VPN 설정 > Phase 1 > Local ID에 “localid” 설정이 있습니다.

이것이 문제 해결에 도움이 되길 바랍니다.

3

IP 기반 차별화가 필요하신가요? 필요 없다면 SAML을 유지하고, 모든 것을 하나의 터널/phase1로 병합한 후 그룹 기반 방화벽 정책으로 다양한 목적지에 접근 권한을 부여할 수 있습니다.

4

이 기능을 추가하는 중입니다. 잘 작동합니다. 다른 peer id를 사용하면 해결됩니다. 우리는 다른 IP 풀을 가지고 있으며, VPN은 정책 내에서 인터페이스로 구성되어 룰을 바로 설정할 수 있습니다.
중요한 점은 특정 Peer Id를 Accept Types로 설정하여 올바른 선택자로 패치되도록 하는 것이었습니다. 그 이전에는 다른 것에 연결된 상태였고, PSK가 실패하는 문제가 있었습니다.

5

local id로 차별화할 수 있습니다.

6

서로 다른 암호화 알고리즘과 PSK를 사용하는 여러 IPsec 터널을 설정하세요. 그리고 "mode-cfg"를 "on"으로 설정하여 클라이언트에 서로 다른 IP 주소를 할당할 수 있습니다.
이것이 나의 고객이 사용하는 방법이며 매우 잘 작동합니다.
내가 선호하는 해결책은 FortiClient를 사용하는 경우, FSSOMA와 FortiAuthenticator를 함께 사용하여 모든 클라이언트가 같은 IP 서브넷을 사용하더라도 FSSO를 통해 액세스를 제어하는 방식입니다.

7

이 문제를 접했는데, 나의 Windows 10 22H2 Hyper-V VM이 성공적으로 연결된 후 라우팅 테이블에 이상한 0.0.0.0/0 경로를 작성하는데 이로 인해 로컬, 인터넷, VPN 연결이 깨집니다.

IPv4 라우팅 테이블

활성 경로:

네트워크 대상 네트마스크 게이트웨이 인터페이스 메트릭

0.0.0.0 0.0.0.0 192.168.20.1 192.168.20.25 25
(vpn) 0.0.0.0 0.0.0.0 192.168.2.8 192.168.2.7 25

이상하게도…신선한 VM에서는 0.0.0.0/0 경로가 작성되지 않으며, 모든 것이 예상대로 작동합니다. 또한, 예전 RA IPSec VPN 터널에 Peer ID를 추가하기 전에 이런 문제가 없었습니다.

최근 FortiClient를 7.4.0.1658로 업그레이드했고, 재설치 후 문제가 해결됩니다.

수정 - 제거 후 재부팅 후 재설치가 잘 작동하며 잘못된 라우팅이 기록되지 않습니다. 이제 VPN이 정상 작동합니다.

8

감사합니다. 아직 시도하지 않았지만 곧 해보겠습니다. Peer ID는 사용자 이름으로 사용된다고 들었기 때문에 만지지 않았습니다.

9

네, 여러 시스템이 서브넷 기반 규칙을 사용하는데, 이는 방화벽 뒤에서도 보안 위험이 크다는 의미입니다:

  • 웹 관리자 URL에 대한 IP 기반 접근 제한 (같은 포트의 사용자 프론트엔드와 동시에 운영)
  • 서브넷 기반 네트워크 트래픽 볼륨 알림
  • 서브넷 기반 IDS 행동 모니터링

각 계층이 고유한 소스 인터페이스를 갖는 것이 방화벽 정책을 훨씬 깔끔하고 실수 가능성을 줄일 수 있다고 생각합니다.

10

맞습니다. 이것은 순수 테스트용으로, 최신 7.6.0에서 다양한 기능을 경험하려 합니다. IKE v1 터널을 동일 암호와 PSK로 사용하고 있으며, Peer ID도 다르게 설정했습니다. 그리고 Golle이 제공한 지침에 따라 Fortinet 클라이언트에 Local ID도 설정하였습니다.

지금까지 Local ID를 클라이언트 측에 구성할 때, 해당 Peer ID와 일치하는 VPN 터널에만 연결된 것을 확인했습니다.

Fortigate와 Forticlient 간에 IKE Phase 1/2 암호와 키 수명이 일치하는지 확인하세요. 본인은 실험하면서 몇 차례 키 수명이 일치하지 않는 문제가 있었으며, 기본 설정을 변경하지 않았기 때문일 수 있습니다.

11

감사 인사해줘서 고마워요! Reddit 사용자가 감사 인사를 하는 모습을 보는 건 정말 좋네요 :slight_smile:

12

현재 IKEv1과 SAML 인증, Peer ID만 이용하고 있으며 IKEv2는 아직 작동하지 않습니다. 온라인 검색에서 XAUTH 문제로 생각했는데, 지금은 IKEv2용 SAML 가이드도 있어서 무엇이 누락됐는지 모르겠습니다.

13

IKEv2는 peer ID와 XAuth 프레임워크를 사용하지 않기 때문에 EAP 인증을 활성화하고 RADIUS 서버를 사용해야 합니다. EAP는 CLI 전용으로 구성할 수 있으며, 가이드는 이곳에서 확인할 수 있습니다.