Planowanie adresowania IP

Ważne jest, aby organizacja planuje adresowanie IP na platformie Azure. Planowanie zapewnia, że przestrzeń adresowa IP nie nakłada się na lokalizacje lokalne i regiony platformy Azure.

Zagadnienia dotyczące projektowania:

• Nakładające się przestrzenie adresów IP w lokalnych regionach i regionach platformy Azure tworzą poważne wyzwania związane z rywalizacją.

• Usługa Azure VPN Gateway może łączyć nakładające się lokacje lokalne z nakładającymi się przestrzeniami adresów IP za pośrednictwem funkcji translatora adresów sieciowych (NAT). Ta funkcja jest ogólnie dostępna w usłudze Azure Virtual WAN i autonomicznej usłudze Azure VPN Gateway.

  

• Przestrzeń adresową można dodać po utworzeniu sieci wirtualnej. Ten proces nie wymaga awarii, jeśli sieć wirtualna jest już połączona z inną siecią wirtualną za pośrednictwem komunikacji równorzędnej sieci wirtualnej. Zamiast tego każda zdalna komunikacja równorzędna wymaga wykonania operacji ponownej synchronizacji po zmianie przestrzeni sieciowej.

• Platforma Azure rezerwuje pięć adresów IP w każdej podsieci. Uwzględnij te adresy podczas określania rozmiaru sieci wirtualnych i uwzględnionych podsieci.

• Niektóre usługi platformy Azure wymagają dedykowanych podsieci. Te usługi obejmują usługę Azure Firewall i usługę Azure VPN Gateway.

• Podsieci można delegować do niektórych usług w celu utworzenia wystąpień usługi w podsieci.

Zalecenia dotyczące projektowania:

• Zaplanuj nienakładające się przestrzenie adresów IP w regionach platformy Azure i lokalizacjach lokalnych z wyprzedzeniem.

• Użyj adresów IP z alokacji adresów dla prywatnego Internetu, znanego jako adresy RFC 1918.

• Nie używaj następujących zakresów adresów:

  • 224.0.0.0/4 (multiemisji)
  • 255.255.255.255/32 (emisja)
  • 127.0.0.0/8 (sprzężenia zwrotnego)
  • 169.254.0.0/16 (link-local)
  • 168.63.129.16/32 (wewnętrzny system DNS)

• W przypadku środowisk, które mają ograniczoną dostępność prywatnych adresów IP, rozważ użycie protokołu IPv6. Sieci wirtualne mogą być tylko protokołem IPv4 lub podwójnym stosem IPv4+IPv6.

  

• Nie twórz dużych sieci wirtualnych, takich jak /16. Gwarantuje to, że przestrzeń adresowa IP nie zostanie zmarnowana. Najmniejsza obsługiwana podsieć IPv4 to /29, a największa jest /2 w przypadku używania definicji podsieci bezklasowej międzydomenowej (CIDR). Podsieci IPv6 muszą mieć dokładnie /64 rozmiar.

• Nie twórz sieci wirtualnych bez wcześniejszego planowania wymaganej przestrzeni adresowej.

• Nie używaj publicznych adresów IP dla sieci wirtualnych, zwłaszcza jeśli publiczne adresy IP nie należą do organizacji.

• Weź pod uwagę usługi, których będziesz używać, istnieją pewne usługi z zastrzeżonymi adresami IP (adresami IP), takimi jak usługa AKS z siecią CNI

• Aby zapobiec wyczerpaniu protokołu IPv4, użyj sieci wirtualnych będącej szprychą strefy docelowej i usługi Azure Private Link.

Zagadnienia dotyczące protokołu IPv6

Coraz większa liczba organizacji wdraża protokół IPv6 w swoich środowiskach. To wdrożenie jest spowodowane wyczerpaniem przestrzeni publicznej IPv4, niedoborem prywatnego protokołu IPv4, zwłaszcza w sieciach na dużą skalę, a także koniecznością zapewnienia łączności z klientami korzystającymi tylko z protokołu IPv6. Nie ma uniwersalnego podejścia do wdrażania protokołu IPv6. Istnieją jednak najlepsze rozwiązania, które można stosować podczas planowania protokołu IPv6 i implementowania go w istniejących sieciach platformy Azure.

