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