Czym jest sieć wirtualna Azure? Większość ludzi słysząc ten termin myśli, że to tylko kolejne ustawienie, które włącza się przy wdrażaniu maszyny wirtualnej, coś, co się zaznacza i o czym się zapomina. Ale prawda jest inna. Sieć wirtualna Azure to nie tylko ustawienie, to fundament wszystkiego, co budujesz w Azure. Każda maszyna wirtualna, każda baza danych, każdy serwis aplikacji, każda funkcja, którą wdrażasz, wszystko to znajduje się wewnątrz sieci. Jeśli nie rozumiesz, jak działają, działasz po omacku. Pod koniec tego odcinka zrozumiesz, czym naprawdę jest sieć wnet, jak działa i dlaczego każdy wdrażany zasób jest od niej zależny. Omówimy, czym jest wnet, jak działają adresy IP, podsieci, bezpieczeństwo, routing i jak łączyć sieci wnet ze sobą. Chwyć kawę i zaczynajmy. Czym jest wnet? Prywatna sieć w chmurze. Zacznijmy od najprostszej definicji. Sieć wirtualna Azure, w skrócie wnet, to twoja własna prywatna sieć wewnątrz Azure.

Pomyśl o niej jak o prywatnym budynku biurowym. Tylko osoby, na które pozwolisz, mogą wejść do środka. Kontrolujesz, kto przechodzi przez drzwi, kto wchodzi na jakie piętro i kto jest całkowicie zablokowany. Zanim powstały sieci wnet, było inaczej. Wdrażałeś maszynę wirtualną w chmurze i była ona domyślnie wystawiona na internet. Brak prywatnej sieci wokół niej. Każdy, kto znał adres IP, mógł próbować się połączyć. To był koszmar z punktu widzenia bezpieczeństwa. Co się zmieniło? Azure dał możliwość tworzenia odizolowanych prywatnych przestrzeni sieciowych. Definiujesz granicę. Decydujesz, co znajduje się w środku. Nic spoza tej granicy nie może wejść do środka, chyba że wyraźnie na to pozwolisz. Jedna rzecz, o której warto wiedzieć na wstępie, twoja sieć wnet znajduje się w konkretnym regionie Azure. Nie jest globalna. Stwórz wnet w regionie West Europę i tam właśnie pozostanie. Zasoby z innego regionu nie mogą tak po prostu do niej wskoczyć.

Potrzebowałyby własnej sieci wnet lub musiałbyś je później połączyć. Kiedy tworzysz wnet, sam definiujesz przestrzeń adresową IP. Azure nie dobiera jej za ciebie. Ty decydujesz o zakresie adresów IP, w których będą używać twoje zasoby. To duża odpowiedzialność, o której powiemy, jak ją dobrze udźwignąć w następnej sekcji. Oto kluczowy punkt. Sieci wnet to fundament. Każda maszyna wirtualna, każda baza danych, każda funkcja Azure, którą wdrażasz, znajduje się wewnątrz takiej sieci. Bez sieci wnet twoje zasoby nie mają kontekstu sieci prywatnej. Są po prostu zawieszone w chmurze, bez granic, bez izolacji, bez bezpieczeństwa. Co to oznacza dla ciebie? Jeśli budujesz cokolwiek w Azure, zacznij od sieci wnet nie po wdrożeniu zasobów, ale przed. Twoja sieć wnet to grunt, na którym budujesz. Nie budowałbyś domu bez kupna działki, prawda? Zupełnie jak tu. Adresowanie IP i C i DR, czyli wybór przestrzeni adresowej.

