एक डिवाइस के लिए राउटर VPN को तीन नियम चाहिए, टॉगल नहीं

राउटर VPN पर हर डिवाइस के लिए कोई स्विच नहीं होता; आप जिस टॉगल की तलाश कर रहे हैं वह एक शॉर्टकट है जो आपकी ओर से नीति-आधारित राउटिंग नियम लिखता है। जिस पल एक लैपटॉप, एक पोर्ट रेंज, एक पता सूची या एक LAN सेगमेंट को टनल से जाना पड़ता है जबकि बाकी सब WAN पर रहता है, आप सुविधा चालू नहीं कर रहे बल्कि एक नीति मार्ग बना रहे हैं। काम के तीन चलते हिस्से हैं, और हर एक अलग तरह से विफल होता है: मार्ग के बिना चिह्नित तालिका चुप्पी जैसी दिखती है, गलत चेन में लगाया गया चिह्न ऐसा लगता है जैसे कुछ हुआ ही नहीं, और छूटा हुआ NAT नियम ऐसी टनल जैसा दिखता है जो जुड़ती है और कुछ नहीं ढोती। दो और हिस्से छूट जाते हैं क्योंकि वे कभी mangle नियम में नहीं आते, और वे DNS तथा IPv6 हैं।

मिथक: टनल क्लाइंट की सेटिंग है

राउटर की ओर का VPN क्लाइंट एक मोटा काम अच्छी तरह करता है: वह 0.0.0.0/0 को मुख्य राउटिंग तालिका में डालता है और उसे टनल की ओर इंगित करता है। WireGuard इसे AllowedIPs से निकालता है, OpenVPN धकेले गए redirect-gateway से, और दोनों राउटर के पीछे के हर होस्ट का पथ बदल देते हैं। AllowedIPs को संकरा करना या route-nopull जोड़ना यह बदलता है कि क्लाइंट क्या इंस्टॉल करता है। इससे यह नहीं बदलता कि इंस्टॉलेशन किस पर लागू है, क्योंकि क्लाइंट कभी डिवाइस नहीं देखता। वह केवल पैकेट देखता है।

स्रोत या गंतव्य के आधार पर चयन एक राउटिंग निर्णय है, इसलिए वह राउटर की नीति परत का काम है: RouterOS पर एक mangle नियम और दूसरी तालिका, OpenWrt या DD-WRT पर MARK और ip rule, या pfSense पर ऐसा फ़ायरवॉल नियम जिसका गेटवे टनल हो। Netgate की WireGuard क्लाइंट रेसिपी वही है जिसे अनुमान लगाने से पहले पढ़ना चाहिए, क्योंकि उस प्लेटफ़ॉर्म पर नियम का गेटवे, इंटरफ़ेस आवंटन और आउटबाउंड NAT प्रविष्टि सबको सहमत होना पड़ता है ताकि एक भी क्लाइंट टनल का उपयोग करे।

मिथक का दूसरा आधा दूसरा राउटर है। दूसरा बॉक्स खरीदना या डिवाइस को अतिथि SSID पर ले जाना अक्सर काम करता है, और कारण हार्डवेयर नहीं है: यह डिवाइस को उसके अपने सबनेट पर रखता है, जो आपको वही स्रोत चयनक देता है जिसे फ़र्मवेयर पहले से समझता है। अगर आप उस सेगमेंट को अपने राउटर पर परिभाषित कर सकते हैं, तो अतिरिक्त बॉक्स ऐसी समस्या हल करता है जो आपके पास थी ही नहीं।

पहला हिस्सा: ऐसी टनल जो डिफ़ॉल्ट मार्ग नहीं है

RouterOS पर क्लाइंट को डिफ़ॉल्ट मार्ग के बिना जोड़ें और टनल को उसकी अपनी तालिका दें। पहला मार्ग चिह्नित डिफ़ॉल्ट है; दूसरा विफलता का आधा हिस्सा है।

/ip route add dst-address=0.0.0.0/0 gateway=VPN_GATEWAY_IP routing-mark=vpn distance=1
/ip route add dst-address=0.0.0.0/0 type=unreachable routing-mark=vpn distance=2

