VPN w chmurze / środowiskach dedykowanych serwerów, tunele IPSec vs tinc

Jestem w trakcie projektowania konfiguracji wirtualnej sieci prywatnej dla środowiska hostingu w chmurze. Biorąc pod uwagę nasze wymagania, tak naprawdę nie widzę w tym różnicy od dedykowanego środowiska serwerowego. Chodzi o to, że chcemy, aby klienci mogli wymagać, aby ich użytkownicy łączyli się z określonymi maszynami wirtualnymi lub serwerami dedykowanymi za pomocą sieci VPN, która może zapewnić szyfrowanie pomocnicze (na przykład dla zadań drukowania przesyłanych z powrotem do sieci klienta).

Chcemy wspierać obsługę IPSec hosta dla hosta IPSec (ESP i AH) i oczywiście tunele SSH, ale żaden z nich tak naprawdę nie oferuje możliwości korzystania z adapterów VPN. Rozważamy konsekwentnie dodanie co najmniej niektórych z następujących elementów, ale ponieważ przestrzeń jest na wagę złota, chcemy ustandaryzować nie więcej niż jeden lub dwa z nich (jeden byłby lepszy):

1. Obsługa tunelu IPSec na hoście wirtualnym lub dedykowanym
2. cynk
3. PPTP

Ponieważ nasze serwery, które wykonują kopie zapasowe itp., Mogą znajdować się w różnych centrach danych, wolelibyśmy tutaj móc ponownie korzystać z naszego podejścia VPN. Wydaje się, że wyklucza to PPTP. Moje obecne myślenie jest takie, że IPSec prawdopodobnie będzie lepszy, ponieważ możemy używać standardowych adapterów VPN, ale konfiguracja routingu (w oparciu o wymagania klientów) może być znacznie trudniejsza, dlatego też patrzymy na tinc.

Który z tych dwóch jest lepszy? Czy obawiam się, że zarządzanie routingiem może być poważnym bólem głowy z IPSec, co jest nieuzasadnione? Czy jest na to łatwy sposób? Czy są jakieś inne problemy dotyczące tinc, których mi brakuje (tj. Inne niż wymaganie osobnego klienta)?

Zaktualizuj w odpowiedzi na odpowiedź @ Wintermute :

Tak, to pytanie jest z perspektywy serwera. Powodem jest to, że są to skutecznie odłączone serwery od sieci klienta. Tak, naszym rynkiem docelowym jest sieć MŚP. Tak, oczekujemy, że będziemy używać publicznych adresów IP dla każdego serwera klienta, chyba że będą potrzebować czegoś innego (a wtedy będziemy mogli porozmawiać).

Opieramy się na rozwiązaniu, w którym klienci definiują tunele IP i zakresy sieci dostępne dla tych tuneli i gdzie łączymy je z naszymi własnymi narzędziami do zarządzania (które są w fazie rozwoju), które łączą żądania klientów ze zmianami konfiguracji. Problem polega na tym, że ponieważ prawdopodobnie nie uruchomimy oprogramowania do routingu na maszynach wirtualnych i serwerach, tablica routingu musi być zarządzana statycznie, aby klienci popełniający błędy w konfiguracji stwierdzili, że VPN nie działa poprawnie.

Jest również prawdopodobne, że będziemy używać ESP przez sieć do własnych wewnętrznych operacji (np. Do tworzenia kopii zapasowych). Cała konfiguracja jest raczej złożona i ma wiele różnych perspektyw, od zorientowanej na serwer (nasz klient VPN na hostowaną instancję), zorientowanej na sieć (wewnętrzne rzeczy), zorientowanej na bazę danych (nasze narzędzia). Więc nie powiedziałbym, że pytanie jest reprezentatywne dla całego naszego podejścia (a pytania zadawane są na wielu stronach SE).

Nic z tego jednak nie wpływa na pytanie jako całość. Być może jest to przydatny kontekst.

Nie jestem pewien co do cynku, ale IPSEC jest prawie obowiązkowy. Żaden poważny biznes nie ufa PPTP.

Nie jestem pewien, w jaki sposób IPSEC wpływa na routing. Tunel to tunel to tunel niezależnie od szyfrowania. Będziesz mieć do czynienia z tymi samymi problemami: dzielenie tunelu czy nie, zachęcanie klientów do zrozumienia koncepcji / och, spójrz, czy konkretny klient IP IP koliduje z wybraną pulą VPN itp.

Wygląda na to, że celujesz w rynek małych i średnich przedsiębiorstw (pojedyncze serwery, bezpośrednie logowanie itp.), Co wyklucza bardziej wyrafinowane rozwiązania, ale i tak wymienię dwa możliwe podejścia

• pewnego rodzaju koncentrator VPN, który umożliwia profile. Wszyscy klienci logują się do koncentratora VPN, a następnie w zależności od swojego profilu / grupy / jakiejkolwiek teminologii dostawcy, uzyskują uprawnienia do korzystania z protokołu X do IP Y (tj. Własnego serwera).

• Routery wirtualne Cisco ASR1000V - każdy klient dostaje jeden, możesz następnie uruchomić bezpośrednie tunele IPSEC (z VTI, dzięki czemu routing wydaje się łatwy) lub nawet skierować MPLS z powrotem do klientów, aby router pojawił się jako kolejna gałąź w ich topologii, a następnie przydziel swoje VNIC VLAN itp. W środku, dzięki czemu uzyskują ładny wirtualny „oddział”.

• w mniejszej skali powyższej, użyliśmy monowall z wielkim efektem w tym celu (tj. każdy klient otrzymuje urządzenie wirtualne warstwy 3, które działa jako router / zapora ogniowa, łączy się z tym VPNem i uzyskuje dostęp tylko do swoich sieci VLAN) , jednak każdy router / zapora ogniowa potrzebuje własnego publicznego adresu IP.

Re: Twoje obecne podejście, zdajesz sobie sprawę, że każdy serwer potrzebuje publicznego adresu IP lub masz skomplikowany i zawiły system NAT, w którym ścieżka VPN każdego klienta jest przydzielana do jednego portu lub podobnego.

Poleciłbym zatrudnienie się w pełnym wymiarze czasu pracy w sieci, aby sprawdził każdy projekt / propozycję, którą masz, wygląda na to, że przychodzisz do niego z tła serwera.

Tak, masz rację. Wygląda na to, że będziesz musiał poradzić sobie z oddzielnymi adresami IP, chyba że agregujesz je za pośrednictwem koncentratora VPN. TBH koncentrator jest prawdopodobnie najlepszym rozwiązaniem, potrzebujesz tylko 1 dodatkowego adresu IP dla wszystkich połączeń VPN, ale jego interfejs zewnętrzny będzie musiał znajdować się w innej podsieci / VLAN niż hosty publicznego adresu IP. Poszedłbym z tym inaczej, ponieważ konfigurujesz IPSEC VPN bezpośrednio na każdym serwerze, co za koszmar