VPN सक्रिय हुँदा क्लाउड फायरवालले कुन ठेगाना देख्छ
पूरा टनेलले तपाईंको डेटाबेसले देख्ने स्रोत ठेगाना बदल्छ। अनुमति सूची, निजी मार्ग वा स्प्लिट टनेल सार्नुहोस्, प्रमाणहरू होइन।
VPN जोडिनु अघि काम गर्ने र पछि असफल हुने डेटाबेस विरलै प्रमाणको समस्या हुन्छ। क्लाउड फायरवालहरू स्रोत ठेगाना मिलाउँछन्, र पूरा टनेलले तिनीहरूले मिलाइरहेको ठेगाना नै बदल्छ। तपाईंको ल्यापटप के पठाउँछ भन्ने तपाईंको अनुमान र सर्भरले के प्राप्त गर्छ भन्नेबीचको फरक नै पूरा बग हो, र यो एकै चरणमा नाप्न सकिन्छ।
स्रोत ठेगाना के हुन्छ
पूरा टनेलमा प्रत्येक प्याकेट VPN गेटवे हुँदै बाहिर जान्छ, त्यसैले सर्भरले तपाईंको घरको जडान होइन, गेटवेको आउटबाउन्ड ठेगाना देख्छ। यदि मार्गमा फर्वार्ड प्रोक्सी छ भने त्यसको ठेगाना पुग्छ। दुवै वैध स्रोत हुन्, र तपाईंको मूल नियममा भएको ठेगाना यीमध्ये कुनै होइन।
Azure SQL का सर्भर-तह र डेटाबेस-तह फायरवाल नियमहरूले तार्किक सर्भरसम्म पुग्ने क्लाइन्ट ठेगाना मिलाउँछन्, पूरा टनेलपछि त्यही आउटबाउन्ड ठेगाना हो। एउटै ठेगाना अनुमति दिने AWS सुरक्षा समूहले पनि त्यसै गरी व्यवहार गर्छ। प्याकेट प्रमाणीकरण अघि नै खारेज हुन्छ, त्यसैले प्राप्त हुने त्रुटि अनुमतिको समस्याजस्तो नभई नेटवर्क विफलताजस्तो देखिन्छ। मानिसहरू पासवर्ड रिसेट गर्न थाल्नुको कारण ठ्याक्कै यही हो।
अनुमति सूची कहाँ तय हुन्छ
असफल हुँदै गरेको मार्गसँग मिल्ने नियम पढ्नुहोस्, तपाईंले बनाएको भनी सम्झिएको नियम होइन। त्यसको दायरा, पोर्ट, प्रोटोकल र कुनै पनि पहिचान जाँच अघि यसको मूल्याङ्कन हुन्छ कि भन्ने कुरा नोट गर्नुहोस्।
त्यसपछि कुन तहले यो निर्णयको वैध स्वामित्व राख्छ भन्ने तय गर्नुहोस्। ठेगानाको नियमले ट्राफिक कहाँबाट आउँछ भन्ने जवाफ दिन्छ। निजी इन्डपोइन्टले सेवा निजी मार्गबाट पुग्न सकिन्छ कि भन्ने जवाफ दिन्छ। स्प्लिट-टनेल अपवादले कुन गन्तव्यहरूले टनेल बाइपास गर्छन् भन्ने जवाफ दिन्छ। यी अदलबदल गर्न मिल्दैन, र टनेल बदलिँदा प्रत्येक फरक तरिकाले असफल हुन्छ।
तीन मर्मत, तीन तह
तलको प्रत्येक विकल्पले फरक कारणले प्रवाह सुधार्छ, र गलत छान्दा अर्को गेटवे परिवर्तनसम्म काम गर्ने जडान बन्छ।
| Repair | Layer it changes | What it does not fix |
|---|---|---|
| Add the egress address to the rule | Source address matching | Nothing about routing, and it breaks when the egress moves |
| Use a private endpoint | Whether the service is reached privately | A client that still resolves the public name |
| Add a split-tunnel exception | Which flows bypass the tunnel | An expired credential or a wrong password |
आउटबाउन्ड ठेगाना थप्नु सबैभन्दा सानो परिवर्तन र सबैभन्दा कमजोर हो, किनकि नयाँ गेटवे वा फरक क्षेत्रले यसलाई चुपचाप अमान्य बनाउँछ। टनेलको परिभाषाको छेउमा ठेगाना अभिलेख गर्नुहोस् ताकि दुवै सँगै चलून्। अस्थायी फराकिलो दायरा निदान हो, मर्मत होइन; यसलाई यथावत् राख्नु नै आन्तरिक सेवाहरू खुला रहने बाटो हो।
व्यवस्थित प्लेटफर्म किन टनेलमा सामेल हुन सक्दैन
Heroku, AppHarbor वा CloudBees जस्ता अनुप्रयोग प्लेटफर्महरूले तपाईंको कोड tun वा tap यन्त्र नभएको र त्यो बनाउने अधिकार पनि नभएको वातावरणमा चलाउँछन्। तिनीहरूको इनबाउन्ड मोडेल HTTP हो, कुनै पनि सुन्ने सकेट होइन। VPN बाइनरी बोक्ने buildpack ले पनि इन्टरफेस राख्ने ठाउँ पाउँदैन। काम गर्ने ढाँचाहरू हुन् डेटाबेसले अनुमति दिन सक्ने स्थिर आउटबाउन्ड ठेगाना, प्लेटफर्मले दिने निजी जडान उत्पादन, वा DMZ मा रहेको HTTPS बाट पुगिने प्रोक्सी।
त्यो प्रोक्सी आफ्नै प्रमाणीकरण र लगिङ भएको पहुँच मार्ग हो। यसले प्लेटफर्मलाई तपाईंको VPN को सदस्य बनाउँदैन, र यसरी वर्णन गर्दा कसैले पनि लेखापरीक्षण गर्न नसक्ने नियमहरू बन्छन्।
असफल भएको क्लाइन्टबाट प्रमाणित गर्नुहोस्
फेरि जोडिनुहोस् र क्लाइन्टको ठ्याक्कै मार्ग दोहोर्याउनुहोस्। सेवाले अभिलेख गर्ने स्रोत ठेगाना, डेटाबेसको नामका लागि क्लाइन्टले छान्ने रुट, र वास्तविक क्वेरीको नतिजा यही क्रममा जाँच्नुहोस्। गेटवेबाट गरिएको परीक्षणले गेटवे काम गर्छ भन्ने प्रमाणित गर्छ, जुन कहिल्यै शंकामा थिएन। यदि जडान अब प्रमाणित हुन्छ र क्वेरी अझै असफल हुन्छ भने, बाँकी समस्या डेटाबेस अनुमति हो।
टनेल बदलिएपछि हरेक पटक यी नियमहरू समीक्षा गर्नुहोस्। बदलिएको गेटवे वा नयाँ आउटबाउन्ड दायराले अनुप्रयोग कन्फिगरेसनमा कुनै पनि परिवर्तन नगरी मार्ग तोड्छ।