व्यावसायिक VPN पोर्ट 5432 अडवते का? तुमचे पर्याय तुलना करा

अ‍ॅप्लिकेशन दररोज कार्यालयातून त्याच्या डेटाबेसशी बोलत असे. नंतर कोणी त्याच लॅपटॉपवर व्यावसायिक VPN क्लायंट सुरू केला, आणि हँडशेकनंतर कनेक्शन रीसेट होऊ लागले. अ‍ॅप्लिकेशनमध्ये काहीही बदलले नाही, टनेल स्वतःला निरोगी घोषित करते, आणि तुम्ही नियंत्रित करता त्या फायरवॉलमध्ये कोणताही अडवण्याचा नियम नाही. बदलले ते एक्झिट मार्ग: प्रदात्याचे सर्व्हर सामायिक, उच्च-ट्रॅफिक एंडपॉइंट आहेत, आणि प्रदाते गैरवापर कमी करण्यासाठी आउटबाउंड पोर्ट फिल्टर करतात. डेटाबेस आणि मेल सबमिशन पोर्टना याचा सर्वात मोठा वाटा मिळतो, कारण अनामिक पत्ता पूलमधून स्कॅनिंग आणि स्पॅम आकर्षित करणारे हेच पोर्ट आहेत.

फिल्टरिंगला बाकी सर्वांपासून वेगळे करणारी पाच मिनिटांची चाचणी

त्याच मशीनवरून, उघडे असायला हवे असलेले एक पोर्ट आणि अयशस्वी होणारा पोर्ट, त्याच होस्टवर, टनेल सुरू आणि नंतर बंद ठेवून तपासा. दोन्ही वेळा तोच कमांड वापरा जेणेकरून एकमेव चल टनेल असेल:

Test-NetConnection db.example.com -Port 443
Test-NetConnection db.example.com -Port 5432
nc -vz -w3 db.example.com 5432

चार निकाल जवळजवळ प्रत्येक प्रकरण व्यापतात. जर 443 चालत असेल आणि 5432 फक्त टनेल सुरू असताना अयशस्वी होत असेल, तर तुम्ही एक्झिट मार्गावरील पोर्ट फिल्टरिंग पाहत आहात. जर टनेल सुरू असताना दोन्ही अयशस्वी होत असतील आणि ताशिवाय दोन्ही चालत असतील, तर समस्या पोर्ट धोरणात नाही, राउटिंग किंवा DNS मध्ये आहे. जर दोन्ही पोर्ट जोडले गेले पण अ‍ॅप्लिकेशन अजूनही अयशस्वी होत असेल, तर दोष पोहोचण्याचा नाही, प्रमाणीकरण किंवा TLS चा आहे. आणि जर प्रदात्याचे फक्त एक सर्व्हर स्थान अयशस्वी होत असेल, तर ते प्रति-सर्व्हर धोरण आहे, म्हणून कोणतेही कॉन्फिगरेशन हाताळण्यापूर्वी दुसरे स्थान वापरून पाहा.

पर्याय एक: डेटाबेस सबनेटसाठी स्प्लिट टनेल

जर लॅपटॉपला व्यावसायिक VPN फक्त इतर हेतूंसाठी हवे असेल, तर डेटाबेसची पत्ता श्रेणी टनेलमधून वगळा जेणेकरून रहदारी कधीही सामायिक एक्झिटमध्ये प्रवेश करणार नाही. जेव्हा दोन्ही मार्गांना खरोखर भेटण्याची गरज नसते तेव्हा हा सर्वात स्वच्छ पर्याय आहे, आणि तुम्ही दस्तऐवजीकरण करू शकता अशा राउटिंग नियमापलीकडे त्याचा कोणताही खर्च नाही. व्यवहार असा आहे की स्प्लिट टनेलिंग दुसरे धोरण पृष्ठभाग आणते: टनेलमधून जे वगळले जाते ते हेतुपूर्वक असावे, नंतर कोणी जोडलेल्या सबनेटचा दुष्परिणाम नाही.

