राउटर VPN मार्फत एउटा यन्त्र जान तीन नियम चाहिन्छ, टगल होइन
राउटर VPN मार्फत एउटा यन्त्र पठाउनु चेकबक्स होइन, पोलिसी राउटिङ हो: चिन्ह लगाइएको तालिका, सीमित NAT नियम, र गाइडहरूले छोड्ने DNS, IPv6 र LAN मार्गहरू।
राउटर 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 को गेटवे देखाउँछ; दुवै उस्तै देखिए मार्क वा तालिकाले नियम भनेअनुसार गरिरहेको छैन। परीक्षणका लागि नयाँ जडान प्रयोग गर्नुहोस्।
त्यसपछि रिबुट गर्नुहोस्। चलिरहेको पोलिसी बिग्रने ठाउँ सुरुको क्रम हो, किनभने पुग्न नसकिने रुट स्थापना हुनुअघि क्लाइन्ट चलिरहेको हुनुपर्छ, र पुरानो नियम समूह फर्काउने सुरक्षित स्न्यापसटले तपाईंको तालिका माथि लेख्छ। हरेक नियम सुरक्षित कन्फिगरेसनमा छ र चिन्ह लगाइएको डिफल्ट बुटपछि अवस्थित छ भनी टाइप गरेपछि मात्र होइन, जाँच्नुहोस्।
केही असफल भयो भने पहिले मार्क हटाएर सामान्य ट्राफिक फर्कन्छ कि हेर्नुहोस्, त्यसपछि तालिका हटाउनुहोस्। त्यो क्रमले तपाईं राउटिङ समस्या पछ्याउँदै हुनुहुन्छ वा फायरवाल समस्या भन्ने बताउँछ, र काम सकिँदासम्म घरमा चल्ने प्रिन्टर छोड्छ।