Zaczynajmy. Kiedy tworzysz wnet, pierwszą ważną decyzją jest wybór zakresu IP. Robisz to za pomocą notacji C i DR. C i DR to skrót od Classless Interdomain Routing, co oznacza po prostu, potrzebuje tylu a tylu adresów IP. Dlaczego to ważne? Ponieważ wybrany zakres określa, ile zasobów zmieścisz w swojej sieci wirtualnej. Oto jak to działa. C i DR używa ukośnika i liczby, na przykład 16 lub 24. Ta liczba określa rozmiar przestrzeni adresowej. Wartość 16 daje około 65 tysięcy adresów IP. To całkiem sporo. Wartość 24 daje około 250, co idealnie nadaje się dla małego zespołu lub jednej warstwy aplikacji. Projektując sieć wnet, musisz więc przemyśleć, ile będziesz mieć zasobów i jak chcesz je pogrupować. Nie możesz jednak wybrać dowolnego zakresu IP. Azure przestrzega standardu RFC 1918, który rezerwuje prywatne zakresy IP dla sieci wewnętrznych. Masz trzy opcje. Zakres 10XXX jest największy i daje mnóstwo miejsca na rozwój.

Zakres 172-16XX jest nieco mniejszy, ale również użyteczny. A zakres 192-168XX to ten, który pewnie masz w domu na swoim routerze. Ważna uwaga! Przestrzeń adresowa sieci wnet nie może pokrywać się z żadną inną siecią, z którą planujesz połączenie. To częsty błąd. Wiele osób wybiera zakres, który wydaje się znajomy, a później okazuje się, że koliduje z siecią firmową. Jeśli więc sieć biurowa Twojej firmy używa 10.0.0.0.0 ukośnik 1.6, nie używaj tego samego zakresu w Azure. Jeśli spróbujesz je później połączyć, wystąpi konflikt i ruch nie będzie wiedział, dokąd trafić. Podam Ci konkretny przykład. Wyobraź sobie, że budujesz hybrydę, w której Azure łączy się z lokalnym centrum danych, a Twoje centrum używa 10.0.0.0 ukośnik 1.6. Jeśli utworzysz sieć wnet z tym samym zakresem, będziesz mieć dwie sieci walczące o te same adresy IP. Pomyśl o tym. Dwie sieci używające tego samego zakresu IP nie mogą się poprawnie komunikować.

To tak, jakby dwa domy miały ten sam adres. Listonosz nie będzie wiedział, gdzie dostarczyć pocztę. To problem, którego nie chcesz rozwiązywać po fakcie. Zaplanuj więc wszystko z wyprzedzeniem i wybierz unikalny zakres. I jeszcze jedna wskazówka. Wybierz większy zakres niż wydaje Ci się, że będziesz potrzebować. Możesz myśleć, że teraz wystarczy Ci maska 24, ale w miarę rozwoju aplikacji pożałujesz, że nie masz 16. Później nie zmienisz tego łatwo. Gdy sieć wnet jest utworzona i wdrożono zasoby, zmiana przestrzeni adresowej jest kłopotliwa. Jest to możliwe, ale nie jest to coś, co chcesz robić na działającym systemie. Daj sobie więc przestrzeń na rozwój. Co to dla Ciebie oznacza? Pomyśl o przestrzeni adresowej swojej sieci wnet jak okupnie ziemi. Zapewnij sobie wystarczająco dużo miejsca na przyszły wzrost. Jeśli uważasz, że potrzebujesz małej działki, kup średnią. Podziękujesz sobie później.

To najważniejszy wniosek. Planuj przestrzeń adresową z myślą o przyszłym rozwoju. Podsieci, czyli podział sieci. Masz już sieć wnet i wybrałeś swoją przestrzeń adresową. Co teraz? Nie wrzucasz wszystkiego do jednego wielkiego zbioru.

Nie pozwalają one organizować i zabezpieczać zasoby. Podsieć to mniejsza sekcja przestrzeni adresowej Twojej sieci wnet. Jeśli wnet to budynek, podsieci są poszczególnymi pomieszczeniami. Nie umieściłbyś serwerownik recepcji i pokoju socjalnego w jednej otwartej przestrzeni, prawda? Tutaj zasada jest taka sama. To prosta koncepcja, ale robi ogromną różnicę w zarządzaniu siecią. Różne zasoby trafiają do różnych podsieci. Serwery www w jednej podsieci, bazy danych w innej, a logika aplikacji w trzeciej. Dlaczego? Z dwóch powodów. Bezpieczeństwo i organizacja. Porozmawiajmy najpierw o bezpieczeństwie, bo jest ono zazwyczaj najważniejsze. Najpierw bezpieczeństwo. Jeśli ktoś włamie się na Twój serwer www, nie chcesz, aby miał bezpośredni dostęp do bazy danych. Oddzielne podsieci tworzą naturalną barierę. Atakujący musiałby przekroczyć tę granicę, a Ty możesz dokładnie kontrolować, co przez nią przechodzi.

