मार्गदर्शिका

विभिन्न सब्सक्रिप्शन या क्षेत्रों में VNets के आर-पार संसाधनों को निजी तौर पर कनेक्ट करें।

→वर्चुअल नेटवर्क के बीच VNet Peering कॉन्फ़िगर करें।

क्यों: ट्रैफ़िक को Microsoft Backbone पर रखता है। VNet Peering गैर-संक्रमणीय है; संचार के लिए प्रत्यक्ष Peering आवश्यक है (A->B, B->C != A->C)।

संदर्भ↗

भविष्य की कनेक्टिविटी के लिए VNet एड्रेस स्पेस डिज़ाइन करें।

→प्रत्येक VNet को अद्वितीय, गैर-ओवरलैपिंग CIDR ब्लॉक असाइन करें।

क्यों: VNet Peering के लिए गैर-ओवरलैपिंग एड्रेस स्पेस की आवश्यकता होती है। पुनर्गठन से बचने के लिए विकास की योजना बनाएं।

विशेष होस्ट संख्या के लिए आवश्यक सबनेट आकार की गणना करें।

→CIDR नोटेशन का उपयोग करें जो आवश्यक होस्ट + Azure के लिए 5 आरक्षित IP एड्रेस प्रदान करता है।

क्यों: Azure प्रत्येक सबनेट में पहले चार और अंतिम IP एड्रेस को आरक्षित करता है। एक /24 (256 IP) केवल 251 उपयोग योग्य IP प्रदान करता है।

Azure Firewall, Gateway, या Bastion जैसी सेवाओं को डिप्लॉय करें।

→विशिष्ट नामों (जैसे AzureFirewallSubnet, GatewaySubnet, AzureBastionSubnet) और न्यूनतम आकारों (/26, /27, /26 क्रमशः) के साथ समर्पित सबनेट बनाएं।

क्यों: इन सेवाओं को अपने संसाधनों को इंजेक्ट करने के लिए समर्पित, विशेष रूप से नामित सबनेट की आवश्यकता होती है। कार्यक्षमता और भविष्य के स्केलिंग के लिए आकार महत्वपूर्ण है।

ऑन-प्रिमाइसेस नेटवर्क और Azure Private DNS ज़ोन के बीच नाम रिज़ॉल्यूशन सक्षम करें।

→Azure DNS Private Resolver डिप्लॉय करें। ऑन-प्रिमाइसेस से Azure क्वेरीज़ के लिए इनबाउंड एंडपॉइंट और Azure से ऑन-प्रिमाइसेस क्वेरीज़ के लिए फ़ॉरवर्डिंग नियमों के साथ एक आउटबाउंड एंडपॉइंट का उपयोग करें।

क्यों: कस्टम DNS VMs की आवश्यकता के बिना हाइब्रिड DNS के लिए एक प्रबंधित PaaS समाधान प्रदान करता है। ऑन-प्रिमाइसेस DNS इनबाउंड एंडपॉइंट IP पर अग्रेषित होता है।

संदर्भ↗

एक Peered VNet एक Private DNS ज़ोन में रिकॉर्ड्स को हल नहीं कर सकता है।

→Private DNS ज़ोन से Peered VNet तक एक वर्चुअल नेटवर्क लिंक बनाएं।

क्यों: Private DNS ज़ोन का एक्सेस Peering के माध्यम से संक्रमणीय नहीं है। रिज़ॉल्यूशन की आवश्यकता वाले प्रत्येक VNet में एक स्पष्ट लिंक होना चाहिए।

एक सबनेट में VMs के लिए allow-listing के लिए एक स्थिर, अनुमानित आउटबाउंड Public IP प्रदान करें।

→एक Azure NAT Gateway को एक Public IP या Public IP Prefix के साथ सबनेट से संबद्ध करें।

