Bulut barındırma / özel sunucu ortamlarındaki VPN'ler, IPSec tünelleri ve tinc


9

Bir bulut barındırma ortamı için sanal özel ağ kurulumu tasarlama sürecindeyim. Gereksinimlerimiz göz önüne alındığında, bunu özel bir sunucu ortamından farklı görmüyorum. Buradaki fikir, müşterilerin, yardımcı şifreleme sağlayabilen bir VPN kullanarak (örneğin, müşteri ağlarına geri gönderilen yazdırma işleri için) kullanıcılarının belirli sanal makinelere veya özel sunuculara bağlanmasını zorunlu kılmalarını istemektir.

IPSec'i (ESP ve AH) ve elbette SSH tünellerini barındırmak için ana makineyi desteklemeye çalışıyoruz, ancak bunların hiçbiri gerçekten VPN bağdaştırıcıları kullanma yeteneği sunmuyor. Sonuç olarak aşağıdakilerin en azından bir kısmını eklemeyi düşünüyoruz, ancak alan bir primde olduğu için bunlardan bir veya ikisinden daha fazlasını standartlaştırmamak istiyoruz (biri daha iyi olurdu):

  1. Sanal veya özel ana bilgisayarda IPSec tünel desteği
  2. tinc
  3. PPTP

Yedek vb. Alan sunucularımız farklı veri merkezlerinde olabileceğinden, burada VPN yaklaşımımızı yeniden kullanmayı tercih ederiz. Bu PPTP'yi dışlıyor gibi görünüyor. Şu anki düşüncem, IPSec'in daha iyi olacağı, çünkü standart VPN bağdaştırıcılarını kullanabileceğimiz, ancak yönlendirmeyi (müşteri gereksinimlerine göre) kurmanın muhtemelen daha zor olacağı, bu yüzden de tenteye bakıyoruz.

Bu ikisinden hangisi tercih edilir? Yönlendirme yönetiminin IPSec'in haksız olmasıyla ciddi bir baş ağrısı olabileceğine dair korkum mu? Bunun kolay bir yolu var mı? Eksik olduğum tentürle ilgili başka gotcha'lar var mı (yani ayrı bir müşteri istemek dışında)?

@ Wintermute'un cevabına yanıt olarak güncelleme :

Evet, bu soru sunucu açısından. Bunun nedeni, sunucuların istemcinin ağlarından etkin bir şekilde bağlantısı kesilmiş olmasıdır. Evet hedef pazarımız KOBİ ağı. Evet, farklı bir şeye ihtiyaç duymadıkça (ve sonra konuşabiliriz), her istemci sunucusu için genel IP'ler kullanmayı umuyoruz.

Yöneldiğimiz çözüm, müşterilerin IP tünellerini tanımladığı ve bu tünellerin erişebildiği ağ aralıklarını ve bunları müşteri isteklerini yapılandırma değişikliklerine bağlayan kendi yönetim araçlarımızla (geliştirilmekte olan) birleştirdiğimiz bir çözümdür. Sorun şu ki, vms ve sunucularda yönlendirme yazılımı çalıştırmadığımızdan, yapılandırmada hata yapan müşterilerin VPN'lerin düzgün çalışmadığını görmeleri için yönlendirme tablosunun statik olarak yönetilmesi gerekiyor.

