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 चा सदस्य बनवत नाही, आणि असे वर्णन केल्यास कोणीही लेखापरीक्षण करू शकत नाही असे नियम तयार होतात।
अयशस्वी झालेल्या क्लायंटवरून पडताळणी करा
पुन्हा जोडा आणि क्लायंटचा नेमका मार्ग पुन्हा करा। सेवा जो स्रोत पत्ता नोंदवते, क्लायंट डेटाबेस नावासाठी जो रूट निवडतो, आणि प्रत्यक्ष क्वेरीचा निकाल याच क्रमाने तपासा। गेटवेवरून केलेली चाचणी गेटवे काम करते हे सिद्ध करते, जे कधीच शंकेचे नव्हते। जोडणी आता प्रमाणित होत असेल आणि क्वेरी अजूनही अयशस्वी होत असेल, तर उरलेली समस्या डेटाबेस परवानगी आहे।
टनेल बदलल्यावर प्रत्येक वेळी हे नियम तपासा। बदललेला गेटवे किंवा नवीन आउटबाउंड श्रेणी अनुप्रयोग संरचनेत कोणताही बदल न करता मार्ग तोडते।