Możesz także użyć sieciowych grup zabezpieczeń do kontrolowania ruchu między podsieciami. To temat na inny film, ale warto wiedzieć, że podsieci są fundamentem tego bezpieczeństwa. Na drugim miejscu organizacja. Kiedy wszystko ma swoje miejsce, zarządzanie jest łatwiejsze. Wiesz, która podsieć zawiera zasoby front-end, a która przechowuje dane back-end. Możesz stosować zasady i reguły do całej podsieci naraz, zamiast konfigurować każdy zasób z osobna. Oszczędza to czas i redukuje liczbę błędów. Oto szczegół, który często zaskakuje użytkowników. Azure rezerwuje 5 adresów IP w każdej podsieci na własne potrzeby wewnętrzne, takie jak routing i DNS. Więc jeśli utworzysz podsieć z zakresem 24, dającą 256 adresów, w rzeczywistości otrzymasz tylko 251 użytecznych. To częsta pułapka. Planujesz 256, a otrzymujesz tylko 251. Dlatego przy określaniu rozmiaru podsieci zawsze dodaj trochę zapasu. Dobrą wiadomością jest to, że podsieci można dodać po utworzeniu sieci w net.

Nie jesteś ograniczony do tych, które skonfigurowałeś podczas tworzenia. Jeśli więc uznasz, że potrzebujesz oddzielnej podsieci dla narzędzi do zarządzania lub monitoringu, dodasz ją później. Żaden problem. Mimo to lepiej zaplanować je od samego początku. Dodawanie podsieci później jest możliwe, ale może wymagać przenoszenia zasobów, co bywa uciążliwe. Oto jednak najlepsza praktyka. Od początku używaj oddzielnych podsieci dla różnych warstw aplikacji. Pomyśl o architekturze swojej aplikacji. Zazwyczaj masz warstwę front-endu obsługującą żądania, warstwę back-endu z logiką biznesową i warstwę danych. Każda z nich powinna mieć własną podsieć. Nie czekaj z podziałem zasobów na moment, gdy aplikacja będzie już na produkcji. Wtedy jest to znacznie trudniejsze, gdy zasoby są już wdrożone. Co to dla Ciebie oznacza? Podsieci pomagają utrzymać sieć w porządku i zapewniają bezpieczeństwo. Są niczym pokoje w budynku.

Zaplanuj je wcześniej i daj każdej warstwie aplikacji własną przestrzeń. W ten sposób utrzymasz sieć przejrzystą i bezpieczną. Publiczne kontra prywatne adresy IP. Kto co widzi? Porozmawiajmy o adresach IP, ponieważ nie każdy z nich jest taki sam. Gdy wdrażasz zasób wewnątrz sieci w net, domyślnie otrzymuje on prywatny adres IP. To adres, którego używa do komunikacji z innymi zasobami wewnątrz w net. Potraktuj to jak wewnętrzny numer telefonu. Tylko osoby wewnątrz budynku mogą się z nim połączyć. Prywatne adresy IP są dostępne tylko z wnętrza sieci w net lub z sieci z nią połączonych. Siedząc w domu przy laptopie nie połączysz się z prywatnym adresem IP w Azure. Nie ma go w internecie. Znajduje się wewnątrz twojej sieci prywatnej. Jak więc sprawić, by zasób był dostępny z internetu? Nadajesz mu publiczny adres IP. To adres widoczny dla świata zewnętrznego jak opublikowany numer telefonu zamiast wewnętrznego numeru.

