Azure UDR बाट VPN गेटवेसम्म: एउटा गन्तव्य, सम्पूर्ण निकास होइन

तपाईं एउटा बाह्य प्रिफिक्सका लागि प्रयोगकर्ता-परिभाषित रुट थप्नुहुन्छ, त्यसलाई VPN गेटवे तिर देखाउनुहुन्छ, र ट्राफिक अझै Azure को इन्टरनेट मार्गबाट बाहिर जान्छ। वा त्यो ठीकसँग बाहिर जान्छ र जवाफ कहिल्यै फर्कंदैन। दुवै परिणाम एउटै गल्तीबाट आउँछन्: Azure को अर्को हपलाई सम्पूर्ण डिजाइन मान्नु। रुट तालिकाले Azure भित्र प्याकेटले कुन निकास लिन्छ भन्ने मात्र निर्धारण गर्छ। सुरुङ पछि त्यसलाई के हुन्छ र जवाफ कसरी फर्कन्छ भन्ने तपाईंले बनाउनुपर्ने दोस्रो आधा हो।

अर्को हप एउटा गेटवे हो, यन्त्रको IP होइन

UDR ले मिल्ने प्रिफिक्सलाई अर्को-हप प्रकारमा पठाउँछ, र VirtualNetworkGateway एउटा प्रकार हो, ठेगाना होइन। मानिसहरूले गेटवेको निजी IP लाई VirtualAppliance रुटमा टाँस्छन् र त्यसपछि किन केही मिल्दैन भनेर सोच्छन्, किनकि त्यो प्रकारले यसको सट्टा NIC वा आन्तरिक लोड ब्यालेन्सर अपेक्षा गर्छ। Microsoft को राउटिङ दस्तावेजले पनि गेटवेको अर्को हपलाई गेटवे VPN गेटवे भएको भर्चुअल नेटवर्कमा सीमित गर्छ। ExpressRoute, Route Server र Virtual WAN हब त्यो विकल्पले सम्बोधन गरिँदैनन्।

रुट लेख्नु अघि भर्चुअल नेटवर्कमा वास्तवमा के छ भनी जाँच्नुहोस्। डिजाइनले हब मार्फत रुट गर्छ भने, रुट हबको राउटिङ मालिकको हो, तपाईंले सम्पादन गरिरहेको स्पोकको होइन।

केही परिवर्तन गर्नु अघि प्रभावकारी रुट पढ्नुहोस्

Azure ले प्रणाली रुट, BGP बाट सिकेका प्रिफिक्स र UDR लाई प्रत्येक NIC का लागि प्रभावकारी रुट तालिकामा जोड्छ, र सबैभन्दा लामो मिल्ने प्रिफिक्स जहाँबाट आए पनि जित्छ। एउटै प्रिफिक्सका लागि UDR ले BGP रुटलाई हराउँछ। यही क्रमले पहिलेको प्रयोगको पुरानो UDR ले सुरुङबाट भर्खरै सिकेको प्रिफिक्सलाई चुपचाप अतिक्रमण गर्न सक्छ।

पहिले प्रभावकारी तालिका हेर्नुहोस्, त्यसपछि तपाईं रुट थप्दै हुनुहुन्छ वा प्रतिस्थापन गर्दै हुनुहुन्छ भनी निर्णय गर्नुहोस्:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

प्रिफिक्ससँगै स्रोत स्तम्भ पनि पढ्नुहोस्। सही प्रिफिक्स र गलत स्रोत भएको रुटले कुन वस्तु सम्पादन गर्ने भनी बताउँछ, र पहिलोसँग हार्ने दोस्रो रुट थप्नबाट बचाउँछ।

वास्तविक प्रिफिक्स र सबनेटका आधारमा रुट लेख्नुहोस्

फोरम पोस्टबाट प्रतिलिपि गरिएको सार्वजनिक दायराको सट्टा तपाईंले वास्तवमा पुग्ने सेवाबाट लिइएको गन्तव्यको वास्तविक प्रिफिक्स प्रयोग गर्नुहोस्। सबै निकास सार्ने पूर्वनिर्धारित रुट विचार गर्नु अघि एउटा स्वीकृत सेवाबाट सुरु गर्नुहोस्। त्यसपछि रुट तालिका कार्यभार सबनेटसँग जोड्नुहोस्। गेटवे सबनेटका आफ्नै आवश्यकताहरू छन्, र त्यहाँ तपाईंको तालिका जोड्दा कार्यभार निर्देशित गर्नुको सट्टा गेटवे बिग्रन्छ।