Przewodnik Microsoft Cloud Adoption Framework dla platformy Azure ułatwia zrozumienie zagadnień, które należy wziąć pod uwagę podczas tworzenia systemów w chmurze. Aby dowiedzieć się więcej o najlepszych rozwiązaniach dotyczących architektury do projektowania zrównoważonych systemów, zobacz Zasady projektowania strefy docelowej platformy Azure. Szczegółowe zalecenia i najlepsze rozwiązania dotyczące architektury chmury, w tym wdrożenia architektury referencyjnej, diagramy i przewodniki, można znaleźć w przewodniku Centrum architektury dla protokołu IPv6.

Zagadnienia dotyczące projektowania:

• Faza wdrożenia protokołu IPv6. W zależności od potrzeb biznesowych w razie potrzeby zaimplementuj protokół IPv6. Pamiętaj, że protokoły IPv4 i IPv6 mogą współistnieć tak długo, jak to konieczne.

• W scenariuszach, w których aplikacje korzystają z usług infrastruktury jako usługi (IaaS), które mają pełną obsługę protokołu IPv6, takich jak maszyny wirtualne, jest możliwe natywne kompleksowe korzystanie z protokołów IPv4 i IPv6. Ta konfiguracja pozwala uniknąć komplikacji związanych z tłumaczeniem i dostarcza najwięcej informacji do serwera i aplikacji.

  Moduły równoważenia obciążenia platformy Azure dostępne z Internetu można wdrożyć za pomocą adresu IPv6 w warstwie Podstawowa. Ta konfiguracja umożliwia kompleksową łączność IPv6 między publicznym Internetem a maszynami wirtualnymi platformy Azure za pośrednictwem modułu równoważenia obciążenia. Takie podejście ułatwia również natywne kompleksowe połączenia wychodzące między maszynami wirtualnymi i klientami obsługującymi protokół IPv6 w publicznym Internecie. Należy pamiętać, że takie podejście wymaga, aby każde urządzenie w ścieżce obsługiwało ruch IPv6.

  Natywne kompleksowe podejście jest najbardziej przydatne w przypadku bezpośredniej komunikacji między serwerami lub klientem i serwerem. Nie jest to przydatne w przypadku większości usług internetowych i aplikacji, które są zwykle chronione przez zapory, zapory aplikacji internetowej lub odwrotne serwery proxy.

• Niektóre złożone wdrożenia i aplikacje korzystające z kombinacji usług innych firm, usług typu platforma jako usługa (PaaS) i rozwiązania zaplecza mogą nie obsługiwać natywnego protokołu IPv6. W takich przypadkach należy użyć translatora adresów sieciowych/nat64 lub rozwiązania serwera proxy IPv6, aby umożliwić komunikację między protokołami IPv6 i IPv4.

• Jeśli złożoność architektury aplikacji lub innych czynników, takich jak koszty trenowania, są uważane za znaczące, warto nadal używać infrastruktury tylko do obsługi protokołu IPv4 na zapleczu i wdrożyć bramę IPv4/IPv6 urządzenia sieciowego innej firmy na potrzeby dostarczania usług.

  Typowe wdrożenie korzystające z urządzenia WUS może wyglądać następująco:

  

Zalecenia dotyczące projektowania:

Poniżej przedstawiono bliżej, jak może wyglądać typowa architektura:

• Wdróż urządzenie WUS w zestawach skalowania maszyn wirtualnych za pomocą elastycznej aranżacji (VMSS Flex) w celu zapewnienia odporności i uwidaczniaj je w Internecie za pośrednictwem usługi Azure Load-Balancer, która ma fronton publicznego adresu IP.

  Urządzenia WUS akceptują ruch IPv4 i IPv6 i tłumaczą go na ruch tylko IPv4 w celu uzyskania dostępu do aplikacji w podsieci aplikacji. Takie podejście zmniejsza złożoność zespołu aplikacji i zmniejsza obszar ataków.

