클라우드 호스팅 / 전용 서버 환경의 VPN, IPSec 터널 및 Tinc


9

클라우드 호스팅 환경을위한 가상 사설망 설정을 설계하는 중입니다. 우리의 요구 사항을 감안할 때 실제로 이것이 전용 서버 환경과 다른 것으로 보지 않습니다. 아이디어는 고객이 보조 암호화를 제공 할 수있는 VPN을 사용하여 사용자가 특정 가상 머신 또는 전용 서버에 연결하도록 요구할 수 있도록하는 것입니다 (예 : 고객 네트워크에 다시 제출 된 인쇄 작업의 경우).

우리는 호스트 대 호스트 IPSec (ESP 및 AH), 물론 SSH 터널을 지원하는 방법을 찾고 있지만 VPN 어댑터를 사용할 수있는 기능은 없습니다. 결과적으로 최소한 다음 중 일부를 추가하는 것을 고려하고 있지만 공간이 부족하기 때문에이 중 하나 또는 두 개 이상으로 표준화하려고합니다 (하나는 더 좋을 것입니다).

  1. 가상 또는 전용 호스트에서 IPSec 터널 지원
  2. 틴크
  3. PPTP

백업 등을 수행하는 서버는 다른 데이터 센터에있을 수 있으므로 여기에서 VPN 접근 방식을 재사용하는 것이 좋습니다. 이것은 PPTP를 배제하는 것처럼 보입니다. 필자의 현재 생각은 표준 VPN 어댑터를 사용할 수 있기 때문에 IPSec이 더 나을 가능성이 있지만 고객 요구 사항에 따라 라우팅을 설정하는 것이 훨씬 더 어려울 수 있기 때문에 우리는 또한 주석을보고 있습니다.

이 둘 중 어느 것이 바람직합니까? IPSec이 정당화되지 않은 상태에서 라우팅 관리가 심각한 두통 일 가능성이 있습니까? 이 문제를 해결하는 쉬운 방법이 있습니까? 내가 놓친 틴크에 관한 다른 문제가 있습니까 (즉, 별도의 클라이언트가 필요하지 않음)?

@Wintermute의 답변에 따라 업데이트 :

예,이 질문은 서버 관점에서 비롯된 것입니다. 그 이유는 서버가 클라이언트의 네트워크에서 효과적으로 연결이 끊어 졌기 때문입니다. 예, 우리의 목표 시장은 중소기업 네트워크입니다. 그렇습니다. 우리는 각기 다른 클라이언트 서버가 다른 것을 필요로하지 않는 한 (그리고 우리가 대화 할 수있는 경우가 아니라면) 각각의 공용 IP를 사용할 것으로 기대합니다.

우리가 기대하는 솔루션은 클라이언트가 IP 터널과 해당 터널에서 액세스 할 수있는 네트워크 범위를 정의하고 고객 요청을 구성 변경에 연결하는 자체 관리 도구 (개발중인)와 함께 연결하는 솔루션입니다. 문제는 vms 및 서버에서 라우팅 소프트웨어를 실행할 가능성이 없기 때문에 라우팅 테이블을 정적으로 관리해야하므로 구성에 실수를 한 고객은 VPN이 제대로 작동하지 않을 수 있습니다.

또한 자체 내부 작업 (백업 등)을 위해 네트워크를 통해 ESP를 사용할 수도 있습니다. 전체 설정은 다소 복잡하며 서버 중심 (클라이언트 VPN에서 호스팅 인스턴스까지)에서 네트워크 중심 (내부 항목), 데이터베이스 중심 (도구)에 이르기까지 다양한 관점이 있습니다. 그래서 나는 그 질문이 우리의 모든 접근 방식을 대표한다고 말하지 않을 것입니다 (그리고 질문은 많은 SE 사이트에서 묻고 있습니다).

이 중 어느 것도 실제로 질문 전체에 영향을 미치지 않습니다. 그래도 유용한 컨텍스트 일 ​​것입니다.

답변:


6

tinc에 대해서는 확실하지 않지만 IPSEC는 거의 필수입니다. PPTP를 신뢰하는 기업은 없습니다.

IPSEC가 라우팅에 어떤 영향을 미치는지 확실하지 않습니다. 터널은 암호화와 상관없이 터널입니다. 터널 분할 여부, 고객이 개념을 이해하도록 유도 / 특정 고객의 LAN IP가 선택한 VPN 풀과 충돌하는 모습 등 동일한 문제가 발생합니다.

보다 정교한 솔루션을 배제하기 위해 SME 시장 (개별 서버, 직접 로그인 등)을 목표로하는 것처럼 들리지만 어쨌든 두 가지 가능한 접근법을 나열하겠습니다.

  • 프로파일을 허용하는 일종의 VPN 집중 장치. 모든 고객은 VPN 집중 장치에 로그인 한 다음 프로필 / 그룹 / 공급 업체 용어에 따라 프로토콜 X에서 IP Y (예 : 자체 서버)를 사용할 수있는 권한을 얻습니다.

  • Cisco ASR1000V 가상 라우터-각 고객이 하나를 획득 한 후 직접 IPSEC 터널을 실행 (VTI를 사용하여 라우팅이 쉽게 나타남)하거나 MPLS를 고객에게 직접 전달하여 라우터가 토폴로지의 다른 브랜치로 표시되도록 한 다음 VNIC를 할당 할 수 있습니다. 내부의 VLAN 등은 멋진 가상 브랜치를 얻습니다.

  • 위의 소규모 버전에서, 모노 월을 사용하여이 목적을 달성했습니다 (즉, 각 고객은 라우터 / 방화벽 역할을하는 레이어 3 가상 장치를 얻음으로써 VPN을이 장치로 가져오고 VLAN에만 액세스 할 수 있습니다). 그러나 각 라우터 / 방화벽에는 자체 공용 IP 주소가 필요합니다.

Re : 현재 접근 방식에서는 각 서버에 퍼블릭 IP가 필요하거나 각 고객의 VPN 경로에 단일 포트 또는 이와 유사한 포트가 할당되는 복잡하고 복잡한 NAT 시스템이 있다는 것을 알고 있습니다.

나는 당신이 가지고있는 디자인 / 제안을 살펴보기 위해 전임 네트워커를 얻는 것이 좋습니다. 서버 배경에서 오는 것처럼 들립니다.


2
또한 이것은 작은 nitpick처럼 보이지만 다른 프로토콜을 통해 이전 터널을 설정하지 않으면 TCP 포트로 ESP를 다시 매핑 할 수 없습니다. ESP가 IP 수준에서 작동하기 때문에 포트 번호에 액세스 할 수 없기 때문입니다. UDP를 통한 ESP 인 Nat-T가 있지만 훨씬 더 복잡합니다. 어쨌든 나는이 편집을 제안 할 것이라고 생각했다.
Chris Travers

1

네 말이 맞아. VPN 집중 장치를 통해 집계하지 않으면 별도의 IP를 처리 해야하는 것처럼 보입니다. 집중 장치가 TBH 인 것이 가장 좋습니다. 모든 VPN 연결에 1 개의 추가 IP 만 있으면되지만 외부 인터페이스는 공용 IP 호스트와 다른 서브넷 / VLAN에 있어야합니다. 그렇지 않으면 각 개별 서버에서 IPSEC VPN을 직접 구성하는 것입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.