Nätverkstopologi och anslutningsöverväganden för Red Hat Enterprise Linux i Azure
Den här artikeln beskriver nätverksöverväganden och rekommendationer för Red Hat Enterprise Linux (RHEL) som baseras på vägledningen i designområdet för Azure-landningszoner för nätverkstopologi och anslutning.
Arkitektur
Följande RHEL-arkitektur är en startpunkt som du kan anpassa ytterligare för att uppfylla dina specifika affärs- och tekniska krav. Du kan distribuera de olika RHEL-plattformskomponenterna och rollerna på virtuella datorer (VM) med specifik storlek och redundans efter behov. Den förenklade nätverkslayouten i de här exemplen visar arkitekturprinciper och beskriver inte ett helt företagsnätverk.
Ladda ned en Visio-fil med den här arkitekturen.
Element | Description |
---|---|
A | Komponenter i Microsoft korisnički ugovor och fakturering |
F | Komponenter i Microsoft Entra-identitets- och åtkomsthantering |
C | Komponenter i Azure-hanteringsgrupper |
D | Komponenter i windows Server Active Directory-identitetshanteringsprenumerationen |
E | Komponenter i nätverkshubbens prenumeration |
F | Komponenter i RHEL-hanterings- och identitetsprenumerationen |
G | Komponenter i Azure Management Group-prenumerationen |
H | Komponenter i rhel-produktionsarbetsbelastningsprenumerationen |
I | Komponenter lokalt |
J | Red Hat Cloud Services |
Designöverväganden för RHEL-nätverk för landningszoner
Överväg följande rekommendationer för nätverksdesignen för landningszonen:
Använd en nätverkstopologi för nav och eker för distributioner i en region eller flera regioner. Azure Virtual WAN Hub innehåller extra funktioner, eller så kan du använda en traditionell virtuell nätverkshubb. Mer information finns i Nätverk i Azure-landningszoner.
Använd infrastruktur som kod för att automatisera dina distributioner, konfigurationshantering och dag-2-åtgärder för alla nätverksrelaterade komponenter i landningszonen.
Använd privata slutpunkter för alla Azure-tjänster som stöds för att förbättra säkerheten. Privata slutpunkter ser till att all trafik dirigeras via ditt privata nätverk i stället för via offentliga IP-adresser.
Brandväggsöverväganden
Följande diagram visar en RHEL-hybridarkitektur för landningszoner i Azure-regionen.
Element | Description |
---|---|
A | Komponenter i det virtuella Red Hat Management-nätverket som finns via Red Hat Management-prenumerationen |
F | Komponenter i det virtuella RHEL-arbetsbelastningsnätverket som finns via rhel-produktionsarbetsbelastningsprenumerationen |
C | Komponenter i det virtuella identitetshanteringsnätverket som finns via Red Hat Identity Management-prenumerationen |
D | Komponenter i det virtuella RHEL-arbetsbelastningsnätverket som finns via rhel-produktionsarbetsbelastningsprenumerationen |
För Virtual WAN-topologier bör du överväga att använda Azure Firewall för att dirigera trafik över landningszoner. Azure Firewall tillhandahåller funktioner för trafikfiltrering och loggning.
En Azure VPN-gateway eller en Azure ExpressRoute-gateway styr hybridanslutningen till hubben. Om du vill övervaka och kontrollera trafiken använder du Azure Firewall eller en virtuell nätverksinstallation (NVA) i hubben.
Du kan använda en lokal brandvägg för att skydda och dirigera all inkommande och utgående Internettrafik. En brandvägg kan medföra svarstider för molnbaserade resurser. Förstå dina prestanda- och säkerhetskrav för att avgöra hur du ska dirigera inkommande och utgående trafik.
Överväganden för undernät
Följande diagram visar undernät för hantering och arbetsbelastning i en zonmotståndskraftig konfiguration.
När du planerar för IP-adressomfattningar och storleken på det virtuella nätverket för RHEL-landningszonen bör du överväga dedikerade undernät för program-, databas- och lagringsresurser.
Anta en Nulta pouzdanost-baserad metod för perimeternätverk och trafiksäkerhet. Mer information finns i Strategier för nätverkssäkerhet i Azure.
Överväganden för nätverkssäkerhetsgrupp
Använd nätverkssäkerhetsgrupper (NSG:er) för att skydda trafiken mellan undernät och trafik i öst och väst över plattformen (trafik mellan landningszoner). Azure Policy kan göra den här konfigurationen till standard för alla undernät.
Använd NSG:er och programsäkerhetsgrupper för att mikrosegmentera trafik inom landningszonen och undvik att använda en central NVA för att filtrera trafikflöden.
Aktivera NSG-flödesloggar och mata in dem i trafikanalys. För att optimera granskningsförmågan och säkerheten aktiverar du flödesloggar på alla kritiska virtuella nätverk och undernät i din prenumeration.
Använd NSG:er för att selektivt tillåta anslutning mellan landningszoner.
Programteamet bör använda programsäkerhetsgrupper på NSG:er på undernätsnivå för att skydda virtuella datorer på flera nivåer i landningszonen.
Om din organisation implementerar tvingad tunneltrafik eller en annonserad standardväg till lokala platser kan du överväga att införa utgående NSG-regler för att neka utgående trafik från det virtuella nätverket direkt till Internet. Den här konfigurationen ger återhämtning om BGP-sessionen (Border Gateway Protocol) avslutas. Mer information finns i Planera för nätverkssegmentering i landningszonen.
Övriga beaktanden
Aktivera Internet och filtrera och inspektera trafik. Utgående alternativ för att aktivera Internet och filtrera och inspektera trafik är:
- Utgående åtkomst till Red Hat Cloud via hubbnätverket.
- Lokal standardväg som använder lokal internetåtkomst.
- Virtual WAN eller traditionell virtuell nätverkshubb som skyddas med Azure Firewall eller en NVA.
Leverera innehåll och program. Inkommande alternativ för att leverera innehåll och program är:
- Azure Application Gateway med L7, TLS-avslutning (Transport Layer Security) och brandvägg för webbprogram.
- Dynamisk nätverksöversättning (DNAT) och en lastbalanserare från en lokal plats.
- Azure Virtual Network med Azure Firewall eller en NVA och Azure Route Server i olika scenarier.
- Virtual WAN-hubb med Azure Firewall, med L4 och DNAT.
- Virtuell WAN-hubb med NVA i olika scenarier.
Konfigurera domännamnsmatchning för lokala resurser och Azure-resurser. RHEL-miljön använder ofta både lokala resurser och Azure-resurser, vilket kräver effektiv namnmatchning av resurser. Överväg följande rekommendationer:
- Azure tillhandahåller en standardmatchning av interna namn i ett virtuellt nätverk. Det här scenariot kräver ingen konfiguration. Du kan inte ändra suffixet för domännamnsmatchning eller utföra manuell registrering. Mer information finns i Namnmatchning som Azure tillhandahåller.
- För namnmatchning mellan virtuella nätverk använder RHEL-distributioner ofta DNS-tjänster (Domain Name System) från Redhat Identity Management Server (IdM) eller Azure DNS. Om du vill tillhandahålla regelbaserad vidarebefordran kombinerar du Azure Private DNS Resolver och befintlig DNS-infrastruktur.