Was ist ein virtuelles Azure-Netzwerk? Die meisten Leute hören diesen Begriff und denken, es sei nur eine weitere Einstellung, die man beim Bereitstellen einer virtuellen Maschine aktiviert. Etwas, das man kurz anklickt und dann vergisst. Doch hier ist die Wahrheit. Ein virtuelles Azure-Netzwerk ist nicht nur eine Einstellung. Es ist das Fundament für alles, was Sie in Azure aufbauen. Jede virtuelle Maschine, jede Datenbank, jeder App-Service und jede Funktion, die Sie bereitstellen, befinden sich darin. Und wenn Sie nicht verstehen, wie Sie funktionieren, arbeiten Sie blind. Am Ende dieser Folge werden Sie verstehen, was ein VNet eigentlich ist, wie es funktioniert und warum jede einzelne Ressource, die Sie bereitstellen, davon abhängt. Wir behandeln, was ein VNet ist, wie IP-Adressen funktionieren, Subnetze, Sicherheit, Routing und wie man VNet miteinander verbindet. Schnappen Sie sich Ihren Kaffee und legen wir los.

Was ist ein VNet? Das private Cloud-Netzwerk. Beginnen wir mit der einfachsten Definition. Ein virtuelles Azure-Netzwerk, kurz VNet, ist Ihr eigenes privates Netzwerk innerhalb von Azure. Stellen Sie es sich wie ein privates Bürogebäude vor. Nur Personen, denen Sie den Zutritt gestalten. Sie kontrollieren, wer durch die Tür kommt, wer an welche Etage gelangt und wer komplett ausgesperrt bleibt. Bevor es VNet gab, war alles anders. Man stellte eine virtuelle Maschine in der Cloud bereit und sie war standardmäßig praktisch dem Internet ausgesetzt. Kein privates Netzwerk drumherum. Jeder, die IP-Adresse kannte, konnte versuchen, eine Verbindung herzustellen. Das war ein Sicherheitsalbtraum. Was hat sich geändert? Azure gab Ihnen die Möglichkeit, isolierte private Netzwerkbereiche zu erstellen. Die definierende Grenze. Sie entscheiden, was hineinkommen. Nichts außerhalb dieser Grenze kann eindringen, es sei denn, Sie erlauben es ausdrücklich.

Eines vorab, Ihr VNet existiert in einer bestimmten Azure-Region. Es ist nicht global. Erstellen Sie ein VNet in Westeuropa, dann bleibt es auch dort. Ressourcen in einer anderen Region können nicht einfach hineinspringen. Sie bräuchten Ihr eigenes VNet oder Sie müssten sie später verbinden. Wenn Sie ein VNet erstellen, definieren Sie den IP-Adressraum selbst. Azure wählt die nicht für Sie aus. Sie entscheiden über den Bereich der IP-Adressen, die Ihre Ressourcen nutzen werden. Das ist eine große Verantwortung und wir werden im nächsten Abschnitt besprechen, wie man das richtig macht. Hier ist der entscheidende Punkt. VNet sind das Fundament. Jede virtuelle Maschine, jede Datenbank und jede Azure-Funktion, die Sie bereitstellen, befindet sich darin. Ohne ein VNet haben Ihre Ressourcen keinen privaten Netzwerkkontext. Sie schweben einfach in der Cloud, ohne Grenzen, ohne Isolation, ohne Sicherheit.

Was bedeutet das also für Sie? Wenn Sie in Azure etwas aufbauen, beginnen Sie zuerst mit einem VNet, nicht erst nach der Bereitstellung Ihrer Ressourcen, sondern davor. Ihr VNet ist das Land, auf dem Sie bauen. Sie würden kein Haus bauen, ohne vorher das Grundstück zu kaufen, oder? Dasselbe Prinzipiert hier. IP-Adressierung, CRDR, die Wahl Ihres Adressbereichs. Legen wir also los. Wenn Sie ein VNet erstellen, ist die erste wichtige Entscheidung die Wahl eines IP-Bereichs. Das tun Sie mithilfe der CRDR-Notation. CRDR steht für Classless Inter-Domain-Routing, aber im Grunde bedeutet es nur, ich benötige so und so viele IP-Adressen. Warum ist das wichtig? Weil der von Ihnen gewählte Bereich bestimmt, wie viele Ressourcen in Ihr virtuelles Netzwerk passen. So funktioniert es. CRDR verwendet einen Schrägstrich und eine Zahl wie 16 oder 24. Diese Zahl gibt Ihnen die Größe des Adressraums an. Ein 16R-Bereich bietet Ihnen etwa 65.000 IP-Adressen.

