एउटा निजी सेवा सुरुङबाट लोड हुन्छ र अर्को समय सकिएर रोकिन्छ, अनि पूरै क्लाइन्ट प्रोफाइल फेरि बनाउने लोभ लाग्छ। काम गरिरहेको सेवा सुरुदेखि फेरि सुरु गर्ने कारणभन्दा नियन्त्रणका रूपमा बढी उपयोगी हुन्छ। यसले एउटा गन्तव्य, एउटा पोर्ट र एउटा अधिकार मार्ग पूरा भएको मात्र प्रमाणित गर्छ, त्यसभन्दा बढी केही होइन।

एउटै गेटवेमा रहेका दुई सेवामा फरक ठेगाना परिवार, फरक सबनेट र फरक नीतिबाट पुग्न सकिन्छ।

काम गर्ने प्रवाहलाई असफल प्रवाहबाट अलग गर्नुहोस्

प्रत्येक सेवालाई VPN को लक्षण नभई आफ्नै प्रवाहका रूपमा लिनुहोस्। एउटा उदाहरणीय क्लाइन्टले portal.corp.example लाई 172.20.4.15:443 मा खोल्न सक्छ र तैपनि 172.20.9.40:5432 मा रहेको डेटाबेसमा पुग्न असफल हुन सक्छ, किनकि ती दुई नियमसमूह भएका दुई गन्तव्य हुन्। केही बदल्नुअघि पोर्ट र प्रोटोकल सहित दुवै पङ्क्ति लेख्नुहोस्, किनकि होस्टमा TCP 443 लाई अनुमति दिने नियमले त्यही होस्टको TCP 5432 बारे केही भन्दैन।

जाँच गर्नुपर्ने पङ्क्ति असफल पङ्क्ति हो। काम गर्ने पङ्क्तिले आधाररेखा कहाँ छ भन्ने मात्र बताउँछ, र हरेक परिवर्तनपछि त्यही तुलनाको बिन्दु हुनेछ।

नामको तुलना गर्नुअघि ठेगानाको तुलना गर्नुहोस्

प्रत्येक पूरा नामलाई एप्लिकेसनले वास्तवमा प्रयोग गर्ने नीतिबाट समाधान गर्नुहोस्, त्यसपछि छानिएको ठेगाना परिवार अभिलेख गर्नुहोस्। एउटा नामले IPv6 ठेगाना फर्काउन सक्छ भने अर्कोले IPv4, र पुरानो क्यास गरिएको उत्तरले निजी सेवासँग कुनै सम्बन्ध नभएको सार्वजनिक ठेगानामा अनुरोध पठाउन सक्छ।

ip route get 172.20.4.15
ip route get 172.20.9.40
ip -6 route get 2001:db8:60::20

वर्तमान तालिका र नीति नियमका आधारमा यो होस्टले त्यो गन्तव्यका लागि कुन मार्ग छान्छ भन्ने साँघुरो प्रश्नको उत्तर खोजले दिन्छ। 172.20.4.0/24 का लागि मार्गले 172.20.9.0/24 समेट्दैन, र दोस्रो सञ्जाल प्रबन्धक वा राम्रो विशिष्टता भएको स्थानीय मार्गले सुरुङलाई चुपचाप अतिक्रमण गर्न सक्छ। जब ती तपाईंको शेलभन्दा फरक हुन्छन्, नामस्थानभित्र वा एप्लिकेसनले प्रयोग गर्ने चिन्हसहित खोज दोहोर्याउनुहोस्। प्याकेट जुन इन्टरफेसबाट बाहिरिन्छ त्यो पनि अभिलेख गर्नुहोस्, किनकि मार्ग तालिकाले एउटा इन्टरफेस भन्न सक्छ तर नीति-आधारित राउटिङले प्रवाह अर्कोबाट बाहिर पठाउन सक्छ।

मिल्ने मार्ग आवश्यक सर्त हो, अनुमति होइन। प्याकेटलाई जाने ठाउँ छ भन्ने मात्र बताउँछ, र फायरवाल, अधिकार सेवा वा होस्ट आफैंले स्वीकार गर्छ कि भन्नेबारे केही भन्दैन।