क्यों: NAT Gateway एक सबनेट के लिए अन्य सभी आउटबाउंड कनेक्टिविटी विधियों को ओवरराइड करता है, यह सुनिश्चित करता है कि सभी ट्रैफ़िक उसके स्थिर Public IP(s) का उपयोग करें।

संदर्भ↗

यह सुनिश्चित करें कि Load Balancer जैसे संसाधन के लिए एक Public IP स्थिर रहे।

→Static एलोकेशन के साथ Standard SKU Public IP एड्रेस का उपयोग करें।

क्यों: Standard SKU स्थिर IP डिफ़ॉल्ट रूप से ज़ोन-रिडंडेंट होते हैं और संबंधित संसाधन के बंद या हटा दिए जाने पर भी बने रहते हैं।

Azure CNI नेटवर्किंग का उपयोग करके एक AKS क्लस्टर के लिए एक सबनेट डिज़ाइन करें।

→IP आवश्यकताओं की गणना (नोड्स की संख्या * प्रति नोड अधिकतम पॉड्स) + नोड्स की संख्या के रूप में करें। एक सबनेट आवंटित करें जो इस संख्या को समायोजित कर सके।

क्यों: Azure CNI के साथ, प्रत्येक पॉड को सीधे सबनेट से एक IP मिलता है, जिसके लिए महत्वपूर्ण IP एड्रेस एलोकेशन की आवश्यकता होती है।

एक spoke VNet से सभी इंटरनेट-बाउंड ट्रैफ़िक को hub VNet में Azure Firewall के माध्यम से रूट करें।

→0.0.0.0/0 के लिए एक रूट, अगले हॉप प्रकार "Virtual appliance", और Azure Firewall के Private IP के साथ एक User Defined Route (UDR) तालिका बनाएं।

क्यों: यह इंटरनेट के लिए डिफ़ॉल्ट सिस्टम रूट को ओवरराइड करता है, निरीक्षण के लिए सभी ट्रैफ़िक को Firewall के माध्यम से बाध्य करता है।

संदर्भ↗

हब में Azure Firewall का उपयोग करके दो spoke VNets के बीच ट्रैफ़िक का निरीक्षण करें।

→प्रत्येक spoke में, Firewall की ओर इशारा करते हुए अन्य spoke एड्रेस स्पेस के लिए UDRs बनाएं। Firewall में, ट्रैफ़िक को अनुमति देने के लिए नेटवर्क नियम बनाएं।

क्यों: दोनों spokes पर Firewall को ट्रैफ़िक भेजने के लिए राउटिंग कॉन्फ़िगर किया जाना चाहिए, जो डिफ़ॉल्ट रूप से इंटर-VNet ट्रैफ़िक को अस्वीकार करता है।

ट्रैफ़िक निरीक्षण या राउटिंग के लिए एक लचीला NVA क्लस्टर डिप्लॉय करें।

→Azure Route Server का उपयोग करें। NVAs BGP के माध्यम से Route Server के साथ Peering करते हैं और रूट्स का विज्ञापन करते हैं। Route Server लोड वितरण के लिए ECMP का उपयोग करता है।

क्यों: Route Server NVAs के साथ डायनेमिक राउटिंग को सरल बनाता है, जटिल UDR प्रबंधन को समाप्त करता है और स्वचालित फेलओवर प्रदान करता है।

संदर्भ↗

एक NVA उस ट्रैफ़िक को छोड़ रहा है जिसे उसे रूट करना चाहिए।

→NVA के नेटवर्क इंटरफ़ेस (NIC) पर "IP forwarding" सक्षम करें।

क्यों: यह Azure-स्तर की सेटिंग NIC को अपने स्वयं के IP एड्रेस के लिए निर्धारित नहीं किए गए ट्रैफ़िक को प्राप्त करने और अग्रेषित करने की अनुमति देने के लिए आवश्यक है।

HTTP/S ट्रैफ़िक को WAF और SSL ऑफलोडिंग के साथ सबसे कम विलंबता वाले बैकएंड में विश्व स्तर पर वितरित करें।