unreachable मार्ग ही वह कारण है कि चिह्नित तालिका मुख्य तालिका की अपवाद सूची को हराती है। जब टनल गिरती है, चिह्नित पैकेटों को चुपचाप WAN पर लौटने के बजाय तुरंत unreachable मिलता है, इसलिए विफलता ऐप के त्रुटि संदेश में दिखती है, एक घंटे बाद देखे जाने वाले भू-स्थान पृष्ठ पर नहीं।

RouterOS 7 उसे अलग करता है जिसे 6.x साथ रखता था: आप तालिका को /routing table add name=vpn fib से घोषित करते हैं, फिर मार्ग में और mangle नियम में नाम से उसका संदर्भ देते हैं। 6.x का वह स्निपेट जो तालिका परिभाषित किए बिना routing-mark इनलाइन डालता है, साफ़ लोड होता है और किसी से मेल नहीं खाता। दूसरा क्लासिक मामला दो 0.0.0.0/1 आधे हैं, या एक ही तालिका में समान दूरी पर दो डिफ़ॉल्ट: कर्नेल एक चुनता है, और रीबूट के बाद व्यवहार बदल सकता है।

दूसरा हिस्सा: मार्ग खोज से पहले चिह्नित करें

चयनक तय करता है कि कौन से पैकेट उस तालिका में प्रवेश करेंगे। RouterOS आमतौर पर गंतव्य नीति के लिए पता सूची से, या डिवाइस नीति के लिए स्रोत पते से शुरू करता है:

/ip firewall mangle add chain=prerouting src-address=192.168.88.50 action=mark-routing new-routing-mark=vpn
/ip firewall mangle add chain=prerouting dst-address-list=via-vpn action=mark-routing new-routing-mark=vpn
/ip firewall address-list add list=via-vpn address=203.0.113.10

Linux फ़र्मवेयर वही काम netfilter चिह्न और ऐसे नियम से करता है जो चिह्नित पैकेटों को आपकी भरी हुई तालिका में भेजता है:

iptables -t mangle -A PREROUTING -p tcp --dport 27000:27050 -j MARK --set-mark 0x200
ip route add default dev tun0 table 100
ip rule add fwmark 0x200 table 100

चेन शैली का चुनाव नहीं है। जब पैकेट FORWARD तक पहुँचता है तब मार्ग खोज हो चुकी होती है, इसलिए वहाँ MARK या DROP केवल फिर से लिख सकता है या गिरा सकता है। चिह्न को अग्रेषित ट्रैफ़िक के लिए PREROUTING में और राउटर द्वारा बनाए गए ट्रैफ़िक के लिए OUTPUT में गिरना चाहिए, क्योंकि राउटर का DNS, NTP और अपडेट जाँच वहीं रहते हैं। यही आउटपुट पथ सामान्य कारण है कि पूरी तरह टनल किया गया सेटअप लीक परीक्षण में अब भी ISP रिज़ॉल्वर से उत्तर देता है।

डिवाइस नीति को ऐसा मेल चाहिए जो सरके नहीं। DHCP में पता आरक्षित करें, या समर्पित सेगमेंट के लिए इंटरफ़ेस मिलाएँ; बाद में दूसरे डिवाइस पर जाने वाला पता चुपचाप गलत क्लाइंट पर टनल लागू कर देता है। अपने सबनेट वाला प्रति-SSID ब्रिज उसी विचार का अधिक टिकाऊ रूप है, और यह IPv6 नियमों को रहने की जगह भी देता है।

तीसरा हिस्सा: NAT, DNS और LAN अपवाद

टनल से बाहर जाने वाले ट्रैफ़िक को ऐसा स्रोत पता चाहिए जिसका दूर का पक्ष उत्तर दे। अनुवाद को टनल इंटरफ़ेस तक सीमित करें: RouterOS पर out-interface=VPN_NAME, Linux पर -o tun0, pfSense पर मेल खाती आउटबाउंड NAT प्रविष्टि। इस सीमा के बिना masquerade नियम उस ट्रैफ़िक को फिर से लिखता है जिसे आप अछूता छोड़ना चाहते थे, और लक्षण यह है कि बिना टनल वाला डिवाइस अपना सार्वजनिक पता खो देता है।