ज्या क्षणी डेटाबेस VPN ला पोहोचायचे त्या नेटवर्कच्या आत राहतो, तेव्हा ते काम करणे थांबवते, म्हणून यासाठी वचनबद्ध होण्यापूर्वी ते तपासा.

पर्याय दोन: तुमचा स्वतःचा एंडपॉइंट, तुमचा स्वतःचा इग्रेस

VPS वर छोटा VPN एंडपॉइंट चालवल्याने इग्रेस धोरणाचे नियंत्रण तुमच्या हातात येते, आणि कोणताही सामायिक पूल सहभागी होत नाही. व्यावसायिक क्लायंटशी प्रामाणिकपणे तुलना करण्यासारखा पर्याय हा आहे: तुम्हाला अंदाज करण्यायोग्य स्रोत पत्ता मिळतो आणि प्रदात्याचे जागतिक पाऊल आणि सोय गमावते. ज्या संघाला दिवसभर डेटाबेस आणि मेल पोर्ट लागतात, त्यांच्यासाठी व्यवहार सहसा एंडपॉइंटच्या मालकीच्या बाजूने जातो, कारण अयशस्वी होण्याची पद्धत दुसऱ्या कोणाचे गैरवापर धोरण नाही, तुमची स्वतःची चुकीची कॉन्फिगरेशन होते.

स्रोत पत्त्याची स्थिरता, तुमची रहदारी कोण वाचू शकतो, आणि एंडपॉइंटचा प्रदाता ज्या दिवशी स्वतःचे फिल्टरिंग बदलतो त्या दिवशी काय होते या तीन गोष्टींवर दोन्हींची तुलना करा.

पर्याय तीन: लॅपटॉप मार्गातून बाहेर काढा

CI काम, नियोजित कंटेनर, किंवा परवानगी असलेल्या नेटवर्कमधील बास्टियन होस्ट माणसाच्या टनेल स्थितीवर अवलंबून नसतो. आधीच परवानगी असलेल्या होस्टवरून SSH टनेलद्वारे डेटाबेसपर्यंत पोहोचा, आणि लॅपटॉप कधीही पोर्टशी थेट बोलत नाही. अनेक लोक एकाच मर्यादेला भिडल्यावर हा पर्याय स्केल होतो, आणि समस्या टाळण्याऐवजी दूर करतो.

हे स्प्लिट-टनेल नियमापेक्षा जास्त आगाऊ काम मागते, आणि आत्ताच संवादात्मक सत्र हवे असलेल्या एका व्यक्तीला ते मदत करत नाही.

प्रदात्याचा पत्ता परवानगी सूचीत टाकणे हे चुकीचे तुलन का आहे

डेटाबेस परवानगी सूचीत प्रदात्याचा एक्झिट पत्ता जोडणे काम करते, आणि त्या क्षणी तो पत्ता सामायिक करणाऱ्या इतर प्रत्येक ग्राहकालाही प्रवेश देते. अरुंदपणे दिलेल्या अ‍ॅप्लिकेशन खात्यामागील फक्त-वाचन प्रतिकृतीसाठी, एका दिवसासाठी उघडकी सहनशील असू शकते. लिहिता येणाऱ्या कोणत्याही गोष्टीसाठी हा नाव देण्यासारखा व्यवहार नाही, आणि फिरणारे एक्झिट पत्ते ते अधिक बिघडवतात: प्रत्येक सर्व्हर बदल नियम मोडतो, आणि देखभाल परवानगी सूचीचा उद्देश नष्ट करणाऱ्या रुंद CIDR नोंदींना आमंत्रण देते.

समर्पित किंवा स्थिर पत्ते, जिथे प्रदाता ते विकतो, हा याचा स्केल होणारा एकमेव प्रकार आहे. परवानगी सूची फक्त तुमच्या हक्काच्या पत्त्याशी जोडा, किंवा अजिबात जोडू नका.

तुम्ही जे निवडाल ते, मार्ग आणि कारण लिहून ठेवा. पुढील व्यक्ती त्याच रीसेट होणाऱ्या कनेक्शनला भेटेल आणि अ‍ॅप्लिकेशनला दोष देऊ लागेल.