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 बाइनरी ले जाने वाला बिल्डपैक भी इंटरफ़ेस रखने की जगह नहीं पाता। व्यवहार्य तरीके हैं वह स्थिर आउटबाउंड पता जिसकी डेटाबेस अनुमति दे सके, प्लेटफ़ॉर्म द्वारा दिया गया निजी कनेक्शन उत्पाद, या DMZ में रखी प्रॉक्सी जहाँ HTTPS से पहुँचा जाए।
वह प्रॉक्सी अपने स्वयं के प्रमाणीकरण और लॉगिंग वाला पहुँच मार्ग है। यह प्लेटफ़ॉर्म को आपके VPN का सदस्य नहीं बनाता, और उसे ऐसे वर्णित करने से ऐसे नियम बनते हैं जिनका कोई अंकेक्षण नहीं कर सकता।
उस क्लाइंट से सत्यापित करें जो विफल हुआ
फिर से जुड़ें और क्लाइंट का ठीक वही मार्ग दोहराएँ। सेवा जो स्रोत पता दर्ज करती है, क्लाइंट जो रूट डेटाबेस के नाम के लिए चुनता है, और वास्तविक क्वेरी का परिणाम, इसी क्रम में जाँचें। गेटवे से किया गया परीक्षण सिद्ध करता है कि गेटवे काम करता है, जो कभी संदेह में नहीं था। यदि कनेक्शन अब प्रमाणित होता है और क्वेरी फिर भी विफल होती है, तो शेष समस्या डेटाबेस अनुमति है।
जब भी टनल बदले, इन नियमों की समीक्षा करें। बदला गया गेटवे या नई आउटबाउंड श्रेणी एप्लिकेशन कॉन्फ़िगरेशन में किसी भी बदलाव के बिना मार्ग तोड़ देती है।