Azure: Basiswissen für Administratoren

Gateways und Verbindungen

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Ein Gateway verbindet zwei Netzwerke mittels Site-to-Site-VPN oder Express Route miteinander, um Azure als verlängertes Datacenter nutzen zu können. Verbindungen (Azure Connections) erlauben den Betrieb permanenter Datenverbindungen zwischen getrennten Netzen. Dies erfolgt mittels "vnet-to-vnet", "site-to-site" oder Express Route.
09:27

Transkript

Wenn Sie Azure produktiv in Betrieb nehmen wollen, dann müssen beziehungsweise sollten Sie Azure natürlich an Ihr eigenes Unternehmensnetzwerk anbinden. Die Grundlage dafür ist ein sogenanntes "Gateway". Ein Gateway innerhalb von Azure lässt sich im Grunde vergleichen mit einem virtuellen Router, der zwei getrennte Netze miteinander verbindet. Bevor Sie zur Tat schreiten und ein VPN-Gateway erzeugen, empfehle ich Ihnen, sich die hier gezeigte Dokumentation in Ruhe anzuschauen und auch einen Blick in die VPN-Gateway-FAQs zu riskieren, um sich wirklich zu informieren, welche Auflagen Sie bei dem Betrieb eines VPN Gateway in Azure erfüllen müssen. Vor allem auch deswegen, weil das Ausrollen eines VPN Gateway in Azure eine Dreiviertelstunde in Anspruch nehmen kann. Aber ganz auf Anfang. Wir gucken uns an, was ist denn ein VPN-Gateway in Azure überhaupt und wozu kann man es benutzen. Ein VPN Gateway ist, wie ich bereits gesagt habe, die Grundlage für das Verbinden von virtuellen Netzwerken. Das kann grundsätzlich folgende Szenarien beinhalten. Wir scrollen etwas weiter nach unten, um uns das erste Szenario anzuschauen, und zwar ist das hier die sogenannte "Site-to-Site-VPN-Verbindung" über einen IPsec-Tunnel. Das bedeutet, wir haben hier ein virtuelles Netzwerk, das in Azure läuft mit einem bestimmten IP-Adressbereich. Und dann haben wir hier unser lokales Netzwerk und über diesen IPsec-Tunnel wird eine Verbindung mittels VPN-Gateway von Ihrem Unternehmensnetzwerk zum Azure-basierten Netzwerk hergestellt. Dies ist nützlich, wenn Sie in diesem Unternehmensstandort schätzungsweise mehr als 100 Mitarbeiter haben, die sich nahtlos mit den Ressourcen, die im Azure liegen, verbinden möchten, ohne eine manuelle VPN-Verbindung aufbauen zu müssen. Hierfür sind allerdings gewisse Voraussetzungen erforderlich. Man sieht das hier schon in der schematischen Darstellung, dass dies natürlich nur dann funktionieren kann, wenn sich die IP-Adressbereiche dieser Netzwerke nicht überlappen beziehungsweise überschneiden und außerdem müssen Sie in Ihrem Unternehmen ein lokales VPN-Gerät haben mit einer öffentlichen IP-Adresse. Nachdem wir uns die Site-to-Site-VPN Topologie angeschaut haben, werfen wir einen Blick auf die Multi-Site-Topologie, die im Grunde folgendermaßen aussieht: Wir haben zwei unterschiedliche Standorte und wir haben zwei IPsec-Tunnels, aber wir haben nur ein VPN-Gateway pro Azure-basiertes Netzwerk. Das ist schon eine wichtige Limitation, die es zu erfassen und zu begreifen gilt, dass ich pro Azure-basiertem VNet nur ein VPN Gateway erzeugen kann. Ausnahme ist ein ExpressRoute-Gateway. Ein ExpressRoute-Gateway kann ich noch zusätzlich an das VNet anhängen. Dazu aber später. Erst einmal schauen wir uns das Point-to-Site-VPN-Modell an, Das schaut so aus, dass wir auch hier für unser "VNet1" nur ein VPN Gateway betreiben können und hier gibt es dann mehrere, je nachdem wie viele ich brauche, Point-to-Site-Tunnel-Verbindungen zu einzelnen Clients. Das können dann beispielsweise Freiberufler sein oder Partner, mit denen ich dezentral zusammenarbeite, die sich also nicht in einem Branch Office beziehungsweise in einer Zweigstelle oder Niederlassung befinden, wo es sich lohnen würde, eine Site-to-Site- VPN-Verbindung aufzubauen. Die können sich dann über eine sogenannte Point-to-Site-VPN-Verbindung mit dem virtuellen Netzwerk in Azure verbinden. Das vorletzte Szenario ist eine sogenannte "VNet-to-VNet-Verbindung". Eine VNet-to-VNet-Verbindung impliziert, dass wir zwei Azure Subscriptions oder auch zwei Azure-basierte Netzwerke haben und dann über zwei VPN-Gateways auch hier wieder über einen IPsec-Tunnel eine Verbindung herstellen können, um beispielsweise virtuelle Maschinen, die in diesem VNet laufen, mit virtuellen Maschinen, die mit diesem VNet laufen, miteinander zu verbinden. So eine VNet-to-VNet-Verbindung ist übrigens auch ein schöner Kniff, um Ressourcen aus dem Resource Manager und Ressourcen aus dem Classic Portal miteinander sprechen zu lassen. Und als Letztes schauen wir uns einen Mischbetrieb an, und zwar die parallel bestehende Site-to-Site- und ExpressRoute-Verbindungen. Wir hatten ja gesagt, dass jedes VNet nur ein VPN-Gateway haben kann, das bleibt auch bestehen, aber ich kann noch ein zweites Gateway in Form eines ExpressRoute-Gateways an mein VPN anheften und sozusagen einen dualen Betrieb zwischen ExpressRoute- und meinem VPN-Gateway gewährleisten. Das sind die Betriebsformen, die ich bei einem Azure-basiertem Gateway laufen lassen kann. Der Sinn hinter dieser Topologie ergibt sich aus der Anforderung der Hochverfügbarkeit für das lokale Headquarter, was natürlich wichtiger ist, als die lokale Stelle, die wir hier haben. Das lokale Headquarter hat deswegen einmal eine IPsec-Verbindung und falls die abreißen sollte, gibt es immer noch die ExpressRoute-Verbindung, um dafür zu sorgen, dass das besonders wichtige lokale Headquarter permanent und performant an das Azure "VNet1" angebunden ist. Nun aber genug der Theorie, jetzt erstellen wir unser Gateway. Dieses Gateway für virtuelle Netzwerke hat natürlich ihren Dienst und daraus erstellen wir eine Dienstinstanz. Die nenne ich "gatewaydemo" und jetzt muss ich mich entscheiden, ist das ein Gatewaytyp "VPN" oder "ExpressRoute". Je nachdem, wofür ich mich entscheide, habe ich hier unterschiedliche SKUs zur Verfügung, die entsprechend unterschiedliche Leistungen, aber natürlich auch Kosten verursachen. Bei einem VPN-Gateway kann ich entweder "dynamisch" routen oder "statisch" routen. Wenn ich dynamisch route, habe ich eine relativ große Auswahl an SKUs, die entsprechend Leistung und Kosten mit sich bringen. Wenn ich statisch route über Richtlinien, gibt es nur die "Basic" SKU. Das heißt, ich route jetzt dynamisch über die Basic SKU. Jetzt wählen wir ein virtuelles Netzwerk aus. Und dieses virtuelle Netzwerk muss einen ausreichend großen Adressbereich haben, damit die Adressen, die vom sogenannten "Gatewaysubnet" in Anspruch genommen werden, ausreichend genutzt werden können beziehungsweise entsprechend großer Raum vorhanden ist. Dann brauchen wir eine public IP Address, die in dem Fall auch dediziert sein muss. Das heißt, diese IP-Adresse hier wird bereits verwendet, dementsprechend erstellen wir eine neue public IP Address und weisen das Ganze entsprechend zu. Falls Sie Probleme haben sollten, das VNet, das Sie anbinden möchten, zu finden, achten Sie bitte auf den Standort, der muss natürlich übereinstimmen. Anschließend klicken wir auf "Erstellen" und die Dienstinstanz rollt aus, was wiederum eine Dreiviertelstunde dauern kann. Dementsprechend machen wir jetzt einen Zeitsprung und gucken uns hinterher das Ergebnis an. Jetzt ist unser erster Gateway erfolgreich erstellt worden und wir können uns umschauen und der wesentliche Punkt ist hier in den Verbindungen zu finden, die wir jetzt auf Basis dieses Gateways aufbauen können. Vom Prinzip her ist es ähnlich, wie das, was Sie bereits gesehen haben, aber Achtung! Wenn wir jetzt eine VNet-to-VNet-Verbindung aufbauen möchten, brauchen wir natürlich zwei Gateways. Also zwei Azure-basierte VNets mit entsprechenden VMs darin und dann jeweils einem Gateway, um eine VNet-to-VNet-Verbindung aufbauen zu können. Das heißt, wir haben ein erstes Gateway und ein zweites Gateway, was wir benennen beziehungsweise erst noch heraus erstellen müssen. Dann haben wir eine Site-to-Site-VPN-Verbindung, die sich einmal mit einem Azure-basiertem virtuellen Gateway verbindet und mit einem sogenannten "lokalen Netzwerkgateway", was wir auch erst noch erstellen müssten. Das geht allerdings relativ einfach. Es gibt einen Bezeichner und dann geben wir hier die öffentlich erreichbare IP-Adresse von unserem Netzwerk-Device ein, um entsprechend die Site-to-Site-VPN-Verbindung vorbereiten beziehungsweise einrichten zu können. Dann gibt es noch Option Nummer 3, ExpressRoute. Auch hier muss natürlich eine entsprechende ExpressRoute-Verbindung beziehungsweise in Circuit eingerichtet sein. Und last, but not least haben wir hier die Möglichkeit zum Einrichten einer Point-to-Site-Verbindung gegen ein entsprechendes Gateway.

Azure: Basiswissen für Administratoren

Lernen Sie das Wichtigste, was Sie als IT-Adminstrator über die Möglichkeiten von Azure wissen müssen.

4 Std. 2 min (31 Videos)
Derzeit sind keine Feedbacks vorhanden...
Hersteller:
Software:
Exklusiv für Abo-Kunden
Erscheinungsdatum:07.09.2017

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!