Ayrıca kendi dahili işlemlerimiz için (yedeklemeler gibi) ağ üzerinden ESP kullanacağız. Tüm kurulum oldukça karmaşıktır ve sunucu merkezli (istemci vpn'mizden barındırılan örneğe) ağ merkezli (dahili şeyler), veritabanı merkezli (araçlar) kadar birçok farklı perspektife sahiptir. Bu yüzden, sorunun tüm yaklaşımımızı temsil ettiğini söyleyemem (ve bir sürü SE sitesinde soru soruluyor).

Bunların hiçbiri soruyu bir bütün olarak gerçekten etkilemez. Belki de yararlı bir bağlamdır.

Yanıtlar:


6

Tenten emin değilim ama IPSEC neredeyse zorunlu. Hiçbir ciddi şirket PPTP'ye güvenmez.

IPSEC'in yönlendirmeyi nasıl etkilediğinden emin değilim. Tünel şifreleme ne olursa olsun bir tüneldir. Aynı sorunla yeniden karşılaşacaksınız: tünel bölünmüş ya da bölünmemiş, müşterilerin kavramı anlamasını sağlamak / seçtiğiniz bir VPN havuzuyla belirli bir müşterinin LAN IP çatışmasına bakmak vb.

KOBİ pazarını (bireysel sunucular, doğrudan giriş vb.) Hedeflediğiniz gibi görünüyor, böylece daha sofistike çözümler öneriyor, ancak yine de iki olası yaklaşımı listeleyeceğim

  • profillere izin veren bir çeşit VPN yoğunlaştırıcı. Tüm müşteriler VPN yoğunlaştırıcıya giriş yapar, ardından profillerine / gruplarına / satıcı teminolojisine bağlı olarak X protokolünü IP Y'ye (yani kendi sunucularına) kullanma izinleri alır.

  • Cisco ASR1000V sanal yönlendiriciler - her müşteri bir tane alır, daha sonra doğrudan IPSEC tünellerini (VTI'larla yönlendirmeyi kolaylaştırır) veya hatta MPLS'yi müşterilere geri yönlendirebilir, böylece yönlendirici topolojilerinde başka bir dal olarak görünebilir, ardından VNIC'lerinizi tahsis edebilirsiniz. VLAN vb.İçeride güzel bir sanal 'dal' elde ederler.

  • Yukarıdakilerin daha küçük ölçekli bir versiyonunu kullandığımızda, bu amaç için büyük bir etki yaratmak için monowall'ı kullandık (yani her müşteri, bir yönlendirici / güvenlik duvarı görevi gören bir katman 3 sanal cihaz alır, bu cihaza VPN ve yalnızca VLAN'larına erişir) ancak, her yönlendiricinin / güvenlik duvarının kendi genel IP adresine ihtiyacı vardır.

Ynt: mevcut yaklaşımınız, her sunucunun genel bir IP'ye ihtiyacı olduğunu veya her müşterinin VPN yolunun tek bir bağlantı noktası veya benzeri tahsis edildiği karmaşık ve kıvrımlı bir NAT sisteminiz olduğunu fark ediyorsunuz.

Sahip olduğunuz herhangi bir tasarım / öneriye bakmak için tam zamanlı bir ağa sahip olmanızı tavsiye ederim, bir sunucu arka planından geliyormuşsunuz gibi görünüyor.


2
Ayrıca bu küçük bir nitpick gibi görünebilir, ancak ESP'yi başka bir protokol üzerinde önceden bir tünel oluşturmadan TCP bağlantı noktasıyla eşleyemezsiniz. Bunun nedeni ESP'nin IP düzeyinde çalışması ve bu nedenle bağlantı noktası numaralarına erişimi olmamasıdır. UDP üzerinden ESP olan Nat-T var ama bu daha da karmaşık. Her neyse, bu düzenlemeyi önerebileceğimi düşündüm.
Chris Travers

1

Evet haklısın. Bir VPN yoğunlaştırıcısıyla toplanmadığı sürece ayrı IP'lerle uğraşmanız gerekecek gibi görünüyor. TBH yoğunlaştırıcı muhtemelen en iyi bahistir, tüm VPN bağlantıları için sadece 1 ekstra IP'ye ihtiyacınız olacaktır, ancak dış arayüzünün genel IP ana bilgisayarlarından farklı bir alt ağ / VLAN'da bulunması gerekir. Bununla devam edeceğim, aksi takdirde IPSEC VPN'yi her bir sunucuda doğrudan yapılandırıyorsunuz, ne kabus

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.