→Azure Front Door का उपयोग करें।

क्यों: Front Door इष्टतम प्रदर्शन के लिए anycast राउटिंग का उपयोग करता है और एज पर WAF, URL राउटिंग और SSL ऑफलोडिंग को एकीकृत करता है।

संदर्भ↗

हेल्थ-प्रोब चालित फेलओवर के साथ DNS के आधार पर ग्लोबल एंडपॉइंट्स पर ट्रैफ़िक वितरित करें।

→Azure Traffic Manager का उपयोग करें।

क्यों: Traffic Manager एक DNS-आधारित Load Balancer है। सबसे कम विलंबता के लिए "Performance" राउटिंग या सक्रिय/निष्क्रिय फेलओवर के लिए "Priority" का उपयोग करें।

WAF, SSL टर्मिनेशन, और URL/होस्ट-आधारित राउटिंग के साथ क्षेत्रीय HTTP/S लोड संतुलन प्रदान करें।

→Azure Application Gateway v2 डिप्लॉय करें।

क्यों: Application Gateway एक क्षेत्रीय L7 Load Balancer है। URL राउटिंग के लिए पाथ-आधारित नियमों और होस्ट-आधारित राउटिंग के लिए मल्टी-साइट लिसनर्स का उपयोग करें।

एक क्षेत्र के भीतर गैर-HTTP/S (TCP/UDP) ट्रैफ़िक को लोड बैलेंस करें।

→Azure Load Balancer (Standard SKU) का उपयोग करें।

क्यों: Azure Load Balancer एक क्षेत्रीय L4 Load Balancer है। यह क्लाइंट सोर्स IP को सुरक्षित रखता है और सभी TCP/UDP प्रोटोकॉल के लिए उपयुक्त है।

Application Gateway पर SSL समाप्त करें लेकिन बैकएंड में ट्रैफ़िक को फिर से एन्क्रिप्ट करें।

→एक HTTPS लिसनर कॉन्फ़िगर करें। बैकएंड HTTP सेटिंग्स में, प्रोटोकॉल को HTTPS पर सेट करें और बैकएंड सर्वर के विश्वसनीय रूट प्रमाणपत्र को अपलोड करें।

क्यों: यह सुनिश्चित करता है कि ट्रैफ़िक बैकएंड तक पूरी तरह से ट्रांज़िट में एन्क्रिप्टेड है, भले ही बैकएंड सर्वर पर स्व-हस्ताक्षरित प्रमाणपत्र हों।

SQL Server Always On Availability Group लिसनर पर ट्रैफ़िक लोड बैलेंस करें।

→लोड बैलेंसिंग नियम पर "Floating IP (Direct Server Return)" सेटिंग सक्षम के साथ एक आंतरिक Standard Load Balancer का उपयोग करें।

क्यों: SQL AG लिसनर के सही ढंग से कार्य करने के लिए Floating IP आवश्यक है, क्योंकि यह फेलओवर के बाद सेकेंडरी नोड को क्लाइंट्स को सीधे जवाब देने की अनुमति देता है।

सभी प्रोटोकॉल और पोर्ट को संसाधित करने वाले NVAs के क्लस्टर पर ट्रैफ़िक लोड बैलेंस करें।

→एक "HA Ports" लोड बैलेंसिंग नियम के साथ एक आंतरिक Standard Load Balancer का उपयोग करें।

क्यों: HA Ports नियम सभी TCP और UDP ट्रैफ़िक को सभी पोर्ट पर अग्रेषित करता है, उन NVAs के लिए कॉन्फ़िगरेशन को सरल बनाता है जिन्हें सभी ट्रैफ़िक प्रवाह का निरीक्षण करने की आवश्यकता होती है।

एक प्राथमिक और द्वितीयक वेब एप्लिकेशन ओरिजिन के बीच स्वचालित फेलओवर कॉन्फ़िगर करें।