Das ist eine ganze Menge. Ein 24R-Bereich bietet etwa 250, was perfekt für ein kleines Team oder eine einzelne Anwendungsebene ist. Wenn Sie also Ihr Vornet planen, müssen Sie überlegen, wie viele Ressourcen Sie haben und wie Sie diese kopieren wollen. Nun, Sie können nicht einfach irgendeinen IP-Bereich wählen. Azure folgt dem RFC 1918-Standard, der private IP-Bereiche für interne Netzwerke reserviert. Sie haben drei Optionen. Der 10.x-Bereich ist der größte und bietet viel Raum für Wachstum. Der 172.16x-Bereich ist etwas kleiner, aber dennoch nützlich. Und der 192.16x-Bereich ist der, den Sie wahrscheinlich zu Hause an Ihrem Router haben. Ist der Punkt. Der Adressraum Ihres Vornets darf sich nicht mit anderen Netzwerken überschneiden, mit denen Sie eine Verbindung herstellen möchten. Dies ist ein häufiger Fehler. Viele Leute wählen einen Bereich, der Ihnen vertraut vorkommt, nur um später festzustellen, dass er mit Ihrem Firmennetzwerk in Konflikt steht.

Wenn also Ihr Büronetzwerk 10.0.0.16 verwendet, nutzen Sie denselben Bereich, nicht den Azure. Wenn Sie versuchen, sich später zu verbinden, gibt es Konflikte und der Datenverkehr weiß nicht, wohin er fließen soll. Lassen Sie mich in ein konkretes Beispiel. Stellen Sie sich vor, Sie bauen ein Hybrid-Setup auf, bei dem Azure mit Ihrem lokalen Rechenzentrum verbunden wird und Ihr Rechenzentrum 10.0.0.0.0.16 nutzt, dann 0.16 nutzt. Wenn Sie ein V-Net mit demselben Bereich erstellen, haben Sie zwei Netzwerke, die um dieselben IPs konkurrieren. Denken Sie darüber nach. Zwei Netzwerke, die denselben IP-Bereich verwenden, können nicht ordnungsgemäß kommunizieren. Es ist wie bei zwei Häusern mit derselben Adresse. Die Pus kommt durcheinander. Das ist ein Problem, das Sie nicht im Nachhinein lösen möchten. Planen Sie also voraus und wählen Sie einen eindeutigen Bereich. Und hier ein Planungstipp.

Wählen Sie einen größeren Bereich, als Sie zu benötigen. Sie denken vielleicht, Sie brauchen jetzt nur ein 24-N-Netz, aber wenn Ihre Anwendung wächst, werden Sie sich ein 16-Netz wünschen. Sie können es später nicht einfach ändern. Sobald Ihr V-Net erstellt ist und Sie Ressourcen bereitgestellt haben, ist das Ändern des Adressraums kompliziert. Es ist möglich, aber das möchten Sie nicht an einem laufenden System durchführen. Eben Sie sich also Raum zum Wachsen. Was bedeutet das für Sie? Betrachten Sie den Adressraum Ihres V-Netzes wie den Kauf von Lamm. Sorgen Sie für genügend Platz für zukünftiges Wachstum. Wenn Sie glauben, Sie brauchen ein kleines Grundstück, kaufen Sie ein mittleres. Sie werden sich später selbst erweitern. Das ist die wichtigste Erkenntnis. Planen Sie Ihren Adressraum mit Blick auf zukünftiges Wachstum. Subnetze die Unterteilung Ihres Netzwerks. Sie haben also Ihr V-Net und Ihren Adressraum ausgewählt.

