Inhalt
(this table of content was created by Markdown Menu)
Einführung
Ziele eines VPN-Hubs ist die Bündelung sämtlicher Anfragen zu einem Rechenzentrum über eine zentrale VPN-Verbindung. Die Alternative wäre die Einrichtung eines VPN-Gateways in ein Rechenzentrum von jedem virtuellen Netzwerk der einzelnen DevOps-Teams aus. Langfristig wäre dieses Vorgehen wegen der hohen Anzahl an VPN-Verbindungen in das Rechenzentrum nicht zu empfehlen. Zu anderen kann das VPN-Hub von einem einzelnen Team organisiert werden und die DevOps-Teams müssten sich nicht in die eventuell neue Thematik der VPN-Anbindung einarbeiten. Die DevOps-Teams müssen sich nur noch mit ihrem VNet an das VPN-Hub anbinden und bekommen damit einen sofortigen Zugang zum OnPremises-Rechenzentrum o.ä..
Es ist zu empfehlen, dass man sich im Vorfeld über die Verteilung der IP-Ranges zwischen dem Rechenzentrum und Azure abstimmt. Die IP-Ranges zwischen beiden dürfen sich im optimalen Fall nicht überlappen, damit eine Integration erfolgen kann und NATting, also eine Umschreibung der IP-Adressen nicht notwendig wird.
Hier wird erklärt wie man ein
- VPN-Hub in Azure aufbaut
- Ein VNet mit dem VPN-Hub konnektiert und
- OnPremises-DNS-Server anbindet
Aufbau des VPN-Hubs
Die Ressourcen
Ein VPN-Hub besteht im Minimum aus fünf Ressourcen um lauffähig zu sein.
Einem normalen Virtual Network (VNet in Azure). Man beachte bitte, dass es nur ein Virtual Network Gateway je VNet geben kann.
Ein Virtual Network Gateway als “VPN Gateway” in das Rechenzentrum. Dieses Gateway ermöglicht schlussendlich, dass sich andere _VNet_s in das OnPremises Rechenzentrum konnektieren können.
Einem Local Network Gateway das die Azure Schnittstelle zum OnPremise-Rechenzentrum ist.
Einer Public IP für das VPN Gateway. Über diese Azure IP wird die VPN-Schnittstelle im Rechenzentrum angebunden.
Die Connection, die die letztendliche Verbindung zwischen Azure und dem OnPremises-VPN-Server herstellt.
Das VNet
Für das Virtual Network (VNet) in Azure sind keine besonderen Konfigurationen notwendig. Über das Azure Portal ist die Konfiguration wie folgt zu wählen:
Die Konfiguration nach eigenen Bedürfnissen frei konfigurierbar. Bzgl. der IPAdresse ist zu beachten, dass es sich bei dem VNet um ein Transfernetzwerk handelt. Die IPAdressen treten auf Seiten des OnPremises-RZ nicht in Erscheinung. D.h. diese können auch mit den genutzten IPRanges im OnPremises-RZ überlappen.
Das Subnet bleibt leer. Dieses wird durch das Gateway bestimmt.
Mit mehr Informationen muss das VNet nicht deployed werden.
Das VPN-Gateway
Für das VPN-Gateway benötigt man als Azure Service ein Virtual Network Gateway. Um diesen als VPN-Gateway zu konfigurieren ist das folgende Setting zu wählen.
Die wichtigen Settings sind
Gateway type: VPN
VPN type: Route-based
SKU: Die SKU bestimmt die Bandbreite mit der das VPN angebunden ist. Die Größe der Bandbreite definiert neben des Durchlassvolumens auch die Kosten für das Gateway. Daher sollte es so groß wie nötig aber so klein wie möglich gewählt werden. Bitte beachtet hier, dass diese Bandbreite ausschließlich von Azure garantiert wird. Wenn auf Seiten des OnPremises-Rechenzentrum nur eine geringere Bandbreite möglich ist, dann kann man die gewählte Bandbreite nie komplett ausnutzen. Mehr Informationen zu den Größen und den Preisen der Bandbreite: https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpngateways
Virtual Network: Hier wählt man das zuvor erstellte VNet aus.
Gateway subnet address range: Wird durch das gewählte VNet automatisch bestimmt und angelegt. Es nimmt immer die komplette IP Range des VNet als Subnet.
Public IP Adress: Hier kann man eine neue oder eine bestehende PublicIP nutzen: Bitte beachtet.
Die Erstellung der realen IP-Adresse (z.B. 18.139.234.89) erfolgt erst mit der Erzeugung der Local Network Gateway. Erst dieser Service “beantragt” die reale IP. Vorher kennt man die reale IP nicht. Wenn man sich eine neue Public IP Adress erzeugen lässt, dann ist dies eine dynamische Adresse. Wenn ein Gateway weggeworfen wird, dann wird die IP freigegeben, auch wenn man die Public IP Adress als Azure Service weiterhin behält. D.h. auch wenn dann eine bestehende Public IP Adress nutzt, bekommt man eine neue reale Adresse zugewiesen. Da die VPN Verbindung über ihre Public IP Adress vom OnPremises-Rechenzentrum eingerichtet werden muss, muss ein Wechsel der Public IP Adress auch immer dem Rechenzentrum mitgeteilt werden. Dies kann verhindert werden wenn man vorher eine Public IP Adress in der statische Variante erzeugt. Das kann dann so deployed werden. Es kann einige Zeit dauern bis alles von Azure eingerichtet und die Public IP verfügbar ist. Erst dann kann man weitermachen. Die PublicIP muss man sich kopieren.
Das Local network gateway
Für die Verbindung zwischen dem OnPremises-RZ und Azure muss eine Local network gateway eingerichtet werden.
IP adress: Hier ist die öffentliche IP Adresse des VPN Server auf Seiten des Rechenzentrums einzufügen.
Adress space: Für die Kommunikation mit dem OnPremieses-RZ sind die IP Ranges einzugeben, die im Rechenzentrum für die Kommunikation mit Azure freigegeben sind. Nur über diese IP-Ranges kann eine Kommunikation von Azure Services mit den Servern des Rechenzentrums erfolgen. Eine Anpassung nachträglich ist aber ohne weiteres möglich.
Die connection
Mit der connection wird die wirkliche Verbindung zwischen Azure und dem OnPremises-RZ eingerichtet.
Connection type: Welche Art von VPN Verbindung soll zwischen dem OnPremises-RZ und Azure hergestellt werden. Die übliche ist eine Site-to-site (IPsec)gesicherte Verbindung mit dem VPN im Rechenzentrum.
Shared key (PSK): Der Shared key ist eine frei zu bestimmende Schlüssel aus Zahlen und Buchstaben. Eine normale UUID ohne die Sonderzeichen ist z.B. zu empfehlen. Dieser Key stellt den “Kommunikationsschlüssel” zwischen dem VPN-Gateway auf Seiten von Azure sowie dem OnPremises-RZ dar. Üblicherweise sind die Public IP Adress sowie dieser PSK der Administration des Rechenzentrums mitzuteilen, da diese beide beiderseitig eingetragen werden müssen.
Mehr ist nicht notwendig. Nach erfolgten Deployment in Azure sollte in den Properties der Connection “Connected” als Status angezeigt werden.
Anbindung eines Netzwerks
Das Peering
Das VPN-Hub kann jetzt von jedem anderen VNet angebunden werden. Dazu muss man in dem betreffenden VNet ein Peering einrichten. Man beachte, dass man das Peering immer in zwei Richtungen einrichtet. Vom VNet zum VPNHub und vom VPNHub zum VNet.
Die Namen für beide Richtungen können frei vergeben werden.
Configure forwarded traffic setting: Das Forwarding muss für beide Richtungen aktiviert werden, damit Daten über den VPN Hub weitergeleitet werden können und nicht blockiert werden.
Dies kann jetzt Deployed werden. Man beachte das das Peering für das VPN Hub und das andere VNet eingerichtet wird. Die Peering Einträge findet man im Azure Portal im jeweiligen Virtual Network.
Der Transit Gateway
Um die Kommunikation über den VPN Hub zu erlauben muss das VPN Hub als Transit Gateway eingerichtet werden. Dieses wird im Peering nachkonfiguriert.
Im VNet des VPN Hubs findet man jetzt unter Peering die eine Richtung des Peerings.
Configure gateway transit setting: Das Gateway trasnit muss erlaubt werdenm, damit der VPN Hub Daten aus anderen VNets an das OnPremises-RZ weiterleitet.
Der Remote Gateway
Der VPN Hub soll ja als Gateway in das Rechenzentrum fungieren. Daher ist der VPN Hub mit seinem Virtual Gateway für das andere VNet ein Remote Gateway. Das andere VNet muss so eingerichtet werden, dass diese den VPN Hub als Remote Gateway nutzen kann.
Configure Remote Gateway settings: Im neu angelegten Peering des anderen VNets kann unter Peering das VPN Hub als Remote Gateway angelegt werden.
