राउटर VPN नियम: स्रोत और गंतव्य का मेल बैठाएँ
राउटर पर एक VPN नियम के दो सिरे होते हैं: वह डिवाइस जो ट्रैफ़िक भेजता है और वह गंतव्य जिसे टनल का उपयोग करना चाहिए। पहले प्रतिच्छेद और फ़ॉलबैक तय करें।
राउटर खरीदने के पेज VPN रूटिंग को एक चेकबॉक्स के रूप में दिखाते हैं, और यह वाक्यांश तीन अलग सवाल छिपाता है। क्या नियम उस डिवाइस से मेल खाता है जो ट्रैफ़िक भेजता है, उस सर्वर से जो उसे प्राप्त करता है, या दोनों से? जो ट्रैफ़िक किसी से भी मेल नहीं खाता उसका क्या होता है? और जब दो नियम ओवरलैप करते हैं, तो कौन जीतता है? जवाब को स्रोत और गंतव्य की जोड़ी के रूप में लिखना एक अस्पष्ट फ़ीचर-सूची को परीक्षण-योग्य डिज़ाइन में बदल देता है।
फ़ीचर का नाम दो सिरे छिपाता है
जो मीडिया प्लेयर टनल का उपयोग करना चाहिए वह स्रोत-मेल है। जो निजी ऑफ़िस प्रीफ़िक्स टनल से पहुँचा जाना चाहिए वह गंतव्य-मेल है। जो वर्कस्टेशन टनल का उपयोग केवल एक सेवा के लिए करना चाहिए वह दोनों है, और वही प्रतिच्छेद वह स्थिति जिसे ज़्यादातर उपभोक्ता फ़र्मवेयर बुरी तरह संभालता है है।
उत्पादों की तुलना करने से पहले आवश्यकता को जोड़ी के रूप में लिखें। यही जोड़ी आप बाद में परखेंगे।
जो उत्पाद डिवाइस-सूची या वैश्विक गंतव्य-सूची देता है वह शायद «केवल यह डिवाइस, केवल ये गंतव्य» नहीं कह सकता। यह अंतर दिखावटी नहीं है: वैश्विक गंतव्य-नियम उस साइट के लिए हर डिवाइस का ट्रैफ़िक टनल से भेजता है, और डिवाइस-नियम उस डिवाइस का सारा ट्रैफ़िक भेजता है। दोनों में से कोई आवश्यकता नहीं है। स्क्रीन पर भरोसा करने से पहले वह स्थिति दो डिवाइसों से परखें।
नियम को प्रतिच्छेद के रूप में बनाएँ
एक तालिका डिज़ाइन को ईमानदार रखती है। परिदृश्य को बाईं ओर रखें, फिर प्रेषक-मेल और लक्ष्य-मेल को अलग-अलग नाम दें:
| Scenario | Sender match | Target match | Rule shape |
|---|---|---|---|
| Media player uses the tunnel | Player address | Any internet destination except the LAN | Source only |
| Office prefix reachable | Authorized LAN devices | 10.40.0.0/16 | Target only |
| One app on one laptop | Laptop address | The service address set | Source and target |
| Guest network never tunnels | Guest subnet | Any | Deny, 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 फ़ॉरवर्डिंग, अपडेट-जाँच और निगरानी डिवाइस के स्रोत-मेल को विरासत में लेने के बजाय राउटर से ही नए प्रवाह शुरू कर सकते हैं। उन प्रवाहों को स्पष्ट रूप से गिनें, वरना वे लॉग में अस्पष्ट लीक के रूप में दिखेंगे।