Was nun? Sie werfen nicht einfach alles in einen großen Topf. Wir kommen Subnetze ins Spiel. Subnetze sind einer der grundlegenden Bausteine Ihres V-Netzes. Sie ermöglichen es Ihnen, Ressourcen zu organisieren und zu schützen. Ein Subnetz ist ein kleinerer Bereich des Adressraums Ihres V-Netzes. Wenn Ihr V-Net das Gebäude ist, sind Subnetze die einzelnen Räume. Sie würden Ihren Serverraum, Ihren Empfang und Ihren Pausenraum doch auch nicht alle in einen einzigen offenen Raum stellen, oder? Dasselbe gilt hier. Es ist ein einfaches Konzept, das aber einen großen Unterschied in der Netzwerkverwaltung macht. Verschiedene Ressourcen kommen in verschiedene Subnetze. Ihre Web-Server kommen in ein Subnetz, Ihre Datenbanken in ein anderes und Ihre Anwendungslogik in ein drittes. Warum? Zwei Gründe. Sicherheit und Organisation. Sprechen wir zuerst über Sicherheit, da diese meist am wichtigsten ist.

Sicherheit zuerst. Wenn jemand in Ihren Web-Server eindringt, möchten Sie nicht, dass er direkten Zugriff auf Ihre Datenbank hat. Getrennte Subnetze schaffen eine natürliche Barriere. Der Angreifer müsste diese Grenze überschreiten und Sie können genau kontrollieren, was hier passiert. Sie können auch Netzwerksicherheitsgruppen verwenden, um den Datenverkehr zwischen Subnetzen zu steuern. Das ist ein Thema für ein anderes Video, aber es ist gut zu wissen, dass Subnetze das Fundament für diese Sicherheit bilden. Organisation der Zweite. Wenn alles seinen Platz hat, ist die Verwaltung einfacher. Sie wissen, welches Subnetz Ihre Frontend-Ressourcen enthält und welches Ihre Backend-Daten. Sie können Richtlinien und Regeln auf das gesamte Subnetz gleichzeitig anwenden, anstatt jede Ressource einzeln zu konfigurieren. Das spart Zeit und reduziert Fehler. Nun ein Detail, das viele Leute überrascht.

Azure reserviert 5 IP-Adressen in jedem Subnetz für eigene interne Zwecke wie Routing und DNS. Wenn Sie also ein Subnetz mit einem 24R-Bereich erstellen, der Ihnen 256 Adressen gibt, erhalten Sie tatsächlich nur 2 Adressengebte Adress. Das ist eine häufige Falle. Du planst für 256, aber du erhältst nur 200. Also plane bei der Größe deiner Subnetze immer etwas Puffer ein. Die gute Nachricht ist, dass du nach dem Erstellen des Vornetzes weitere Subnetze hinzufügen kannst. Du bist nicht an die gebunden, die du bei der Erstellung festgelegt hast. Wenn du also merkst, dass du ein eigenes Subnetz für Management-Tools oder Überwachungssysteme brauchst, füge es später hinzu, brauchst du. Kein Problem. Aber es ist dennoch besser, sie im Voraus zu planen. Das nachträgliche Hinzufügen von Subnetzen ist möglich, kann aber das Verschieben von Ressourcen erfordern, was störend sein kann. Aber hier ist die bewährte Methode.

Nutze von Anfang an separate Subnetze für die verschiedenen Ebenen deiner Anwendung. Denk über deine Anwendungsarchitektur nach. Normalerweise hast du eine Frontend-Ebene für Benutzeranfragen, eine Backend-Ebene für Geschäftslogik und eine Datenebene für Information. Jeder davon sollte ein eigenes Subnetz haben. Warte nicht bis zur Produktion, um zu merken, dass du Dinge trennen musst. Das ist viel schwieriger, wenn die Ressourcen bereits bereitgestellt sind. Was bedeutet das für dich? Über Subnetze hältst du dein Netzwerk organisiert und sicher. Sie sind wie die Räume in deinem Gebäude. Plane sie früh und gib jeder Ebene deiner Anwendung in ihren eigenen Bereich. So hältst du dein Netzwerk sauber und sicher. Öffentliche versus Privat-IPs. Wer kann das sehen? Lass uns über IP-Adressen sprechen, denn nicht alle IP-Adressen sind gleich. Das ist die Adresse, über die sie mit anderen Ressourcen im V-Net kommuniziert.