Oto kluczowa kwestia. Publiczne adresy IP są opcjonalne. Przypisujesz je jawnie, ponieważ Azure nigdy nie nada za sobą publicznego IP, jeśli o to nie poprosisz. Tak zostało to zaprojektowane. Domyślnie powinien być adres prywatny, a publiczny powinien być świadomym wyborem. I w tym miejscu wielu początkujących popełnia błąd. Przypisują publiczne adresy IP do wszystkiego. Serwer www, baza danych, backendowe API, wszystko dostaje własny adres. To ryzyko dla bezpieczeństwa. Twoja baza danych nie musi być dostępna z internetu, podobnie jak twoje backendowe API. Tylko zasoby frontendowe, z którymi faktycznie wchodzą w interakcje użytkownicy, powinny mieć publiczne adresy IP. Publiczne adresy IP występują w dwóch rodzajach, statyczne i dynamiczne. Statyczny publiczny adres IP pozostaje taki sam, nawet po zatrzymaniu i ponownym uruchomieniu zasobu. Dynamiczny publiczny adres IP może ulec zmianie.

Jeśli uruchamiasz aplikację produkcyjną, prawdopodobnie potrzebujesz statycznych adresów IP, aby użytkownicy zawsze mogli cię znaleźć. Jeśli coś testujesz, adres dynamiczny może być w zupełności wystarczający. Możesz również skorzystać z tak zwanej prefiksu publicznego adresu IP, który pozwala zarezerwować blok adresów. Zamiast tworzyć je pojedynczo, rezerwujesz zakres, a następnie przypisujesz poszczególne adresy z tego zakresu. Przydatne, jeśli wiesz, że do projektu będziesz potrzebować wielu publicznych adresów IP. Co to oznacza dla ciebie? Prywatne adresy IP to bezpieczne ustawienie domyślne. Są one jak wewnętrzny numer telefonu. Publiczne adresy IP to świadomy wybór, którego dokonujesz tylko wtedy, gdy potrzebujesz, aby coś było dostępne z zewnątrz. A gdy już ich potrzebujesz, zastanów się, czy wymagany jest adres statyczny czy dynamiczny oraz czy prefiks ma sens. Sieciowe grupy zabezpieczeń kontrolujące ruch.

Masz już skonfigurowaną sieć wnet, podsieci i adresy IP. Jak jednak faktycznie kontrolować ruch przychodzący i wychodzący? W tym miejscu pojawiają się sieciowe grupy zabezpieczeń NSG. NSG to strażnik, który kontroluje ruch wchodzący do twoich zasobów i z nich wychodzący. Pomyśl o nim jak o ochroniarzu w klubie, który sprawdza dowody, weryfikuje listę gości i odsyła każdego, kto nie powinien wejść. Każdy pakiet ruchu próbujący dotrzeć do twojego zasobu musi najpierw przejść przez tego ochroniarza. Grupy NSG działają w oparciu o reguły. Każda reguła zezwala lub zabrania ruchu w oparciu o cztery elementy, źródłowy adres IP, docelowy adres IP, numer portu i protokół. Możesz więc zezwolić na ruch z mojego biurowego adresu IP na porcie 443 lub zablokować cały ruch z internetu na porcie 22. Tego typu kontrola, a oto potężna funkcja. Możesz dołączyć grupę NSG do podsieci lub bezpośrednio do interfejsu sieciowego pojedynczej maszyny wirtualnej.

Jeśli dołączysz ją do podsieci, NSG będzie obowiązywać dla wszystkiego, co się w niej znajduje. Każdej maszyny wirtualnej, każdej bazy danych, każdego zasobu. To ogólna polityka bezpieczeństwa. Jeśli dołączysz ją do interfejsu sieciowego konkretnej maszyny wirtualnej, będzie ona dotyczyć tylko tego jednego urządzenia. Możesz nawet zrobić obie te rzeczy. NSG na poziomie podsieci dla szerokich reguł i NSG na poziomie karty sieciowej nic dla wyjątków. Domyślne reguły tworzone przez Azure są całkiem rozsądne. Pozwalają one na cały ruch wewnątrz sieci wnet, więc twoje zasoby mogą się ze sobą komunikować, a jednocześnie blokują cały ruch z internetu, więc nikt z zewnątrz nie dotrze do twoich zasobów, chyba że wyraźnie na to pozwolisz. To dobry punkt wyjścia. Podam ci częsty przykład. Załóżmy, że zarządzasz maszyną wirtualną z systemem Linux i musisz się do niej połączyć przez SSH. Utworzysz regułę NSG, która zezwala na ruch przychodzący na porcie 22, ale nie chcesz zezwalać na SSH zewsząd.

