PiVPN को ह्यान्डसेक काम गर्छ, पृष्ठहरू अड्किन्छन्: MASQUERADE जाँच्नुहोस्

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

क्लाइन्टले के पाउन सक्छ र के सक्दैन त्यसबाट सुरु गर्नुहोस्

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

सार्वजनिक साइटहरूको समय सकिँदा ping लाई जवाफ दिने टनेल ठेगाना फर्वार्डिङ वा अनुवादको समस्याको संकेत हो, टुटेको ह्यान्डसेकको होइन। क्लाइन्टको आफ्नै स्थिति प्यानलले यी दुई छुट्याउन सक्दैन, किनभने त्यसलाई नियन्त्रण च्यानल माथि छ भन्ने मात्र थाहा हुन्छ। सर्भरमा टनेल इन्टरफेस यसले जाँच्नुहोस्: ip -br addr show tun0 र क्लाइन्टलाई दिइएको ठेगाना तपाईंले कन्फिगर गरेको पूलभित्र पर्छ भनी पुष्टि गर्नुहोस्। पूल र क्लाइन्ट ठेगाना मिलेन भने पहिले त्यही सुधार्नुहोस्, किनभने तलको हरेक नियम पूलसँग मिल्छ।

अर्को, सार्वजनिक ठेगानामा पुग्न सर्भरले कुन इन्टरफेस प्रयोग गर्नेछ भनी सोध्नुहोस्। ip route get 203.0.113.9 आफ्नो पहिलो लाइनमा छानिएको यन्त्र र स्रोत छाप्छ। त्यो यन्त्रको नाम लेख्नुहोस्, किनभने NAT नियममा यही मान हुनुपर्छ।

प्याकेट बाहिर जान्छन् कि जाँदैनन् भनी निर्णय गर्ने नियम पढ्नुहोस्

MASQUERADE प्याकेटलाई तब मात्र पुनःलेख्छ जब प्याकेट नियममा उल्लेख गरिएको इन्टरफेसबाट बाहिर जान्छ। तार भएको यन्त्रमा सीमित नियमले Wi-Fi बाट बाहिर जाने ट्राफिकका लागि केही गर्दैन, र प्याकेट माथिल्लो राउटरसम्म आफ्नो निजी स्रोत ठेगाना राख्छ। त्यो राउटरसँग तपाईंको टनेल पूलतिर फर्कने बाटो छैन, त्यसैले त्यसले जवाफ फ्याँक्छ, र क्लाइन्टले खुल्ने र त्यसपछि मर्ने जडान देख्छ। पहिलो जवाफ आवश्यक हुनुअघि पृष्ठको कति भाग आउँछ भन्नेसँग लक्षण बढ्छ।

जीवित तालिका सूचीबद्ध गर्नुहोस् र केवल MASQUERADE शब्द खोज्नुको सट्टा आउट-इन्टरफेस स्तम्भ पढ्नुहोस्। ढाँचा गरिएको सूचीभन्दा थप्ने रूपको आउटपुट तुलना गर्न सजिलो छ:

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

एक समय Ethernet र अहिले Wi-Fi प्रयोग गर्ने Raspberry Pi मा, पुरानो नाम लगभग सधैं पूरै कथा हुन्छ। इन्स्टलरले सेटअपको समयमा कुन यन्त्र थियो लेख्यो, र सुरक्षित नियमसमूहले हरेक बुटमा त्यही दोहोर्याउँछ। अरू केही बदल्नुअघि रुट खोजबाट आएको यन्त्रलाई नियममा भएको यन्त्रसँग तुलना गर्नुहोस्। दुवै मिले इन्टरफेस तपाईंको समस्या होइन र तपाईंले अन्तिम भागको काउन्टरतिर जानुपर्छ। फरक परे सुधार भनेको स्थायित्व फाइलमा एक शब्दको सम्पादन हो।