Stell es dir wie eine interne Telefondurchwahl. Nur Leute innerhalb des Gebäudes können sie erreichen. Private-IPs sind nur aus dem V-Net oder verbundenen Netzwerken erreichbar. Wenn du zu Hause an deinem Laptop sitzt, erreichst du keine private IP in Azure. Sie ist nicht im Internet. Sie befindet sich in deinem privaten Netzwerk. Wie machst du eine Ressource also aus dem Internet erreichbar? Du gibst dir eine öffentliche IP-Adresse. Das ist die nach außen sichtbare Adresse, wie eine öffentliche Telefonnummer statt einer internen Durchwahl. Das ist der entscheidende Punkt. Öffentliche IPs sind optional. Du weißt sie explizit zu, da Azure deine Ressourcen nie eine öffentliche IP gibt, außer du fragst danach. Das ist Absicht. Der Standard sollte privat sein, öffentlich sollte eine bewusste Entscheidung sein. Und hier machen viele Anfänger einen Fehler. Sie geben allem öffentliche IP-Adressen.

Ihr Web-Server, ihre Datenbank, ihre Backend-API erhalten alle eine. Das ist ein Sicherheitsrisiko. Deine Datenbank muss nicht aus dem Internet erreichbar sein, genau wie deine Backend-API. Nur Frontend-Ressourcen, mit denen Benutzer tatsächlich interagieren, sollten öffentliche IP-Adressen haben. Nun, öffentliche IP-Adressen gibt es in zwei Varianten, statisch und dynamisch. Eine statische öffentliche IP bleibt gleich, auch wenn Sie die Ressource stoppen und neu starten. Eine dynamische öffentliche IP kann Sie ja. Wenn Sie eine Produktionsanwendung betreiben, benötigen Sie wahrscheinlich statische IPs, damit Ihre Benutzer sie immer finden. Wenn Sie etwas testen, reicht eine dynamische IP möglicherweise aus. Sie können auch ein sogenanntes öffentliches IP-Präfix verwenden, mit dem Sie einen Adressblock reservieren können. Anstatt sie einzeln zu erstellen, reservieren Sie einen Bereich und weisen daraus individuelle Adressen zu.

Nützlich, wenn Sie wissen, dass Sie mehrere öffentliche IPs für ein Projekt benötigen. Was bedeutet das für Sie? Private IP-Adressen sind die sichere Standardeinschuldung. Sie sind wie eine interne Telefonnummer. Öffentliche IPs sind eine bewusste Entscheidung, die Sie nur treffen, wenn etwas von außen erreichbar sein muss. Und wenn Sie diese benötigen, überlegen Sie, ob statisch oder dynamisch nötig ist und ob ein Präfix Sinn ergibt. Netzwerksicherheitsgruppen zur Steuerung des Datenverkehrs. Sie haben also Ihr VNet, Ihre Subnetze und Ihre IP-Adressen geklärt. Aber wie steuern Sie tatsächlich, welcher Datenverkehr ein- und ausgehen darf? Hier kommen Netzwerksicherheitsgruppen NSGs ins Spiel. Ein NSG ist der Türsteher, der kontrolliert, welcher Datenverkehr Ihre Ressourcen erreicht oder verlässt. Stellen Sie sich wie ein Türsteher in einem Club vor. Der Ausweise prüft, auf die Gästeliste schaut und jeden abweist, der nicht dort sein sollte, der nicht dort sein.

Jedes Datenpaket, das versucht, Ihre Ressource zu erreichen, muss zuerst an diesem Türsteher vorbei. NSGs funktionieren mit Regeln. Jede Regel besagt Zulassen oder Verweigern, basierend auf vier Faktoren. Quell-IP-Adresse, Ziel-IP-Adresse, Portnummer und Protokoll.

243 zulassen oder den gesamten Internetdatenverkehr auf Port 22 verweigern. Genau diese Art von Kontrolle. Nun ein leistungsstärkes Feature. Sie können eine NSG an ein Subnetz oder direkt an die Netzwerkschnittstelle einer einzelnen VM anbinden. Wenn Sie sie an ein Subnetz anbinden, gilt die NSG für alles darin. Jede VM, jede Datenbank, jede Ressource. Es ist eine pauschale Richtung. Wenn Sie sie an die Netzwerkschnittstelle einer bestimmten VM anbinden, gilt sie nur für diese eine Maschine. Sie können sogar beides tun. Eine NSG auf Subnetzebene für allgemeine Regeln und eine NSG-Ebene für Ausnahmen. Die Standardregeln, die Azure erstellt, sind ziemlich sinnvoll. Sie erlauben den gesamten Datenverkehr innerhalb des VNet, damit Ihre Ressourcen miteinander kommunizieren können und blockieren den gesamten Datenverkehr aus dem Internet, sodass niemand von außen auf Ihre Ressourcen zugreifen kann, sofern Sie dies nicht explizit erlauben.