→दोनों ओरिजिन को एक ही Front Door ओरिजिन समूह में रखें। प्राथमिक ओरिजिन को 1 की प्राथमिकता और द्वितीयक को कम प्राथमिकता (जैसे 2) असाइन करें।

क्यों: Front Door हमेशा उच्चतम-प्राथमिकता वाले स्वस्थ ओरिजिन को ट्रैफ़िक भेजता है। जब प्राथमिक स्वास्थ्य जांच में विफल हो जाता है, तो ट्रैफ़िक स्वचालित रूप से अगली प्राथमिकता में बदल जाता है।

प्रबंधन पोर्ट को इंटरनेट पर उजागर किए बिना Azure VMs को सुरक्षित RDP/SSH एक्सेस प्रदान करें।

→Azure Bastion डिप्लॉय करें (उन्नत सुविधाओं के लिए Standard SKU)।

क्यों: Bastion एक प्रबंधित जंप बॉक्स के रूप में कार्य करता है, TLS पर Azure पोर्टल के माध्यम से एक्सेस प्रदान करता है। यह प्रबंधन के लिए VMs पर Public IPs की आवश्यकता को समाप्त करता है।

संदर्भ↗

अपने VNet के भीतर से एक Private IP एड्रेस का उपयोग करके Azure PaaS सेवा (जैसे SQL, Storage) तक पहुंचें।

→PaaS संसाधन के लिए एक Private Endpoint बनाएं। स्वचालित नाम रिज़ॉल्यूशन के लिए एक Private DNS Zone के साथ एकीकृत करें।

क्यों: Private Endpoint PaaS सेवा को आपके VNet में एक Private IP के साथ प्रोजेक्ट करता है, जिससे वास्तव में निजी कनेक्टिविटी सक्षम होती है। PaaS सेवा पर सार्वजनिक नेटवर्क एक्सेस को अक्षम करना इसे लागू करता है।

Public IPs का उपयोग किए बिना, लेकिन एक समर्पित Private IP को प्रबंधित किए बिना Azure Backbone पर VNet से Azure PaaS सेवाओं तक पहुंचें।

→स्रोत सबनेट पर विशिष्ट सेवा (जैसे Microsoft.Storage) के लिए एक Service Endpoint सक्षम करें।

क्यों: Service Endpoints VNet से PaaS सेवाओं के लिए एक सीधा मार्ग प्रदान करते हैं, लेकिन VNet में एक Private IP का उपयोग नहीं करते हैं। यह Private Endpoints की तुलना में सरल लेकिन कम लचीला है।

अपने VNet में चल रही सेवा को अन्य VNets (संभवतः अन्य टेनेंट्स) में उपभोक्ताओं को निजी तौर पर उजागर करें।

→सेवा को एक Standard Load Balancer के पीछे रखें और उस पर इंगित करते हुए एक Private Link Service बनाएं।

क्यों: Private Link Service प्रदाता-पक्ष घटक है। उपभोक्ता आपकी सेवा से निजी तौर पर कनेक्ट होने के लिए अपने VNets में Private Endpoints बनाते हैं।

संदर्भ↗

एक मल्टी-टियर एप्लिकेशन के लिए NSG नियमों को सरल बनाएं जहां VMs स्केल या IP बदल सकते हैं।

→प्रत्येक टियर (जैसे Web, App, DB) के लिए Application Security Groups (ASGs) बनाएं। ASGs को स्रोत/गंतव्य के रूप में उपयोग करके NSG नियम परिभाषित करें।

क्यों: ASGs VMs के लिए नेटवर्क ऑब्जेक्ट टैग के रूप में कार्य करते हैं, जिससे आप भंगुर IP एड्रेस के बजाय एप्लिकेशन संरचना के आधार पर नियम बना सकते हैं।

जब NSG एक NIC और उसके सबनेट दोनों पर लागू होते हैं तो ट्रैफ़िक अप्रत्याशित रूप से अवरुद्ध हो जाता है।

