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
.
- Pojedynczy adres IPv4 to 32 bity, z czterema grupami z maksymalnie trzema cyframi dziesiętnymi. Na przykład
- 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
- Mały —
- Na przykład można wdrożyć ustalanie rozmiaru koszulki, aby ułatwić zespołom aplikacji opisanie ich potrzeb:
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.