To proszenie się o kłopoty, więc ograniczasz to do własnego adresu IP, dzięki czemu tylko ty możesz się połączyć przez SSH, a wszyscy inni są blokowani. Podobnie jest z RDP na porcie 3389 dla maszyn z systemem Windows. Co to oznacza dla ciebie? Sieciowe grupy zabezpieczeń NSG to twoja pierwsza linia obrony, a co najlepsze są darmowe. Nie ma dodatkowych kosztów ich używania, więc nie ma wymówki, by ich nie skonfigurować. Każda podsieć i każdy zasób powinny mieć przypisaną grupę NSG.

Teraz porozmawiajmy o routingu, bo kiedy już zdecydujesz, jaki ruch jest dozwolony, musisz ustalić, dokąd faktycznie trafia. Chodzi o to, że Azure automatycznie tworzy trasy systemowe dla każdej podsieci. Nie musisz nic robić. Pomyśl o tym jak o domyślnym GPS IE, który zna podstawowe drogi. Ruch wewnątrz sieci w net, ruch do połączonych sieci w net, ruch do internetu. Wszystko po prostu działa od razu po uruchomieniu, ale czasami domyślny GPS nie prowadzi cię tam, gdzie chcesz dotrzeć. Wtedy potrzebujesz tras zdefiniowanych przez użytkownika, czyli UDR. Pozwalają one zastąpić trasy systemowe Azure i przejąć kontrolę nad ścieżką ruchu. Jak to działa? Tworzysz tabelę tras. Dodajesz swoje niestandardowe trasy. Następnie kojarzysz te tabelę tras z podsiecią. Od tego momentu ruch opuszczający tę podsieć podąża według twoich reguł, a nie domyślnych. Podam ci konkretny przykład. Powiedzmy, że chcesz, aby cały ruch internetowy z twojej sieci w net przechodził najpierw przez zapory sieciową.

Może musisz go sprawdzić, zarejestrować lub zablokować złośliwe witryny. Domyślna trasa systemowa wysyła ruch internetowy bezpośrednio na zewnątrz. To nie jest to, czego chcesz, więc tworzysz trasę, która mówi, że każdy ruch skierowany do 0.0.0.0, czyli dowolnego miejsca w internecie, powinien zamiast tego trafić do zapory. To właśnie jest trasa zdefiniowana przez użytkownika. Tabelę tras wykorzystują tak zwany. Następny przeskok, Next Hop, to miejsce docelowe, do którego ruch jest wysyłany w następnej kolejności. Masz kilka opcji. Możesz wysłać go do wirtualnego urządzenia, takiego jak zapora ogniowa. Możesz wysłać go do bramy sieci wirtualnej, dzięki której łączysz się z sieciami lokalnymi. Możesz wysłać go bezpośrednio do internetu albo donikąd, co w praktyce oznacza odrzucenie ruchu. Kluczem jest zrozumienie, że routing pozwala kontrolować ścieżkę, jaką ruch pokonuje w sieci. Trasy systemowe są dobrym ustawieniem domyślnym, ale nie zawsze sprawdzają się w każdej sytuacji.

Jeśli chcesz, aby ruch przechodził przez punkt kontrolny konkretną bramę lub był całkowicie blokowany, potrzebujesz tras zdefiniowanych przez użytkownika. Co to dla Ciebie oznacza? Routing określa, dokąd ma trafiać ruch, a Ty masz możliwość nadpisania ustawień domyślnych azjur, gdy tylko zajdzie taka potrzeba. Zacznij od tras systemowych, zrozum ich działanie, a następnie dodawaj trasy niestandardowe, gdy wymaga tego architektura. Komunikacja między sieciami wirtualnymi w Netpeering. Do tej pory rozmawialiśmy o pojedynczej sieci w Net, jednym budynku, jednej prywatnej sieci. Co się jednak dzieje, gdy masz wiele sieci w Net? Może masz jedną sieć dla środowiska produkcyjnego, a inną do testów, albo uruchamiasz aplikacje w różnych regionach azjur. Domyślnie te sieci w Net są całkowicie odizolowane. Nie mogą się ze sobą komunikować. Są jak osobne budynki, między którymi nie ma żadnych dróg. W tym miejscu przydaje się w Netpeering.