→NSG नियम मूल्यांकन क्रम को याद करें। इनबाउंड: पहले NIC नियम, फिर सबनेट नियम। आउटबाउंड: पहले सबनेट नियम, फिर NIC नियम।

क्यों: किसी भी स्तर पर अस्वीकृति ट्रैफ़िक को अवरुद्ध कर देगी। ट्रैफ़िक प्रवाह को सफल होने के लिए दोनों NSG को अनुमति देनी चाहिए।

ज्ञात दुर्भावनापूर्ण IP एड्रेस और डोमेन से/तक ट्रैफ़िक को स्वचालित रूप से ब्लॉक करें।

→Azure Firewall Threat intelligence-based filtering को "Alert and deny" मोड में सक्षम करें।

क्यों: यह Microsoft के थ्रेट इंटेलिजेंस फीड का उपयोग शून्य कॉन्फ़िगरेशन के साथ ज्ञात खतरों के खिलाफ प्रबंधित, अप-टू-डेट सुरक्षा प्रदान करने के लिए करता है।

मालवेयर जैसे खतरों के लिए एन्क्रिप्टेड HTTPS ट्रैफ़िक का निरीक्षण करें।

→Azure Firewall Premium का उपयोग करें। पॉलिसी में TLS Inspection सक्षम करें और एक इंटरमीडिएट CA प्रमाणपत्र डिप्लॉय करें जिस पर क्लाइंट को भरोसा करना चाहिए।

क्यों: यह एक प्रीमियम सुविधा है जो ट्रैफ़िक का निरीक्षण करने के लिए मैन-इन-द-मिडल डिक्रिप्शन करती है, जो जीरो-ट्रस्ट सुरक्षा स्थिति के लिए महत्वपूर्ण है।

IP सूचियों को बनाए रखे बिना Windows Update जैसी जटिल Microsoft सेवाओं तक आउटबाउंड एक्सेस की अनुमति दें।

→Azure Firewall में, FQDN टैग्स (जैसे "WindowsUpdate", "AzureBackup") का उपयोग करके एक Application Rule बनाएं।

क्यों: Microsoft इन टैग्स से जुड़े FQDNs को प्रबंधित करता है, जिससे डायनामिक सेवाओं के लिए Firewall नियम प्रबंधन सरल हो जाता है।

पब्लिक-फेसिंग एप्लिकेशन को वॉल्यूमेट्रिक DDoS हमलों से बचाएं और त्वरित प्रतिक्रिया समर्थन तक पहुंच प्राप्त करें।

→VNet पर DDoS Network Protection (पूर्व में Standard) सक्षम करें।

क्यों: यह अनुकूली ट्यूनिंग, अटैक टेलीमेट्री, मिटिगेशन रिपोर्ट, और DDoS रैपिड रिस्पांस टीम तक पहुंच प्रदान करता है, जिसकी मुफ्त बेसिक सुरक्षा में कमी है।

एक कनेक्टिविटी विफलता का निदान करें और उस सटीक हॉप की पहचान करें जहां ट्रैफ़िक गिराया जा रहा है।

→Network Watcher > Connection Troubleshoot का उपयोग करें।

क्यों: यह एक एंड-टू-एंड जांच करता है, जिसमें पूर्ण हॉप-बाय-हॉप पाथ दिखाया जाता है और NSGs, UDRs, या अन्य नेटवर्क मुद्दों के कारण होने वाली विफलताओं को इंगित करता है।

जल्दी से सत्यापित करें कि क्या एक NSG नियम किसी VM से/तक ट्रैफ़िक को अनुमति दे रहा है या अस्वीकार कर रहा है।

→Network Watcher > IP Flow Verify का उपयोग करें।

क्यों: यह NSG नियमों के विरुद्ध एक विशिष्ट 5-ट्यूपल का परीक्षण करने और यह देखने के लिए सबसे सीधा उपकरण है कि कौन सा नियम परिणाम के लिए जिम्मेदार है।