LAN अपवाद टनल से भी अधिक सहायता थ्रेड बनाता है। अगर चिह्नित तालिका में केवल डिफ़ॉल्ट मार्ग है, तो चुने गए डिवाइस से प्रिंटर या NAS गंतव्य उस डिफ़ॉल्ट से मेल खाता है और टनल में गायब हो जाता है। LAN मार्ग उसी तालिका में जोड़ें, या चयनक में स्थानीय सबनेट को बाहर रखें; दोनों काम करते हैं, और बाद में VLAN जोड़ते समय अपवाद को सही रखना आसान है।

DNS अलग पथ लेता है। राउटर जो क्वेरी आगे भेजता है वे राउटर से उत्पन्न होती हैं और OUTPUT का पालन करती हैं, अग्रेषण चिह्न का नहीं, इसलिए पूरी तरह टनल किया लैपटॉप अब भी ISP से हल कर सकता है। क्लाइंट को टनल से पहुँचने योग्य रिज़ॉल्वर की ओर इंगित करें, या राउटर के अपने पोर्ट 53 ट्रैफ़िक को चिह्नित करें, फिर यह मानने के बजाय कि उत्तर वेब अनुरोध के साथ गया, हल किए गए पते की जाँच करें।

जब नियम मेल खाता है पर ऐप अब भी WAN उपयोग करता है

गंतव्य सूचियाँ बुरी तरह पुरानी होती हैं। कोई नाम ऐसे पते पर हल होता है जो सूची में नहीं है, इसलिए अनुरोध WAN ले लेता है जबकि सूचीबद्ध पते पर आपका हर परीक्षण काम कर रहा था। सूची को उसी रिज़ॉल्वर से ताज़ा करें जिसका क्लाइंट उपयोग करता है, और जब सचमुच एक डिवाइस का सारा ट्रैफ़िक चाहिए तो स्रोत-आधारित चयनक को प्राथमिकता दें।

IPv6 शांत बाईपास है। डिवाइस के पास अपने डिफ़ॉल्ट मार्ग और अपने नियम समूह वाला दूसरा पता परिवार है, और केवल IPv4 पता मिलाना आधी नीति है। वही चयनक ip6tables या nftables के समतुल्य पर लागू करें, या उस सेगमेंट पर IPv6 जानबूझकर बंद करें, संयोग से नहीं।

स्थापित कनेक्शन भी मायने रखते हैं। बदलाव से पहले बनी conntrack प्रविष्टि समाप्त होने तक पुराने पथ पर चलती रहती है, इसलिए संपादन के दौरान खुला रहा ब्राउज़र ठीक ऐसे नियम जैसा दिखता है जो कभी लागू ही नहीं हुआ। नीति का आकलन करने से पहले नया कनेक्शन खोलें, या स्थिति फ़्लश करें।

दो डिवाइस और एक रीबूट से सत्यापित करें

जिस डिवाइस को टनल में होना चाहिए और जिसे नहीं होना चाहिए, दोनों को परखें, और गति के आंकड़े के बजाय दूसरी हॉप की तुलना करें। दोनों में से traceroute दूसरी हॉप पर या तो टनल गेटवे दिखाता है या ISP गेटवे; अगर दोनों एक जैसे दिखें तो चिह्न या तालिका वह नहीं कर रहे जो नियम कहता है। परीक्षण के लिए नए कनेक्शन उपयोग करें।

फिर रीबूट करें। स्टार्टअप क्रम वह जगह है जहाँ काम करती नीति टूटी हुई बन जाती है, क्योंकि unreachable मार्ग स्थापित होने से पहले क्लाइंट चालू होना चाहिए, और पुराना नियम समूह बहाल करने वाला सहेजा स्नैपशॉट आपकी तालिका को ऊपर लिख देगा। जाँचें कि हर नियम सहेजी गई कॉन्फ़िग में है और चिह्नित डिफ़ॉल्ट बूट के बाद मौजूद है, केवल आपके टाइप करने के बाद नहीं।

अगर कुछ विफल हो, पहले चिह्न हटाएँ और देखें सामान्य ट्रैफ़िक लौटता है या नहीं, फिर तालिका हटाएँ। यह क्रम बताता है कि आप राउटिंग समस्या का पीछा कर रहे हैं या फ़ायरवॉल समस्या का, और काम पूरा करते समय घर को चलते प्रिंटर के साथ छोड़ देता है।