Pozwala on na prywatne połączenie dwóch sieci w Net i mam tu na myśli naprawdę prywatne połączenie. Ruch między połączonymi sieciami w Net pozostaje wewnątrz szkieletowej sieci Microsoft. Nigdy nie trafia do publicznego internetu. Oznacza to niskie opóźnienia, wysoką przepustowość i brak narażenia na zagrożenia z zewnątrz. Oto coś, co zaskakuje wielu ludzi. Peering działa również między regionami. Nazywamy to Peeringiem Globalnym. Możesz mieć sieć w Net w Europie Zachodniej połączoną z siecią w Net w Azji Południowo-Wschodniej, a ruch między nimi pozostaje w prywatnej sieci Microsoftu. Bez bramek VPN, bez publicznych adresów IP, tylko bezpośrednie prywatne połączenie. Jest jednak zasada, której absolutnie nie wolno łamać. Połączone sieci w Net muszą mieć niepokrywające się przestrzenie adresowe. Jeśli obie sieci w Net próbują użyć zakresu 1.0.0.0.0 ukośnik 1.6, nie można ich połączyć. Adresy IP by się pokrywały, a Azure nie wiedziałby, do której sieci należy pakiet.

Pamiętasz wcześniejszą wskazówkę dotyczącą starannego planowania przestrzeni adresowej? Oto dlaczego jest to ważne. Jeśli przewidujesz, że w przyszłości połączysz sieci w Net, upewnij się od początku, że ich zakresy się nie pokrywają. A oto szczegół, który często sprawia kłopoty. Peering nie jest przechodni. Co to oznacza? Załóżmy, że sieć VNET-A jest połączona z siecią VNET-B, a VNET-B z siecią VNET-C. VNET-A nie łączy się automatycznie z VNET-C poprzez B. Nie są ze sobą połączone. Każdy peering to bezpośrednie połączenie między dokładnie dwiema sieciami VNET. Jeśli chcesz, aby akomunikowało się z C, musisz ustanowić oddzielne połączenie między A i C, jak więc zarządzać tym na dużą skalę. Stosuje się architekturę typu Hub & Spoke. Jedna centralna sieć VNET, zwana Hubem, jest połączona z wieloma innymi sieciami VNET, zwanymi Spoke. Hub może zawierać usługi współdzielone, takie jak zapora sieciowa, brama VPN czy narzędzia monitorujące.

Sieci Spoke zawierają Twoje poszczególne obciążenia. Każda sieć Spoke łączy się bezpośrednio z Hubem, ale sieci Spoke nie łączą się ze sobą. Jeśli sieć Spoke musi połączyć się z inną siecią Spoke, ruch przechodzi przez Hub. Hub utrzymuje to porządek i zapewnia centralne miejsce do stosowania zasad bezpieczeństwa. Co to dla Ciebie oznacza? Peering to sposób budowania sieci obejmujących wiele sieci VNET i regionów. To most pomiędzy Twoimi budynkami. Zaplanuj przestrzenie adresowe tak, aby się nie nakładały. Pamiętaj, że Peering nie jest przechodni i rozważ architekturę typu Hub & Spoke, gdy zaczniesz wykraczać poza jedną sieć VNET. Jak to wszystko się łączy szersza perspektywa. Cofnijmy się więc i zobaczmy, jak te elementy faktycznie do siebie pasują. W tym tkwi prawdziwa siła. Zaczynasz od sieci VNET. To Twoja prywatna przestrzeń w Azjur. Pomyśl o tym, jak o swoim terenie. Wewnątrz tego terenu tworzysz podsieci.

