VPNs in Cloud-Hosting- / dedizierten Serverumgebungen, IPSec-Tunnel gegen Tinc

Ich bin gerade dabei, ein virtuelles privates Netzwerk für eine Cloud-Hosting-Umgebung einzurichten. Angesichts unserer Anforderungen sehe ich dies nicht wirklich anders als eine dedizierte Serverumgebung. Die Idee ist, dass Kunden in die Lage versetzt werden sollen, von ihren Benutzern die Verbindung zu bestimmten virtuellen Maschinen oder dedizierten Servern über ein VPN zu verlangen, das eine zusätzliche Verschlüsselung bereitstellen kann (z. B. für Druckaufträge, die an Kundennetzwerke zurückgesendet werden).

Wir möchten Host-to-Host-IPSec (ESP und AH) und natürlich SSH-Tunnel unterstützen, aber keiner dieser Tunnel bietet wirklich die Möglichkeit, VPN-Adapter zu verwenden. Wir erwägen folglich, zumindest einige der folgenden Elemente hinzuzufügen, aber da der Platz knapp ist, möchten wir nicht mehr als ein oder zwei davon standardisieren (eines wäre besser):

1. IPSec-Tunnelunterstützung auf dem virtuellen oder dedizierten Host
2. tinc
3. PPTP

Da sich unsere Server, die Backups usw. erstellen, möglicherweise in verschiedenen Rechenzentren befinden, möchten wir unseren VPN-Ansatz hier lieber wiederverwenden können. Dies scheint PPTP auszuschließen. Meiner Meinung nach ist IPSec wahrscheinlich besser, da wir Standard-VPN-Adapter verwenden können, aber das Einrichten des Routings (basierend auf den Kundenanforderungen) ist wahrscheinlich erheblich schwieriger, weshalb wir uns auch mit tinc befassen.

Welche dieser beiden ist vorzuziehen? Ist meine Befürchtung, dass das Routing-Management mit IPSec zu Unrecht ungerechtfertigt wird, ungerechtfertigt? Gibt es einen einfachen Weg, dies zu umgehen? Gibt es andere Fallstricke in Bezug auf Tinc, die mir fehlen (dh außer dass ich einen separaten Client benötige)?

Update als Antwort auf die Antwort von @ Wintermute :

Ja, diese Frage ist aus Serverperspektive. Der Grund dafür ist, dass dies effektiv getrennte Server von den Clientsetzwerken sind. Ja, unser Zielmarkt ist das KMU-Netzwerk. Ja, wir erwarten, dass für jeden Client-Server öffentliche IP-Adressen verwendet werden, es sei denn, diese benötigen etwas anderes (und dann können wir uns unterhalten).

Die Lösung, auf die wir uns stützen, besteht darin, dass Clients IP-Tunnel und die Netzwerkbereiche definieren, auf die diese Tunnel zugreifen, und diese mit unseren eigenen Management-Tools (die sich in der Entwicklung befinden) verknüpfen, die Kundenanforderungen mit Konfigurationsänderungen verbinden. Das Problem ist, dass, da wir wahrscheinlich keine Routing-Software auf den VMs und Servern ausführen, die Routing-Tabelle statisch verwaltet werden muss, damit Kunden, die Fehler in der Konfiguration machen, feststellen, dass die VPNs nicht richtig funktionieren.

Es ist auch wahrscheinlich, dass wir ESP über das Netzwerk für unsere eigenen internen Operationen verwenden (für Dinge wie Backups). Das gesamte Setup ist ziemlich komplex und hat viele verschiedene Perspektiven, von serverzentriert (unser Client-VPN bis gehostete Instanz) über netzwerkzentriert (internes Material) bis datenbankzentriert (unsere Tools). Daher würde ich nicht sagen, dass die Frage repräsentativ für unseren gesamten Ansatz ist (und Fragen werden auf einer Reihe von SE-Websites gestellt).

Nichts davon betrifft jedoch wirklich die Frage als Ganzes. Es ist vielleicht ein nützlicher Kontext.

Ich bin mir nicht sicher, aber IPSEC ist fast obligatorisch. Kein ernstes Unternehmen würde PPTP vertrauen.

Ich bin nicht sicher, wie sich IPSEC auf das Routing auswirkt. Ein Tunnel ist ein Tunnel ist ein Tunnel, unabhängig von der Verschlüsselung. Sie werden auf die gleichen Probleme stoßen, wenn Sie den Tunnel teilen oder nicht, um Kunden dazu zu bringen, das Konzept zu verstehen. Schauen Sie, wie die LAN-IP-Konflikte eines bestimmten Kunden mit dem von Ihnen ausgewählten VPN-Pool zusammenstoßen.

Klingt so, als würden Sie den KMU-Markt anstreben (einzelne Server, direkte Anmeldung usw.), um anspruchsvollere Lösungen auszuschließen, aber ich werde trotzdem zwei mögliche Ansätze auflisten

• eine Art VPN-Konzentrator, der Profile ermöglicht. Alle Kunden melden sich beim VPN-Konzentrator an und erhalten dann abhängig von ihrem Profil / ihrer Gruppe / der jeweiligen Anbieterteminologie die Berechtigung, Protokoll X bis IP Y (dh ihren eigenen Server) zu verwenden.

• Virtuelle Cisco ASR1000V-Router - Jeder Kunde erhält einen. Sie können dann direkte IPSEC-Tunnel ausführen (mit VTIs wird das Routing so einfach wie möglich) oder sogar MPLS direkt an die Kunden zurückleiten, sodass der Router nur als ein weiterer Zweig in seiner Topologie angezeigt wird, und dann Ihre VNICs zuweisen VLANs usw. auf der Innenseite, damit sie einen schönen virtuellen "Zweig" erhalten.

• In einer kleineren Version der oben genannten Version haben wir Monowall für diesen Zweck mit großer Wirkung verwendet (dh jeder Kunde erhält ein virtuelles Layer 3-Gerät, das als Router / Firewall fungiert, VPN in dieses Gerät und erhält nur Zugriff auf seine VLANs). Dann benötigt jedoch jeder Router / jede Firewall eine eigene öffentliche IP-Adresse.

Betreff: Bei Ihrem aktuellen Ansatz stellen Sie fest, dass jeder Server eine öffentliche IP-Adresse benötigt oder dass Sie ein kompliziertes und kompliziertes NAT-System haben, bei dem dem VPN-Pfad jedes Kunden ein einzelner Port oder ähnliches zugewiesen wird.

Ich würde empfehlen, einen Vollzeit-Netzwerker hinzuzuziehen, um alle Entwürfe / Vorschläge zu überprüfen, die Sie haben. Es hört sich so an, als würden Sie von einem Serverhintergrund aus darauf zugreifen.

Ja, du hast Recht. Sieht so aus, als müssten Sie mit separaten IPs umgehen, es sei denn, Sie aggregieren über einen VPN-Konzentrator. TBH der Konzentrator ist wahrscheinlich die beste Wahl, Sie benötigen nur 1 zusätzliche IP für alle VPN-Verbindungen, aber seine externe Schnittstelle muss sich in einem anderen Subnetz / VLAN befinden als die öffentlichen IP-Hosts. Ich würde damit weitermachen, sonst konfigurieren Sie IPSEC VPN direkt auf jedem einzelnen Server, was für ein Albtraum