• Wdróż usługę Azure Front Door , aby zapewnić globalny routing dla ruchu internetowego.

  Funkcje usługi Azure Front Door obejmują proxying IPv6 client requests and traffic to an IPv4-only back end ( Jak pokazano poniżej:

  

Są to główne różnice między podejściem urządzenia WUS a podejściem do usługi Azure Front Door:

• Urządzenia WUS są zarządzane przez klienta, działają w warstwie 4 modelu OSI i mogą być wdrażane w tej samej sieci wirtualnej platformy Azure co aplikacja z prywatnym i publicznym interfejsem.
• Azure Front Door to globalna usługa PaaS platformy Azure i działa w warstwie 7 (HTTP/HTTPS). Zaplecze aplikacji to usługa dostępna z Internetu, która może być zablokowana w celu akceptowania tylko ruchu z usługi Azure Front Door.

W złożonych środowiskach można użyć kombinacji obu tych elementów. Urządzenia WUS są używane we wdrożeniu regionalnym. Usługa Azure Front Door służy do kierowania ruchu do co najmniej jednego wdrożenia regionalnego w różnych regionach platformy Azure lub w innych lokalizacjach internetowych. Aby określić najlepsze rozwiązanie, zalecamy przejrzenie możliwości usługi Azure Front Door i dokumentacji produktu.

Bloki CIDR sieci wirtualnej IPv6:

• Podczas tworzenia nowej sieci wirtualnej w ramach istniejącego wdrożenia platformy Azure w ramach subskrypcji można skojarzyć pojedynczy blok routingu międzydomenowego bezklasowego (CIDR, Classless Inter-Domain Routing, IPv6 Classless Inter-Domain Routing) podczas tworzenia nowej sieci wirtualnej w istniejącym wdrożeniu platformy Azure. Rozmiar podsieci dla protokołu IPv6 musi być /64. Użycie tego rozmiaru zapewnia zgodność w przyszłości, jeśli zdecydujesz się włączyć routing podsieci do sieci lokalnej. Niektóre routery mogą akceptować tylko /64 trasy IPv6.
• Jeśli masz istniejącą sieć wirtualną, która obsługuje tylko protokół IPv4 i zasoby w podsieci skonfigurowane do używania tylko protokołu IPv4, możesz włączyć obsługę protokołu IPv6 dla sieci wirtualnej i zasobów. Sieć wirtualna może działać w trybie podwójnego stosu, co umożliwia zasobom komunikowanie się za pośrednictwem protokołów IPv4, IPv6 lub obu tych typów. Komunikacja IPv4 i IPv6 jest niezależna od siebie.
• Nie można wyłączyć obsługi protokołu IPv4 dla sieci wirtualnej i podsieci. Protokół IPv4 to domyślny system adresowania IP dla sieci wirtualnych platformy Azure.
• Skojarz blok CIDR IPv6 z siecią wirtualną i podsiecią lub protokołem IPv6 BYOIP. Notacja CIDR to metoda reprezentowania adresu IP i maski sieciowej. Formaty tych adresów są następujące:
  • Pojedynczy adres IPv4 to 32 bity, z czterema grupami z maksymalnie trzema cyframi dziesiętnymi. Na przykład 10.0.1.0.
  • Blok CIDR protokołu IPv4 ma cztery grupy z maksymalnie trzema cyframi dziesiętnym, od 0 do 255, oddzielone kropkami, a następnie ukośnikiem i liczbą z zakresu od 0 do 32. Na przykład 10.0.0.0/16.
  • Pojedynczy adres IPv6 to 128 bitów. Ma osiem grup czterech cyfr szesnastowych. Na przykład 2001:0db8:85a3:0000:0000:8a2e:0370:7334.
  • Blok CIDR IPv6 ma cztery grupy szesnastkowe cyfry, oddzielone dwukropkami, a następnie dwukropek, a następnie ukośnik i liczbę z zakresu od 1 do 128. Na przykład 2001:db8:1234:1a00::/64.
• Zaktualizuj tabele tras, aby kierować ruch IPv6. W przypadku ruchu publicznego utwórz trasę, która kieruje cały ruch IPv6 z podsieci do usługi VPN Gateway lub bramy usługi Azure ExpressRoute.
• Zaktualizuj reguły grupy zabezpieczeń, aby uwzględnić reguły dla adresów IPv6. Umożliwia to przepływ ruchu IPv6 do i z wystąpień. Jeśli masz reguły sieciowej grupy zabezpieczeń do kontrolowania przepływu ruchu do i z podsieci, musisz uwzględnić reguły ruchu IPv6.
• Jeśli typ wystąpienia nie obsługuje protokołu IPv6, użyj podwójnego stosu lub wdróż urządzenie WUS zgodnie z wcześniejszym opisem, które przekłada się z protokołu IPv4 na protokół IPv6.

narzędzia Zarządzanie adresami IP (IPAM)

Użycie narzędzia IPAM może pomóc w planowaniu adresów IP na platformie Azure, ponieważ zapewnia scentralizowane zarządzanie i widoczność, zapobiegając nakładaniu się i konfliktom w przestrzeniach adresowych IP. W tej sekcji przedstawiono podstawowe zagadnienia i zalecenia dotyczące wdrażania narzędzia IPAM.

Zagadnienia dotyczące projektowania:

Do rozważenia jest dostępnych wiele narzędzi IPAM, w zależności od wymagań i rozmiaru organizacji. Opcje obejmują posiadanie podstawowego spisu opartego na programie Excel na rozwiązanie oparte na społeczności typu open source lub kompleksowe produkty dla przedsiębiorstw z zaawansowanymi funkcjami i obsługą techniczną.

• Podczas oceniania narzędzia IPAM do zaimplementowania należy wziąć pod uwagę następujące czynniki:

  • Minimalne funkcje wymagane przez organizację
  • Całkowity koszt posiadania (TCO), w tym licencjonowanie i ciągła konserwacja
  • Dzienniki inspekcji, rejestrowanie i mechanizmy kontroli dostępu oparte na rolach
  • Uwierzytelnianie i autoryzacja za pomocą identyfikatora Entra firmy Microsoft
  • Dostępne za pośrednictwem interfejsu API
  • Integracje z innymi narzędziami i systemami do zarządzania sieciami
  • Aktywna pomoc techniczna społeczności lub poziom pomocy technicznej od dostawcy oprogramowania

• Rozważ ocenę narzędzia IPAM typu open source, takiego jak Azure IPAM. Azure IPAM to uproszczone rozwiązanie oparte na platformie Azure. Automatycznie odnajduje wykorzystanie adresów IP w dzierżawie platformy Azure i umożliwia zarządzanie nim ze scentralizowanego interfejsu użytkownika lub za pośrednictwem interfejsu API RESTful.

• Weź pod uwagę model operacyjny organizacji i własność narzędzia IPAM. Celem implementacji narzędzia IPAM jest usprawnienie procesu żądania nowych przestrzeni adresów IP dla zespołów aplikacji bez zależności i wąskich gardeł.

• Ważną częścią funkcji narzędzia IPAM jest spis użycia przestrzeni adresowej IP i logiczne organizowanie go.

Zalecenia dotyczące projektowania:

• Proces rezerwowania nienakładających się przestrzeni adresów IP powinien obsługiwać żądania różnych rozmiarów w zależności od potrzeb poszczególnych stref docelowych aplikacji.

  • Na przykład można wdrożyć ustalanie rozmiaru koszulki, aby ułatwić zespołom aplikacji opisanie ich potrzeb:
    • Mały — /24 — 256 adresów IP
    • Średni — /22 — 1024 adresy IP
    • Duży — /20 — 4096 adresów IP

• Narzędzie IPAM powinno mieć interfejs API do rezerwowania nienakładających się przestrzeni adresów IP w celu obsługi podejścia infrastruktury jako kodu (IaC). Ta funkcja ma również kluczowe znaczenie dla bezproblemowej integracji usługi IPAM z procesem sprzedaż abonamentów, co zmniejsza ryzyko błędów i potrzebę ręcznej interwencji.

  • Przykładem podejścia IaC jest Bicep z funkcją skryptu wdrażania lub źródłami danych narzędzia Terraform w celu dynamicznego pobierania danych z interfejsu API usługi IPAM.

• Utwórz systematyczne rozmieszczenie przestrzeni adresów IP, tworząc struktury według regionów i archetypów obciążeń platformy Azure, zapewniając czysty i możliwy do śledzenia spis sieci.

• Proces likwidowania obciążeń powinien obejmować usuwanie przestrzeni adresowych IP, które nie są już używane, co może później zostać ponownie zastosowane w przypadku nadchodzących nowych obciążeń, promowanie efektywnego wykorzystania zasobów.