Das ist ein guter Ausgangspunkt. Lassen Sie mich ein gängiges Beispiel nennen. Angenommen, Sie verwalten eine virtuelle Linux-Maschine und müssen sich per SSH darauf verbinden. Sie würden eine NSG-Regel erstellen, die eingehenden Datenverkehr auf Port 22 zulässt, aber Sie möchten SSH nicht für jeden freigeben. Das wäre riskant. Also beschränken Sie den Zugriff auf Ihre eigene IP-Adresse, damit nur Sie per SSH zugreifen können und alle anderen blockiert werden. Dasselbe gilt für RDP über Port 3.089 bei Windows-Maschinen. Was bedeutet das für Sie? NSGs sind Ihre erste Verteidigungslinie und das Beste daran, sie sind kostenlos. Es gibt keine zusätzlichen Kosten für die Nutzung, also gibt es keinen Grund, Sie die einzurichten. Jedes Subnetz und jede Ressource sollte mit einer NSG verknüpft sein. Beginnen Sie mit alles ablehnen und öffnen Sie nur das, was Sie wirklich benötigen. Routing-Tabellen und Routing, die Lenkung des Datenverkehrs.

Kommen wir nun zum Routing. Denn wenn Sie erst einmal festgelegt haben, welcher Datenverkehr erlaubt ist, müssen Sie entscheiden, wohin er tatsächlich fließen soll. Die Sache ist, die Azure erstellt automatisch Systemrouten für jedes Subnetz. Sie müssen sich um nichts kümmern. Stellen Sie es sich wie ein Standard-Navi vor, das die grundlegenden Straßen kennt. Datenverkehr innerhalb des V-Net, Datenverkehr zu verbundenen V-Net, Datenverkehr ins Internet. Alles funktioniert sofort, aber manchmal führt Sie das Standard-Navi nicht dorthin, wo Sie hinwollen. Dann benötigen Sie benutzerdefinierte Routen oder UDRs. Damit können Sie die Systemrouten

Wie funktioniert das? Sie erstellen eine Routing-Tabelle. Sie fügen Ihre benutzerdefinierten Routen. Dann ordnen Sie diese Routing-Tabelle einem Subnetz zu. Von diesem Moment an folgt der Datenverkehr, der das Subnetz verlässt, Ihren Regeln anstelle der Standard ein. Ich gebe Ihnen ein konkretes Beispiel. Angenommen, der gesamte Internet-Datenverkehr Ihres V-Netz soll zuerst durch eine Firewall geleitet werden. Vielleicht müssen Sie ihn überprüfen, protokollieren oder bösartige Seiten blockieren.

Das ist nicht das, was Sie wollen. Also erstellen Sie eine Route, die besagt, dass der gesamte Datenverkehr an 0.0.0, also ins Internet, stattdessen an die Firewall gesendet werden soll, also es ist eine benutzerdefinierte Route. Routing-Tabellen verwenden das Konzept des Next Hop. Das ist das Ziel, an das der Datenverkehr als nächstes gesendet wird. Sie haben dabei mehrere Optionen. Sie können ihn an ein virtuelles Gerät wie eine Firewall senden. Sie können ihn an ein virtuelles Netzwerk-Gateway senden, über das Sie Verbindungen zu lokalen Netzwerken herstellen. Sie können ihn direkt ins Internet leiten oder an None senden, was den Datenverkehr im Grunde verwirft. Das Wichtigste ist zu verstehen, dass Routing die Methode ist, mit der Sie den Pfad des Datenverkehrs durch Ihr Netzwerk steuern. Systemrouten sind eine gute Standardeinstellung, aber nicht immer für Ihre Situation geeignet. Wenn Datenverkehr einen Prüfpunkt oder ein bestimmtes Gateway passieren muss oder komplett blockiert werden soll, benötigen Sie benutzerdefinierte Routen.

