OpenVPN रुट निर्देशनमा वाइल्डकार्ड किन काम गर्न सक्दैन

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

रुटले के स्थापना गर्छ, र के कहिल्यै पढ्दैन

रुट प्रविष्टिले भन्छ कि गन्तव्य उपसर्ग इन्टरफेसबाट पुग्न सकिने छ। कर्नेलले प्याकेटहरूलाई ती उपसर्गसँग मिलाउँछ, त्यसैले संलग्न एकमात्र पहिचानकर्ता ठेगाना र मास्क हुन्। होस्टनाम कहिल्यै फर्वार्डिङ निर्णयमा आउँदैन, र त्यसैले त्यहाँ कुनै ढाँचा मिलाउन सकिँदैन।

OpenVPN ले केही रुट प्यारामिटरमा समाधान गर्न सकिने नाम स्वीकार गर्न सक्छ, र त्यो सहिष्णुता भ्रमको स्रोत हो। कन्फिगरेसन लागू हुँदा नाम समाधान हुन्छ, जसले सामान्य रुट बन्ने एक वा बढी ठेगाना उत्पादन गर्छ। त्यसपछि, नाम चित्रबाट पूर्ण रूपमा हराउँछ।

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

जब गन्तव्य साँच्चै उपसर्ग हुन्छ

यदि लक्ष्य ज्ञात निजी सञ्जाल हो भने, उपसर्ग लेख्नुहोस्। अभिलेखन ठाउँको उदाहरणका लागि, एउटा होस्ट र एउटा सबनेट यस्तो देखिन्छ:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

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

एउटा DNS उत्तरबाट ठूलो उपसर्ग अनुमान नगर्नुहोस्। एउटा ठेगानामा समाधान हुने एउटा होस्टनामले त्यसको पछाडिको सञ्जालको आकारबारे तपाईंलाई केही भन्दैन, र अनुमानित उपसर्ग नै त्यो बाटो हो जसले सुरुङ अन्ततः कसैले त्यसबाट पठाउन नचाहेको ट्राफिक समात्छ। खोजबाट अनुमान गर्नुको सट्टा सञ्जालको मालिकलाई वास्तविक उपसर्ग सोध्नुहोस्।

जब कामको एकाइ होस्टनाम हुन्छ

डोमेनअनुसार छनोट गर्न डोमेन पढ्ने कुनै कुरा चाहिन्छ, अर्थात् अनुप्रयोग-तहको घटक। सामान्य उत्तर सुरुङको अर्को छेउमा बस्ने HTTP प्रोक्सी हो, र क्लाइन्टले कुन अनुरोध त्यसमा पठाउने भनी छनोट गर्छ।

प्रोक्सी कन्फिगरेसन फाइलले त्यो छनोट व्यक्त गर्न सक्छ। तलका उदाहरण नियमहरूले एउटा डोमेन र त्यसका सबडोमेनहरू प्रोक्सीमा र बाँकी सबै सिधै पठाउँछन्:

function FindProxyForURL(url, host) {
    var h = host.toLowerCase();
    if (h === "corp.example" || dnsDomainIs(h, ".corp.example")) {
        return "PROXY 10.60.0.12:3128";
    }
    return "DIRECT";
}

ठ्याक्कै-नाम तुलनाले डोमेनलाई नै समेट्छ, र प्रत्यय तुलनाले त्यसका सन्तानहरूलाई समेट्छ तर मात्र समान अक्षरमा अन्त्य हुने नामसँग मिल्दैन। दुवै आवश्यक छन्, र एउटा छाड्दा सही देखिने तर शिखर वा बनावटीलाई छुटाउने नियम बन्छ।

यी नियमहरूले प्रोक्सी छान्छन्; तिनीहरूले त्यो बनाउँदैनन्, र अपरेटिङ सिस्टमको कुनै पनि रुट बदल्दैनन्। प्रोक्सी ठेगानालाई अझै सुरुङबाट आफ्नै बाटो चाहिन्छ, र सिधै भनी चिन्ह लगाइएका अनुरोधहरू मेसिनसँग पहिले नै भएको राउटिङ नीति अनुसरण गर्छन्।

प्रोक्सी विकल्पले के समेट्दैन

ब्राउजरको प्रोक्सी कन्फिगरेसन बेवास्ता गर्ने प्रोग्रामहरूमा यसमध्ये केहीले पनि असर गर्दैन। कमाण्ड-लाइन उपकरण, अपडेटर र आफ्नै सञ्जाल स्ट्याक भएका एप्लिकेसनहरूले PAC फाइल होइन, रुट तालिका लिन्छन्, त्यसैले ती अवस्थाहरूलाई समर्थित प्रत्येक एप्लिकेसनको संयन्त्र वा फरक डिजाइन चाहिन्छ। ब्राउजर नियमले कार्यप्रवाह समेट्छ भनी वाचा गर्नुअघि महत्त्वपूर्ण क्लाइन्टको सूची बनाउनुहोस्।

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

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

दुवै बाटोको परीक्षण, मात्र सुखद बाटोको होइन

मिल्नुपर्ने होस्टनाम, नमिल्नुपर्ने होस्टनाम, र डोमेनको शिखर परीक्षण गर्नुहोस्, किनभने मात्र-प्रत्यय नियमले सबैभन्दा धेरै छुटाउने अवस्था शिखर नै हो। त्यसपछि पृष्ठ लोड भयो कि भएनबाट अनुमान गर्नुको सट्टा प्रत्येक अनुरोधले वास्तवमा कुन बाटो लियो भनी पुष्टि गर्नुहोस्।

अन्तमा, असफलता शाखाको परीक्षण गर्नुहोस्। पुग्न नसकिने प्रोक्सीले तपाईंले पहिले नै निर्णय गरेको तरिकाले असफल हुनुपर्छ, चुपचाप सिधा जडानमा फर्किनु हुँदैन। सञ्जाल विकल्पको सन्दर्भ ले रुट प्यारामिटरहरू सटीक रूपमा अभिलेख गर्छ; यो डिजाइनको डोमेन आधा भाग पूर्ण रूपमा त्यसको बाहिर छ।