सुरक्षित नियमसमूह सुधार्नुहोस्, चलिरहेको मात्र होइन

केवल जीवित तालिका सम्पादन गर्ने अर्को रिबुटसम्म टिक्छ, जुन समस्या समाधान भयो भनी विश्वास दिलाउन ठ्याक्कै पर्याप्त हुन्छ। बुटमा फर्किने नियमहरू एउटा फाइलमा बस्छन् जसलाई फायरवाल स्थायित्व प्याकेजले पुनःलोड गर्छ। Debian आधारित Pi इमेजमा त्यो फाइल सामान्यतया /etc/iptables/rules.v4।

छुनुअघि प्रतिलिपि लिनुहोस्, त्यसपछि MASQUERADE लाइनको आउट-इन्टरफेस तपाईंले लेखेको यन्त्रले बदल्नुहोस्, उदाहरणका लागि -o wlan0 को सट्टा -o eth0। स्रोत दायरा जस्तो छ त्यस्तै राख्नुहोस्, तपाईंको क्लाइन्ट पूल बदलिएको छैन भने। पुनःलोड गर्नुहोस् र नियमले अब सही यन्त्र भन्छ भनी पुष्टि गर्नुहोस्:

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

छेउछाउका दुई सेटिङ बिर्सन सजिलो छ। sysctl net.ipv4.ip_forward ले 1 रिपोर्ट गर्नुपर्छ, र माथिल्लो राउटरले निजी स्रोत ठेगाना आफैं फिल्टर गर्नु हुँदैन।

नियम सक्रिय हुन्छ भनी प्रमाणित गर्नुहोस्, त्यसपछि अझै के ढिलो छ छुट्याउनुहोस्

काउन्टर नै नियम मिलेको एकमात्र इमानदार प्रमाण हो। विस्तृत सूची चलाउनुहोस्, क्लाइन्टमा डाउनलोड सुरु गर्नुहोस् र फेरि चलाउनुहोस्। तपाईंको नियमको छेउका प्याकेट र बाइट स्तम्भ बढ्नुपर्छ, र शून्यमा रहने नियम अझै मिल्दैन। काउन्टर सर्छ तर पृष्ठहरू अझै असफल हुन्छन् भने, स्रोत दायरालाई वास्तविक पूलसँग यसले तुलना गर्नुहोस् grep -n "^server " /etc/openvpn/server.conf। ती सर्छन् र पृष्ठहरू लोड हुन्छन् तर थ्रुपुट कमजोर छ भने, अनुवाद सकियो र बाँकी समस्या अन्तै छ।

एउटै क्लाइन्टबाट दुई स्थानान्तरण तुलना गर्नुहोस्, एउटा स्थानीय सञ्जालको होस्टमा र अर्को टनेलबाट त्यही होस्टमा। दुवैमा ढिलो हुनुले VPN होइन, Pi को माथिल्लो लिंक वा Wi-Fi जडानतिर संकेत गर्छ। टनेलबाट मात्र ढिलो हुनुले MTU र पुनःप्रेषणतिर संकेत गर्छ, जुन तपाईं यसले जाँच्न सक्नुहुन्छ ip -s link show tun0 कुनै पनि क्रिप्टो सेटिङ बदल्नुअघि।

प्रयोग रद्द गर्न प्रतिलिपि पुनःस्थापित गर्नुहोस् र फेरि लोड गर्नुहोस्, त्यसपछि मूल नियम र त्यसका काउन्टर फर्केका छन् भनी पुष्टि गर्नुहोस्। सर्भर नोटमा इग्रेस यन्त्र र पुनःलोड आदेश लेख्नुहोस्, किनभने अर्को अपलिंक परिवर्तनले त्यही असंगति फेरि पत्ता लगाउनेछ। गलत यन्त्र भन्ने नियम ट्राफिकलाई त्यसको आवश्यकता नपर्दासम्म अदृश्य रहन्छ।