Was bedeutet das für Sie? Routing bestimmt, wohin der Datenverkehr fließt und Sie haben jederzeit die Möglichkeit, die Standardeinstellungen von Azure zu überschreiben. Beginnen Sie mit den Systemrouten, verstehen Sie deren Funktion und fügen Sie benutzerdefinierte Routen hinzu, wenn Ihre Architektur dies erfordert. VNet-Peering-Netzwerke verbinden. Bisher haben wir über ein einzelnes VNet gesprochen. Ein Gebäude, ein privates Netzwerk. Aber was passiert, wenn Sie mehrere VNet haben? Vielleicht haben Sie eines für Ihre Produktionsumgebung und ein anderes zum Testen oder Sie betreiben Anwendungen in verschiedenen Azure-Regionen. Standardmäßig sind diese VNet vollständig isoliert. Sie können nicht miteinander kommunizieren. Sie sind wie getrennte Gebäude ohne Straßen dazwischen. Hier kommt das VNet-Peering ins Spiel. Es ermöglicht Ihnen, zwei VNets privat zu verbinden und zwar wirklich privat.

Der Datenverkehr zwischen gepaerten VNet bleibt im Microsoft-Backbone-Netzwerk. Er berührt niemals das öffentliche Internet. Das bedeutet geringe Latenz, hohe Bandbreite und keinen Schutz gegen Bedrohungen von außen. Hier ist etwas, das viele überrascht. Peering funktioniert auch über Regionen hinweg. Es nennt man globales Peering. Sie können ein VNet in Westeuropa mit einem VNet in Südostasien verbinden und der Datenverkehr dazwischen bleibt im privaten Netzwerk von Microsoft. Keine VPN-Gateways, keine öffentlichen IPs, einfach eine direkte private verbinden. Es gibt jedoch eine Regel, die Sie auf keinem Verbrechen dürfen. Gepaerte VNets müssen überlappungsfreie Adressbereiche haben. Wenn beide VNets versuchen, den Bereich 10.0.0.16 zu nutzen, können sie nicht gepaert werden, können sie nicht gepaert werden. Die IP-Adressen würden kollidieren und Azure wüsste nicht, zu welchem Netzwerk ein Paket gehört.

Erinnern Sie sich an den früheren Planungstipp, den Adressbereich sorgfältig zu wählen. Das ist der Grund. Wenn Sie glauben, dass Sie später wie Netzpaaren könnten, stellen Sie sicher, dass sich Ihre Bereiche von Anfang an nicht überschneiden. Hier ist ein Detail, dass viele stolpern lässt. Peering ist nicht transitiv. Was bedeutete das? Nehmen wir an, VNet A ist mit VNet B gepaert und VNet B mit VNet C. VNet A erreicht VNet C nicht automatisch über B. Sie sind nicht verbunden. Jedes Peering ist eine direkte Verbindung zwischen genau zwei VNets. Wenn A mit C kommunizieren soll, benötigen Sie ein separates Peering zwischen A und C. Wie geht man also damit in großem Maßstab um? Sie verwenden eine Hub-and-Spoke-Architektur. Ein zentrales VNet, der Hub ist mit vielen anderen VNets den Spokes verbunden. Der Hub kann gemeinsame Dienste wie eine Firewall, ein VPN-Gateway oder Überwachungstools enthalten.

In den Spokes befinden sich individuellen Workloads. Jeder Spoke ist direkt mit dem Hub verbunden, aber die Spokes sind nicht untereinander verbunden. Wenn ein Spoker einen anderen Spoker erreichen muss, läuft der Datenverkehr über den Hub. Das sorgt für Ordnung und bietet einen zentralen Ort für Sicherheitsrichtlinien. Was bedeutet das für Sie? Peering ist die Art, Netzwerke zu erstellen, die mehrere VNets und Regionen umspannen. Es ist die Brücke zwischen Ihren Gebäuden. Planen Sie Ihre Adressbereiche so, dass Sie sich nicht überschneiden. Denken Sie daran, dass Peering nicht transitiv ist und erwägen Sie ein Hub-Spoke-Design, wenn Sie über ein einzelnes VNet hinaus wachsen. Wie alles zusammenhängt das große Ganze. Treten wir also einen Schritt zurück und schauen, wie die Teile zusammenpassen. Genau da liegt die wahre Stärke. Sie beginnen mit einem VNet. Das ist Ihr privater Bereich in Azure.