अनुपालन और विश्लेषण के लिए सभी अनुमति प्राप्त और अस्वीकृत नेटवर्क ट्रैफ़िक को लॉग करें।

→NSG Flow Logs सक्षम करें और उन्हें Traffic Analytics (एक Log Analytics Workspace के माध्यम से) में शामिल करें।

क्यों: NSG Flow Logs कच्चा ट्रैफ़िक डेटा प्रदान करते हैं। Traffic Analytics ट्रैफ़िक पैटर्न, शीर्ष वार्तालापकों और सुरक्षा खतरों की पहचान करने के लिए इस डेटा को समृद्ध और कल्पना करता है।

एक निजी, समर्पित कनेक्शन के साथ एक ऑन-प्रिमाइसेस नेटवर्क को Azure से कनेक्ट करें जो अनुमानित विलंबता और उच्च बैंडविड्थ प्रदान करता है।

→एक Azure ExpressRoute सर्किट प्रोविजन करें।

क्यों: ExpressRoute पूरी तरह से पब्लिक इंटरनेट को बायपास करता है, जो Site-to-Site VPN की तुलना में अधिक विश्वसनीय, तेज़ और कम विलंबता वाला कनेक्शन प्रदान करता है।

संदर्भ↗

Azure संसाधनों तक पहुंचने के लिए सही ExpressRoute Peering चुनें।

→VNets से कनेक्ट करने के लिए Azure Private Peering का उपयोग करें। पब्लिक PaaS सेवाओं और Microsoft 365 तक पहुंचने के लिए Microsoft Peering का उपयोग करें।

क्यों: दो Peering प्रकार विभिन्न संसाधनों तक पहुंच प्रदान करते हैं। Microsoft Peering के लिए Public IPs, NAT, और रूट फिल्टर की आवश्यकता होती है।

spoke VNets को hub VNet में एक केंद्रीय VPN या ExpressRoute Gateway के माध्यम से ऑन-प्रिमाइसेस नेटवर्क तक पहुंचने की अनुमति दें।

→हब-टू-स्पोक Peering पर, "Allow gateway transit" सक्षम करें। स्पोक-टू-हब Peering पर, "Use remote gateways" सक्षम करें।

क्यों: यह दो-भाग का कॉन्फ़िगरेशन spokes को हब के Gateway का उपयोग करने की अनुमति देता है, जिससे हाइब्रिड कनेक्टिविटी केंद्रीकृत होती है।

ExpressRoute कनेक्शन के लिए बैकअप के रूप में एक Site-to-Site VPN कॉन्फ़िगर करें।

→एक ExpressRoute और एक VPN Gateway दोनों को डिप्लॉय करें। डिफ़ॉल्ट रूप से, ExpressRoute पाथ को उसी प्रीफ़िक्स के लिए VPN पाथ पर प्राथमिकता दी जाती है।

क्यों: Azure उच्च डिफ़ॉल्ट रूट वेट के कारण ExpressRoute को स्वचालित रूप से प्राथमिकता देता है। यदि ExpressRoute सर्किट विफल हो जाता है, तो BGP रूट्स को वापस ले लेगा और ट्रैफ़िक VPN पर फेल ओवर हो जाएगा।

सक्रिय/निष्क्रिय रिडंडेंसी के लिए एक ExpressRoute सर्किट को दूसरे पर प्राथमिकता देने के लिए ट्रैफ़िक को प्रभावित करें।

→BGP AS Path prepending का उपयोग करें। बैकअप सर्किट पर रूट विज्ञापनों में अपनी खुद की ASN को कई बार जोड़ें ताकि उसका पाथ लंबा दिखाई दे।

क्यों: BGP सबसे छोटे AS Path को प्राथमिकता देता है। यह प्राथमिक सर्किट को पसंदीदा पाथ बनाता है, यदि प्राथमिक पाथ वापस ले लिया जाता है तो बैकअप पर स्वचालित फेलओवर होता है।

