हरियो आइकन, उही सार्वजनिक IP: VPN ले कुन मार्ग छोड्यो

जोडिएको छ, ट्रे आइकन हरियो छ, र ठेगाना देखाउने पृष्ठले अझै प्रदायकको ठेगाना देखाइरहेको छ, तर यसको अर्थ स्वतः खराबी होइन। क्लाइन्टले दुई छुट्टै काम गर्छ: यसले टनेल बनाउँछ, र यसले राउटिङ तालिका सम्पादन गर्छ। जुनसुकै अर्को बिना हुन सक्छ, र छनोट राउटिङ त्यो कन्फिगरेसन हो जहाँ दोस्रो जानाजान छोडिन्छ।

क्लाइन्टले वास्तवमा के स्थापना गर्‌यो

टनेल माथि छ कि भनेर सोध्नुको सट्टा प्याकेटलाई वास्तविक गन्तव्यसम्म कुन इन्टरफेसले लैजान्छ भनेर सोध्नुहोस्। त्यो गन्तव्यको मार्ग नभएको टनेल त्यस्तो निजी बाटो हो जहाँ कोही जाँदैन।

ip route get 9.9.9.9
Find-NetRoute -RemoteIPAddress 9.9.9.9
route print -4

पहिलो आदेशले Linux र macOS मा जवाफ दिन्छ, र बाँकी दुई Windows का समकक्ष हुन् जहाँ एउटा पुग्छ। यदि जवाफले भौतिक एडाप्टरको नाम लिन्छ भने टनेल माथि छ र पूर्वनिर्धारित मार्ग कहिल्यै सरेन। टनेल प्रयोग गर्नुपर्ने गन्तव्यका लागि जाँच दोहोर्याउनुहोस्, किनकि दुई जाँच, एउटा टाढाको र एउटा सामान्य, कुन डिजाइन लागू छ भन्छन्।

छनोट राउटिङका तीन रूप

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

grep -nE "redirect-gateway|route-nopull|route " /etc/openvpn/client/*.conf
ip route show table main | head -20

निर्णय गर्ने निर्देशनका लागि प्रोफाइल पढ्नुहोस्, त्यसपछि यसले के उत्पादन गर्‌यो भनेर तालिका पढ्नुहोस्। धकेलिएको निर्देशन क्लाइन्टमा दबाउन पनि सकिन्छ, त्यसैले सर्भरलाई दोष दिनुअघि प्रोफाइल र तालिका मिल्नुपर्छ।

परको पक्षले स्रोत ठेगाना पुनः लेख्नुपर्छ

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

sysctl net.ipv4.ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -S | grep MASQUERADE

वास्तवमै इन्टरनेटतर्फ फर्केको इन्टरफेसको नाम लिनुहोस्, जो आधुनिक वितरणमा सधैं eth0 हुँदैन। स्थिर ठेगाना भएको होस्टेड सर्भरले masquerade प्रयोग गर्नुको सट्टा सिधै त्यो ठेगानामा अनुवाद गर्न सक्छ। दुवै आधा महत्त्वपूर्ण छन्, किनकि अनुवाद बिनाको अग्रेषणले राउट नहुने स्रोत चुहाउँछ, जबकि अग्रेषण बिनाको अनुवादले प्याकेट कहिल्यै देख्दैन।

नाम समाधान आफ्नै बाटो जान्छ

नाम भेट्ने जाँच स्थानीय सञ्जालको समाधानकर्तामा गएको बेला ट्राफिक टनेलबाट बाहिर जान सक्छ। देखिने ठेगाना उही रहन्छ, जाँचहरू रहँदैनन्, र त्यही खाडल विभाजित DNS डिजाइनले छान्छ।

resolvectl status | head -20
resolvectl query example.org

कुन सर्भरले जवाफ दियो र त्यो टनेलअघिको आधाररेखाभन्दा फरक छ कि छैन हेर्नुहोस्। विभाजित टनेलमा यो सामान्यतया त्यो सेटिङ हो जुन मानिसहरूले ठेगानाको बारेमा गुनासो गर्दा बदल्न चाहन्थे, र त्यही हो जुन उनीहरूले कहिल्यै हेरेनन्।

कुरा टुंग्याउने चार अवलोकन

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

curl -sS https://ifconfig.me/ip
ip route get 9.9.9.9

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