Stellen Sie sich Ihr Grundstück vor. Auf diesem Grundstück erstellen Sie Subnetze. Das sind Ihre Räume. Einer für Web-Server, einer für Datenbanken, einer für Verwaltungstools. Jedes Subnetz erhält einen eigenen Adressblock aus dem Adressraum des VNets. Dann fügen Sie Sicherheit hinzu. Netzwerksicherheitsgruppen werden an Ihre Subnetze angehängt. Sie steuern, welcher Datenverkehr ein- und ausgehen darf. Ihr Web-Subnetz lässt Datenverkehr aus dem Internet auf Port 4.3 zu. Ihr Datenbank-Subnetz lässt nur Datenverkehr vom Web-Subnetz auf Port 4.3 zu. Der Türsteher an jeder Tür weiß genau, wer hinein darf. Als nächstes Routing ein. Vielleicht soll der gesamte ausgehende Internetverkehr zur Prüfung über eine Firewall laufen. Sie erstellen eine Routing-Tabelle, fügen eine benutzerdefinierte Route hinzu und verknüpfen sie mit Ihren Subnetze. Jetzt folgt der Datenverkehr dem von Ihnen entworfenen Pfad statt dem Standard von Azure.

Und schließlich verbinden Sie alles miteinander. Sie verbinden Ihr VNet mit anderen VNets, vielleicht einem Hub-File und Dienste, RL. Jetzt umspannt Ihre Anwendung mehrere Netzwerke, funktioniert aber als ein System. Hier kommt der Aha-Moment. Keines dieser Elemente funktioniert isoliert. Ein VNet ohne Subnetze ist nur leerer. Subnetze ohne NSGs sind weit offen. Routing ohne klares Design leitet Daten an die falschen Orte. Peering ohne Planung erzeugt Adresskonflikte. Sie bilden ein System. Jedes Teil hängt von den anderen. Ich gebe Ihnen ein konkretes Beispiel. Stellen Sie sich eine Web-Anwendung vor. Ihre Web-Server stehen in einem öffentlichen Subnetz mit einer NSG, die HTTPS-Verkehr aus dem Internet erlaubt. Ihre Anwendungs-Server stehen in einem privaten Subnetz, das nur Datenverkehr vom Web-Subnetz akzeptiert. Ihre Datenbank befindet sich in einem privaten Subnetz, das nur Datenverkehr vom App-Subnetz akzeptiert.

Eine Routing-Tabelle leitet den gesamten ausgehenden Datenverkehr zur Protokollierung und Prüfung durch eine Firewall im Hub-Einheit. Und das Ganze ist mit Ihrem Unternehmensnetzwerk verbunden, sodass Ihr internes Teams verwalten kann. Das ist der wahre Mehrwert, nicht ein einzelnes Feature. Es ist das Zusammenspiel aller Komponenten. Vor 20 Jahren kauften Sie einzelne Server, konfigurierten physische Router und verwalteten Firewalls pro Gerät, V-Gerät. Alles war manuell, langsam und teuer. Azure bietet Ihnen das alles als Dienstleistung an. Sie definieren es mit wenigen Klicks oder einem Skript und es funktioniert einfach. Was bedeutet das für Sie? Sobald Sie verstehen, wie diese Teile zusammenpassen, wird Azure Networking vorhersehbar. Sie müssen nicht raten, Sie planen. Und wenn etwas ausfällt, wissen Sie genau, wo Sie suchen müssen, weil Sie das System verstehen. Hier ist das, was Sie aus dieser Folge mitnehmen sollten.

Erstens der wichtigste Schritt, den Sie machen können. Erstellen Sie ein V-Net mit einem gut geplanten Adressraum, bevor Sie irgendetwas bereitstellen. Diese eine Entscheidung wirkt sich auf alles Weitere aus. Zweitens nutzen Sie Subnetze, um Ihre Anwendungsebenen zu trennen. Webserver, App-Server, Datenbanken geben Sie jedem seinen eigenen Raum. Und drittens beginnen Sie mit NSGs. Sie sind kostenlos. Sie sind leistungsstark und verbessern Ihre Sicherheit vom ersten Tag an drastisch. Ihr V-Net ist das Fundament für alles, was Sie in Azure aufbauen. Machen Sie es richtig und alles andere wird einfacher. Machen Sie es falsch und Sie verbringen Ihre ganze Zeit damit, gegen Ihr Netzwerk zu kämpfen. Abonnieren Sie uns auf Ihrer Lieblings-Podcast-Plattform und teilen Sie dies mit jemandem, der seine Azure-Reise beginnt. Hinterlassen Sie einen Kommentar, falls es bei Ihnen klicken mag. Wir sehen uns in der nächsten Folge.