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

सुविधाको नामले दुई छेउ लुकाउँछ

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

उत्पादनहरू तुलना गर्नुअघि आवश्यकता जोडीका रूपमा लेख्नुहोस्। त्यही जोडी पछि तपाईंले परीक्षण गर्नुहुनेछ।

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

नियमलाई प्रतिच्छेदनका रूपमा बनाउनुहोस्

तालिकाले डिजाइनलाई इमानदार राख्छ। परिदृश्य बायाँतिर राख्नुहोस्, त्यसपछि प्रेषक-मिलान र लक्ष्य-मिलान अलग-अलग नाम दिनुहोस्:

ScenarioSender matchTarget matchRule shape
Media player uses the tunnelPlayer addressAny internet destination except the LANSource only
Office prefix reachableAuthorized LAN devices10.40.0.0/16Target only
One app on one laptopLaptop addressThe service address setSource and target
Guest network never tunnelsGuest subnetAnyDeny, evaluated first

तेस्रो पङ्क्ति रोचक छ, किनकि यसलाई दुवै आधा एकैचोटि चाहिन्छ। यदि फर्मवेयरले एउटा मात्र अक्ष व्यक्त गर्न सक्छ भने आवश्यकता दुई नियममा बाँड्नुपर्छ वा त्यो गर्न सक्ने यन्त्रमा सार्नुपर्छ।

स्रोतको पहिचान स्थिर राख्नुहोस्। DHCP आरक्षण, समर्पित खण्ड वा यन्त्र-पहिचान संयन्त्र सबै काम गर्छन्, तर लिज सकिएपछि बदलिने ठेगानाले काम गर्दैन। IPv6 समावेश गर्नुहोस्, किनकि एउटा IPv4 ठेगानाले यन्त्रको सबै ट्राफिक चिन्न सक्दैन।

प्राथमिकताले ओभरल्याप तय गर्छ

नियमहरू ओभरल्याप हुनु सामान्य हो। फराकिलो यन्त्र-नियम र साँघुरो गन्तव्य-नियम दुवैले एउटै प्रवाह वर्णन गर्न सक्छन्, र अभिलेखित प्राथमिकता-क्रमले कुन जित्छ तय गर्छ। आकर्षक सेटिङ स्क्रिनले तपाईंलाई त्यो क्रम बताउँदैन।

क्रम र नमिल्ने अवस्थाका लागि पुस्तिका पढ्नुहोस्, त्यसपछि तपाईंले देख्न सक्ने ट्राफिकले दुवै परीक्षण गर्नुहोस्:

ip rule show
ip route get 203.0.113.10

यदि अभिलेखले क्रम बताउँदैन भने साँघुरो नियमले नजित्न सक्ने मानेर त्यसैअनुसार डिजाइन गर्नुहोस्। जो दुई नियम बाझिन सक्दैनन् तिनलाई समर्थन गर्नु, प्राथमिकता अलिखित भएको एउटा चतुर नियमभन्दा सजिलो छ।

नामलाई रिफ्रेस नीति चाहिन्छ

डोमेनका रूपमा लेखिएको गन्तव्यले मर्मतको समस्या थप्छ। राउटरले त्यसलाई समाधान गर्नुपर्छ, म्यापिङ रिफ्रेस गर्नुपर्छ, धेरै ठेगाना र उपडोमेन सम्हाल्नुपर्छ, र अपेक्षित रिजोल्भरलाई छलेर जाने अनुप्रयोग DNS सामना गर्नुपर्छ।

एउटा खोज-नतिजा IP नियममा प्रतिलिपि गर्नु स्न्यापसट हो, डोमेन नीति होइन।

नियम गलत हुनुअघि उत्तर कति पुरानो हुन सक्छ, र रिजोल्युसन असफल हुँदा राउटरले के गर्छ तय गर्नुहोस्। अन्तिम ज्ञात ठेगाना राख्ने नियम सेवा-स्थानान्तरणपछि पनि टिक्न सक्छ; प्रविष्टि फ्याँक्ने नियमले सुरुङिङ चुपचाप रोक्न सक्छ। दुवै व्यवहार स्वीकार्य छन् यदि ती नियमको छेउमा लेखिएका छन्।

अनुपलब्ध अवस्था परिभाषित गर्नुहोस्

मार्ग प्राथमिकताले VPN-मात्र ट्राफिक लागू गर्दैन। सुरुङ बन्द हुँदा राउटरले प्रवाह रोक्न सक्छ, सिधै पठाउन सक्छ वा अर्को सुरुङ प्रयोग गर्न सक्छ, र हरेक विकल्पको असफलता-चिन्ह फरक हुन्छ।

आवश्यकतालाई कुन चाहिन्छ तय गर्नुहोस्, त्यसपछि सुरुङ रोकेर र प्रवाह हेरेर त्यसलाई प्रमाणित गर्नुहोस्:

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://service.example/
ping -c 2 203.0.113.10

राउटरबाटै उत्पन्न हुने ट्राफिक छुट्टै क्षेत्र हो। DNS फर्वार्डिङ, अद्यावधिक जाँच र अनुगमनले यन्त्रको स्रोत-मिलान उत्तराधिकार नलिई राउटरबाटै नयाँ प्रवाह सुरु गर्न सक्छन्। ती प्रवाहलाई स्पष्ट रूपमा हिसाब गर्नुहोस्, नत्र ती लगमा अस्पष्ट चुहावटका रूपमा देखिनेछन्।

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