अपने मौजूदा ExpressRoute सर्किट का उपयोग करके Microsoft Backbone नेटवर्क के माध्यम से दो ऑन-प्रिमाइसेस साइट्स को कनेक्ट करें।

→ExpressRoute Global Reach सक्षम करें।

क्यों: Global Reach दो ExpressRoute सर्किट को एक साथ लिंक करता है, जिससे Microsoft नेटवर्क पर एक निजी WAN सक्षम होता है, जिसमें Azure VNet में ट्रैफ़िक को हेयरपिन करने की आवश्यकता नहीं होती है।

कई शाखा कार्यालयों और VNets को जोड़ने वाले एक ग्लोबल नेटवर्क के प्रबंधन को सरल बनाएं।

→Azure Virtual WAN डिप्लॉय करें।

क्यों: Virtual WAN स्वचालित किसी भी-से-किसी भी संक्रमणीय कनेक्टिविटी, राउटिंग और सुरक्षा सेवाओं (सुरक्षित हब) के साथ एक प्रबंधित हब-एंड-स्पोक सेवा प्रदान करता है।

संदर्भ↗

Virtual WAN में, सभी इंटर-VNet, इंटर-ब्रांच और इंटरनेट-बाउंड ट्रैफ़िक का केंद्रीय रूप से निरीक्षण करें।

→एक सुरक्षित वर्चुअल हब (Azure Firewall के साथ) डिप्लॉय करें। Firewall के माध्यम से निजी और इंटरनेट ट्रैफ़िक भेजने के लिए राउटिंग इंटेंट कॉन्फ़िगर करें।

क्यों: राउटिंग इंटेंट vWAN में ट्रैफ़िक इंजीनियरिंग को सरल बनाता है, मैन्युअल UDRs के बिना सुरक्षा प्रदाता के माध्यम से ट्रैफ़िक को बाध्य करने के लिए रूट्स को स्वचालित रूप से प्रोग्राम करता है।

Azure को एक लचीला VPN कनेक्शन प्रदान करें।

→एक सक्रिय-सक्रिय कॉन्फ़िगरेशन में एक VPN Gateway डिप्लॉय करें। इसके लिए दो Public IPs और दो सुरंग स्थापित करने में सक्षम एक ऑन-प्रिमाइसेस डिवाइस की आवश्यकता होती है।

क्यों: Azure क्षेत्र के भीतर इंस्टेंस-स्तरीय रिडंडेंसी प्रदान करता है। क्रॉस-जोन रिडंडेंसी के लिए, ज़ोन-रिडंडेंट (AZ) SKUs का उपयोग करें।

अतिरिक्त सॉफ़्टवेयर के बिना व्यापक क्लाइंट संगतता के लिए एक Point-to-Site VPN प्रोटोकॉल चुनें।

→IKEv2 का उपयोग करें। पुराने उपकरणों सहित अधिकतम संगतता के लिए, OpenVPN का उपयोग करें।

क्यों: IKEv2 आधुनिक Windows, macOS और iOS पर मूल रूप से समर्थित है। SSTP केवल Windows के लिए है। OpenVPN को एक क्लाइंट की आवश्यकता होती है लेकिन यह व्यापक रूप से समर्थित है।

Azure VMs से सभी इंटरनेट-बाउंड ट्रैफ़िक को एक ऑन-प्रिमाइसेस सुरक्षा उपकरण पर रीडायरेक्ट करें।

→ऑन-प्रिमाइसेस से, ExpressRoute या VPN कनेक्शन पर BGP के माध्यम से एक डिफ़ॉल्ट रूट (0.0.0.0/0) का विज्ञापन करें।

क्यों: यह BGP विज्ञापन Azure के डिफ़ॉल्ट इंटरनेट रूट को ओवरराइड करता है, निरीक्षण के लिए ट्रैफ़िक को वापस ऑन-प्रिमाइसेस नेटवर्क पर बाध्य करता है।