राउटर 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

न पोहोचणारा रूट हेच कारण आहे की मार्क केलेला टेबल मुख्य टेबलमधील अपवाद यादीवर मात करतो। टनेल पडल्यावर मार्क केलेल्या पॅकेटना शांतपणे WAN वर परत जाण्याऐवजी लगेच न पोहोचण्याचा प्रतिसाद मिळतो, त्यामुळे बिघाड तासाभराने तपासायच्या भौगोलिक स्थान पानात नाही, तर अनुप्रयोगाच्या त्रुटी संदेशात दिसतो।

RouterOS 7 ते वेगळे करते जे 6.x ने एकत्र ठेवले होते: तुम्ही टेबल /routing table add name=vpn fib ने जाहीर करता, नंतर रूटवर आणि mangle नियमात त्याचा नावाने उल्लेख करता। टेबल न ठरवता routing-mark लिहिणारा 6.x तुकडा स्वच्छ लोड होतो आणि कशाशीही जुळत नाही। दुसरा क्लासिक म्हणजे 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 मधून नावे सोडवू शकतो। क्लायंटना टनेलमधून पोहोचणाऱ्या रिझोल्व्हरकडे वळवा, किंवा राउटरच्याच port-53 रहदारीला मार्क करा, आणि नंतर उत्तर वेब विनंतीसोबत प्रवास केले असे गृहीत धरून न सोडवलेला पत्ता तपासा।

नियम जुळतो पण ॲप तरीही WAN वापरतो तेव्हा

गंतव्य याद्या लवकर जुन्या होतात। नाव अशा पत्त्यावर सोडवले जाते जो यादीत नाही, त्यामुळे विनंती WAN वर जाते, तर यादीतल्या पत्त्यावर केलेली प्रत्येक चाचणी चालली होती। क्लायंट वापरत असलेल्या त्याच रिझोल्व्हरकडून यादी ताजी करा, आणि एका डिव्हाइसवरून सर्व रहदारी खरोखर हवी असेल तर स्रोत-आधारित निवडकाला प्राधान्य द्या।

IPv6 हा शांत बगलमार्ग आहे। डिव्हाइसला स्वतःचा डीफॉल्ट रूट आणि स्वतःचा नियम संच असलेले दुसरे पत्ता कुटुंब असते, आणि फक्त IPv4 पत्त्याशी जुळवणे म्हणजे अर्धी पॉलिसी। तोच निवडक ip6tables किंवा nftables च्या समतुल्यावर लागू करा, किंवा त्या विभागातील IPv6 अपघाताने नाही तर जाणीवपूर्वक बंद करा।

प्रस्थापित जोडण्याही महत्त्वाच्या आहेत। बदलापूर्वी तयार झालेली conntrack नोंद कालबाह्य होईपर्यंत जुन्या मार्गानेच जाते, त्यामुळे संपादनादरम्यान उघडे राहिलेले ब्राउझर कधीच लागू न झालेल्या नियमासारखेच दिसते। धोरण ठरवण्यापूर्वी नवीन जोडणी उघडा, किंवा स्थिती रिकामी करा।

दोन डिव्हाइस आणि रीबूटने पडताळा

टनेलमधून जायला हवे असलेले डिव्हाइस आणि जायला नको असलेले डिव्हाइस तपासा, आणि वेगाच्या आकड्याऐवजी दुसरा हॉप तुलना करा। प्रत्येकाकडून traceroute दुसऱ्या हॉपवर टनेलचा गेटवे किंवा ISP चा गेटवे दाखवते; दोन्ही सारखे दिसले तर मार्क किंवा टेबल नियम सांगतो तसे करत नाही। चाचणीसाठी नवीन जोडण्या वापरा।

मग रीबूट करा। चालू असलेले धोरण बिघडते ते सुरुवातीच्या क्रमात, कारण न पोहोचणारा रूट बसवण्यापूर्वी क्लायंट सुरू असला पाहिजे, आणि जुना नियम संच परत आणणारा जतन केलेला स्नॅपशॉट तुमचे टेबल पुसून टाकेल। प्रत्येक नियम जतन केलेल्या संरचनेत आहे आणि मार्क केलेला डीफॉल्ट बूटनंतर अस्तित्वात आहे हे तुम्ही टाइप केल्यानंतरच नाही, तर तपासा।

काही बिघडले तर आधी मार्क काढून सामान्य रहदारी परत येते का पहा, मग टेबल काढा। तो क्रम सांगतो की तुम्ही राउटिंगची अडचण पकडत आहात की फायरवॉलची, आणि काम संपेपर्यंत घरात चालणारा प्रिंटर ठेवतो।