प्रोटोकल र प्रतिक्रियाको चरणले कहाँ रोकिन्छ भन्ने बताउँछ

ping को उत्तरले डेटाबेस पोर्ट खुला छ भनी प्रमाणित गर्दैन, र सफल HTTPS पृष्ठले उही मेसिनमा फाइल साझेदारीलाई अधिकृत गर्दैन। हरेक असफलतालाई एउटै वर्गमा समथर बनाउनुको सट्टा वास्तवमा के फर्कियो अभिलेख गर्नुहोस्। समय सकिने, रिसेट, TLS पहिचान त्रुटि र एप्लिकेसन-स्तरीय अस्वीकृति प्रत्येकले फरक तहतर्फ सङ्केत गर्छ।

भिन्नता महत्त्वपूर्ण छ किनकि सुधारहरू फरक दिशातिर जान्छन्। मौनता सामान्यतया मार्ग, फायरवाल वा बाटोमा अनुवादको समस्या जनाउँछ। तत्काल रिसेटले केही होस्टसम्म पुग्यो र पोर्ट अस्वीकार गर्‍यो भन्ने सुझाउँछ। प्रमाणपत्र त्रुटि भनेको जडान आयो र नाम मिलेन, जुन कन्फिगरेसनको समस्या हो, पहुँचको होइन। एप्लिकेसनको अस्वीकृति भनेको सञ्जालले आफ्नो काम गर्‍यो र पहिचान पछि अस्वीकार भयो।

जब स्रोत गेटवेमार्फत प्रकाशित हुन्छ, गन्तव्यले देख्ने स्रोत ठेगानालाई तपाईंको क्लाइन्टले प्रयोग गर्छ भन्ने ठान्ने स्रोतसँग तुलना गर्नुहोस्। गेटवे आफैंबाट सुरु भएको अनुरोध सफल हुन सक्छ तर क्लाइन्टबाट त्यही अनुरोध असफल हुन्छ, किनकि दुवै फरक ठेगानाबाट आउँछन् र फरक नियमसँग भेट्छन्।

एउटा चल बदल्नुहोस् र दुवै अनुरोध फेरि चलाउनुहोस्

पहिचान मानिसहरूले सबैभन्दा पछि हेर्ने ठाउँ हो र सही अस्वीकृति सबैभन्दा पहिले देखिने ठाउँ हो। VPN लगइन, डाइरेक्टरी समूह र एप्लिकेसन खाता तीन फरक पहिचान हुन् जो फरक पर्न सक्छन्। पोर्टलमा पहुँचले कहिल्यै त्यसपछाडिको डेटाबेसमा पहुँच जनाउँदैन, र एउटा डाइरेक्टरीको नामले अर्कोमा पङ्क्ति बनाउँदैन। यदि सेवा प्रयोगकर्ताको अभिप्रेत दायराबाहिर छ भने, त्यो अस्वीकृति प्रणाली काम गरिरहेको सङ्केत हो।

फराकिलो मार्ग थप्ने वा परीक्षणका रूपमा समूह खोल्ने सट्टा स्रोतको मालिकलाई अभिप्रेत हकको पुष्टि गर्न भन्नुहोस्। कुरा प्रमाणित गर्न सञ्जाल फराकिलो बनाउनु नै अस्थायी निदान स्थायी जोखिममा बदलिने बाटो हो, र यसले तपाईंले सुरु गरेको नियन्त्रण नष्ट गर्छ। हरेक पुनरावृत्तिमा एउटा देखाइएको असंगति पर्याप्त छ: छुटेको मार्ग, गलत ठेगाना परिवार, अवरुद्ध पोर्ट वा नभएको समूह सदस्यता।

हरेक परिवर्तनपछि दुवै अनुरोध दोहोर्याउनुहोस् र नतिजा सँगसँगै राख्नुहोस्। असफल सेवा आफ्नै नीतिअन्तर्गत काम गर्छ र काम गर्ने सेवा तथा तपाईंले अझै अपेक्षा गरेका अस्वीकारहरू पहिलेजस्तै व्यवहार गर्छन् भने जाँच सकिन्छ।

सम्बन्धित लेखहरू