रुट सिर्जना गर्नुहोस्, त्यसपछि तालिका कार्यभार भएको सबनेटमा बाँध्नुहोस्:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

प्रसार पनि महत्त्वपूर्ण छ। त्यो तालिकामा BGP प्रसार सक्षम भए सिकेका प्रिफिक्सहरू तपाईंले लेखेकाहरूको छेउमा देखिन्छन्, र बढी विशिष्ट सिकेको प्रिफिक्सले फराकिलो UDR लाई हराउन सक्छ। प्रसार तपाईंले त्यो सबनेटका लागि UDR समूह अधिकारिक हुन चाहँदा मात्र बन्द गर्नुहोस्।

अन-प्रिमाइस आधा पूरा गर्नुहोस्, नत्र प्रवाह त्यहीँ मर्छ

अन-प्रिमाइस गेटवेले Azure स्रोत स्वीकार गर्नुपर्छ, त्यसलाई गन्तव्यमा अगाडि पठाउनुपर्छ र अनुप्रयोगलाई अनुमति दिनुपर्छ। यसको अर्को मार्ग इन्टरनेट निकास वा अर्को निजी हप हुन सक्छ, तर त्यो निर्णय योजनामा छ, Azure रुट तालिकामा होइन। सामान्य असफलता फर्कने मार्ग हो। इन्टरनेट गन्तव्यले निजी Azure स्रोतलाई तपाईंतिर फर्केर रुट गर्दैन, त्यसैले जवाफ आफ्नै पूर्वनिर्धारित गेटवेमा गएर मर्छ, वा बाहिरै निस्कँदैन।

दुई डिजाइनले यसलाई समाधान गर्छन् र ती परस्पर विनिमय गर्न मिल्दैनन्। निकासमा स्रोतको अनुवाद गर्नुहोस्, ताकि गन्तव्यले अन-प्रिमाइस नेटवर्कको स्वामित्वमा रहेको सार्वजनिक ठेगानामा जवाफ दिन्छ। वा स्रोत जोगाएर राख्नुहोस् र जवाफहरू सुरुङबाट फर्कनका लागि रुट गरिएको फर्कने सम्बन्ध बनाउनुहोस्। एउटा छान्नुहोस् र अनुप्रयोगले कुन ठेगाना देख्नेछ भनी लेख्नुहोस्।

चयनकर्ता र अनुमति सूचीहरू यी सबैबाट अलग छन्। Azure अर्को हप छान्दा VPN ट्राफिक चयनकर्ता फराकिलो हुँदैन, र कुनै बाह्य सेवाको स्रोत अनुमति सूची परिवर्तन हुँदैन।

गन्तव्यले देख्ने स्रोतसँग प्रमाणित गर्नुहोस्

अनुरोध अर्को सबनेटको जम्प होस्टबाट होइन, वास्तविक कार्यभारबाट पठाउनुहोस्, त्यसपछि गन्तव्यले देखेको स्रोत ठेगाना पढ्नुहोस्। त्यो एउटै मानले दुई फर्कने डिजाइनमध्ये कुन लागू छ भनी बताउँछ। त्यसपछि जवाफ मार्ग जाँच्नुहोस्, र VM तर्फको सामान्य व्यवस्थापन ट्राफिक अझै चल्छ भनी पुष्टि गर्नुहोस्, किनकि दुर्घटनावश थपिएको पूर्वनिर्धारित रुट अनुप्रयोग बिग्रनुभन्दा धेरै अघि बिग्रेको SSH सत्रको रूपमा देखिन्छ।

छानिएको प्रिफिक्सबाट जाने ट्रान्जिट जबर्जस्ती सुरुङभन्दा धेरै साँघुरो परिवर्तन हो। यसलाई साँघुरो राख्नुहोस् र फर्काउनु भनेको एउटा रुट मेटाउनु हो।