To Twoje pomieszczenia. Jedno dla serwerów www, jedno dla baz danych, jedno dla narzędzi zarządzania. Każda podsieć otrzymuje własny blok adresów wydzielony z przestrzeni adresowej sieci VNET. Następnie dodajesz zabezpieczenia. Sieciowe grupy zabezpieczeń są przypisywane do Twoich podsieci. Kontrolują one, jaki ruch jest dozwolony w obie strony. Twoja podsieć www zezwala na ruch z internetu na porcie 443. Twoja podsieć bazy danych zezwala tylko na ruch z podsieci www na porcie 1433. Ochroniasz przy każdych drzwiach, wie dokładnie, kto ma uprawnienia. Następnie konfigurujesz routing. Może chcesz, aby cały wychodzący ruch internetowy przechodził przez zaporę sieciową w celu inspekcji. Tworzysz tabelę tras, dodajesz trasę niestandardową i łączysz ją ze swoimi podsieciami. Teraz ruch podąża zaprojektowaną przez Ciebie ścieżką, a niedomyślną trasą Azjur. I na koniec łączysz wszystko w całość.

Łączysz swoją sieć VNET z innymi sieciami VNET, być może z siecią Hub, która zawiera zaporę i usługi współdzielone.

To jeden połączony system. Oto moment olśnienia. Żaden z tych elementów nie działa w izolacji. Sieć VNET bez podsieci to tylko pusta przestrzeń. Podsieci bez grup NSG są całkowicie otwarte. Routing bez przejrzystego projektu wysyła ruch w niewłaściwe miejsce. Peering bez planowania powoduje konflikty adresów. Stanowią one system. Każdy element zależy od pozostałych. Podam Ci konkretny przykład. Wyobraź sobie aplikację internetową. Twoje serwery www znajdują się w publicznej podsieci z grupą NSG zezwalającą na ruch HTTPS z internetu. Twoje serwery aplikacji znajdują się w prywatnej podsieci, która akceptuje ruch tylko z podsieci www. Twoja baza danych znajduje się w innej prywatnej podsieci, która akceptuje ruch tylko z podsieci aplikacji. Tablica TRAS wymusza kierowanie całego ruchu wychodzącego przez zaporę w sieci w net typu hub w celu rejestrowania i inspekcji. Całość jest połączona z Twoją siecią firmową, dzięki czemu zespół wewnętrzny może nią zarządzać.

Na tym polega prawdziwa wartość, a nie na pojedynczej funkcji. Chodzi o to, jak wszystkie te elementy współpracują ze sobą. 20 lat temu kupowałbyś osobne serwery, konfigurował fizyczne routery i zarządzał zaporami dla każdego urządzenia. Wszystko było ręczne, powolne i kosztowne. Azure zapewnia to wszystko jako usługę. Definiujesz to kilkoma kliknięciami lub skryptem i po prostu działa. Co to dla Ciebie oznacza? Gdy zrozumiesz, jak te elementy do siebie pasują, sieć w Azure stanie się przewidywalna. Nie musisz zgadywać, po prostu projektujesz, a gdy coś przestaje działać, wiesz dokładnie, gdzie szukać, bo rozumiesz system. Oto co chcę, żebyś zapamiętał z tego odcinka. Po pierwsze, najważniejszy krok, jaki możesz podjąć. Stwórz sieć w net z dobrze zaplanowaną przestrzenią adresową, zanim cokolwiek wdrożysz. Ta jedna decyzja wpływa na wszystko, co nastąpi później. Po drugie, używaj podsieci do oddzielenia warstw aplikacji.

Serwery www, serwery aplikacji, bazy danych daj każdemu własną przestrzeń. I po trzecie, zacznij od sieciowych grup zabezpieczeń NSG. Są darmowe, są potężne i znacząco poprawiają bezpieczeństwo od pierwszego dnia. Twoja sieć w net to fundament wszystkiego, co budujesz w Azure. Jeśli zrobisz to dobrze, reszta stanie się prostsza. Jeśli źle, będziesz spędzać cały czas na walce z własną siecią. Zasubskrybuj na swojej ulubionej platformie podcastowej i udostępnij to komuś, kto zaczyna przygodę z Azure. Zostaw komentarz, jeśli coś stało się jasne. Do zobaczenia w kolejnym odcinku.