WireGuard ह्यान्डसेक काम गर्छ तर इन्टरनेट छैन: प्याकेट ट्र्याक गर्नुहोस्
ह्यान्डसेकले कुञ्जी र पहुँच मात्र प्रमाणित गर्छ। AllowedIPs बाट फर्वार्डिङ, NAT र फिर्ती मार्ग हुँदै एउटा प्याकेट ट्र्याक गर्नुहोस् र यो कहाँ रोकिन्छ हेर्नुहोस्।
सुरुङ सक्रिय छ, wg show ले हालैको ह्यान्डसेक रिपोर्ट गर्छ, तपाईं सर्भरको सुरुङ ठेगानामा पिङ गर्न सक्नुहुन्छ, र त्यसपछि केही पनि जवाफ दिँदैन। पहिलो प्रवृत्ति कुञ्जी फेरि बनाउने वा कन्फिग फेरि साझा गर्ने हुन्छ। त्यसले पहिले नै काम गर्ने प्रमाणित भइसकेको बाटोको भाग मात्र बदल्छ।
पूरा भएको ह्यान्डसेकले दुई पक्ष कुञ्जीमा सहमत छन्, UDP अन्तिम बिन्दुमा पुग्छ, र क्रिप्टो राउटिङले प्याकेट स्वीकार गर्छ भन्छ। प्याकेट त्यसपछि सर्भर छोड्न सक्छ कि भन्नेबारे यसले केही भन्दैन।
त्यसैले अनुमान गर्नुको सट्टा एउटा प्याकेट ट्र्याक गर्नुहोस्। यो मर्न सक्ने चार ठाउँ छन्, र प्रत्येकले फरक चिन्ह छोड्छ।
ह्यान्डसेकले वास्तवमा के प्रमाणित गर्छ
WireGuard एउटा UDP प्रोटोकल हो जसले Noise ह्यान्डसेकबाट सत्र स्थापना गर्छ र त्यसपछि साथीका लागि प्याकेट इन्क्रिप्ट गर्छ। जब wg show ले केही सेकेन्ड पुरानो ह्यान्डसेक र बढ्दो स्थानान्तरण काउन्टर देखाउँछ, अन्तिम बिन्दु, कुञ्जी र साथीको सार्वजनिक कुञ्जी सबै सही हुन्छन्।
यसले प्रमाणित नगर्ने कुरा हो: तपाईंको क्लाइन्टले इन्टरनेटतर्फ जाने ट्राफिक इन्टरफेसमा पठाउँछ कि पठाउँदैन, सर्भर त्यो फर्वार्ड गर्न तयार छ कि छैन, वा जवाफले फिर्ती बाटो भेट्टाउन सक्छ कि सक्दैन। यी कर्नेल राउटिङ र फायरवालका निर्णय हुन्, र ती सुरुङ बाहिर लिइन्छन्।
सर्भरको सुरुङ ठेगानामा पिङ गर्नु यति भ्रमित गर्ने परीक्षण हुनुको कारण यही हो। त्यो प्याकेट सर्भरलाई नै सम्बोधन गरिएको, त्यसैले यो स्थानीय रूपमा टुंगिन्छ। यसलाई कहिल्यै फर्वार्डिङ, कहिल्यै अनुवाद र कहिल्यै इन्टरनेटबाट फिर्ती मार्ग चाहिँदैन।
AllowedIPs एउटा राउटिङ निर्णय हो
क्लाइन्टमा AllowedIPs ले दुई काम गर्छ। यो कुन गन्तव्य ठेगाना यो साथीको सुरुङमा पठाइन्छ भनी निर्धारण गर्ने क्रिप्टोकुञ्जी राउटिङ तालिका हो, र यो साथीले तपाईंबाट स्वीकार गर्ने स्रोत ठेगानाको सूची हो। क्लाइन्ट कन्फिगमा 10.8.0.0/24 मात्र भए, सार्वजनिक गन्तव्य कहिल्यै इन्टरफेसमा पस्दैनन् र तपाईंको सामान्य पूर्वनिर्धारित मार्गले तिनलाई सुरुङ बाहिर लैजान्छ। त्यसपछि सुरुङ पूर्ण रूपमा काम गर्छ र तपाईंले चाहेको कुनै कुरा गर्दैन।
कन्फिग फाइलले के भन्छ भन्ने होइन, क्लाइन्टले वास्तवमा के स्थापना गर्यो हेर्नुहोस्:
wg show wg0 allowed-ipsip route get 1.1.1.1
दोस्रो कमाण्ड निर्णायक हो। जवाफले तपाईंको भौतिक इन्टरफेस र सामान्य गेटवे भन्छ भने, प्याकेट सुरुङ हुँदै जाँदैन र सर्भरतर्फको कुनै परिवर्तनले त्यो सुधार्ने छैन। IPv4 का लागि 0.0.0.0/0 र IPv6 का लागि ::/0 छुट्टाछुट्टै थप्नुहोस्; एउटा परिवारका लागि सबै समात्ने नियमले अर्कोलाई यसको मूल मार्गमै छोड्छ, र यो काम गर्ने IPv4 सुरुङ र अड्किएको IPv6 खोजीको सामान्य कारण हो।
गेटवेमा प्याकेट कहाँ मर्छ
मार्ग सही भए पनि प्याकेट अझै कतै जाँदैन भने, यो सर्भरमा पुग्छ र त्यहीँ रोकिन्छ। चार जाँचले अधिकांश गेटवे समेट्छन्।
फर्वार्डिङ। sysctl net.ipv4.ip_forward ले 0 फर्काउनु नेहमीको जवाफ हो, र धेरै वितरणहरू अझै पूर्वनिर्धारित रूपमा 0 मै छन्। यो 1 हुनुपर्छ, र रिबुटमा हराउने कमाण्डको सट्टा sysctl फाइलमा स्थायी रूपमा सेट गर्नुपर्छ। IPv6 फर्वार्डिङ छुट्टै स्विच हो।
फिल्टर नीति। पूर्वनिर्धारित drop नीति भएको FORWARD चेनले सुरुङको ट्राफिक फाल्छ, तर होस्ट आफैंतर्फ जाने ट्राफिकलाई अनुमति दिन्छ, जुन लक्षणसँग ठ्याक्कै मिल्छ। सुरक्षित फाइल होइन, जीवित नियमसमूह पढ्नुहोस्: nft list ruleset वा iptables -S।
अनुवाद वा राउटिङ। निजी सुरुङ ठेगाना प्रयोग गर्ने क्लाइन्टलाई सर्भरको निर्गमन इन्टरफेसमा स्रोत NAT चाहिन्छ, वा माथिल्लो नेटवर्कले फिर्ता पठाउन जान्ने राउट गरिएको प्रिफिक्स चाहिन्छ। यी दुईबीचको छनोट ठेगाना योजनाअनुसार हुन्छ। तपाईंको प्रिफिक्स पहिले नै फिर्ता राउट गर्ने नेटवर्कमा MASQUERADE थप्नु हानिकारक छैन तर अर्थहीन छ, र मार्ग नभएको ठाउँमा यो छोड्दा जवाफहरू राउट गर्न नसकिने निजी दायरातर्फ सम्बोधित रहन्छन्।
फिर्ती मार्ग। राउट गरिएका डिजाइनमा माथिल्लो राउटरलाई तपाईंको सर्भरतर्फ देखाउने मार्ग चाहिन्छ। प्रदायकको नेटवर्कले पनि यो रोक्न सक्छ: केही क्लाउडले इन्स्टेन्समा स्रोत र गन्तव्य जाँच सक्रिय गर्छन्, जसले स्रोत इन्स्टेन्सकै ठेगाना नभएका प्याकेटहरू त्यो जाँच बन्द नगरेसम्म चुपचाप फाल्छ।
DNS राउटिङभन्दा फरक तरिकाले असफल हुन्छ
ज्ञात ठेगानामा प्याकेट र नाम खोजी दुई छुट्टा असफलता हुन्, र त्रुटि सन्देशहरू विपरीत दिशामा भ्रमित गर्छन्। ping 1.1.1.1 काम गरे पनि ब्राउजरले केही लोड गर्न नसके, मार्ग ठीक छ र नाम विश्लेषण छैन। पिङ आफैं असफल भए, DNS अप्रासंगिक छ र तपाईं अघिल्लो खण्डमा फर्कनुभयो।
wg-quick ले कन्फिगको DNS = लाइनबाट रिजोल्भर सेट गर्न सक्छ, र systemd-resolved को प्रत्येक लिंकका लागि आफ्नै व्यवहार छ। सुरुङभित्र मात्र पुग्न सकिने ठेगानाले रिजोल्भर बदल्ने VPN ले सुरुङ खस्ने क्षणमा हरेक खोजी असफल बनाउँछ, जुन सुरुङले नै इन्टरनेट बिगारेको जस्तो देखिन्छ।
| Symptom | Layer to inspect |
|---|---|
| Tunnel address pings, nothing else does | Client route, then gateway forwarding |
| Public IP pings, hostnames fail | Resolver selection and reachability |
| Handshake completes, no reply ever | FORWARD policy or missing NAT on the server |
| Small requests work, large transfers stall | MTU and TCP MSS clamping |
प्रमाण दिने क्रम
पहिले क्लाइन्टतर्फको जाँच चलाउनुहोस्, किनकि यो एउटै कमाण्ड हो र आधा सम्भावना हटाउँछ। त्यसपछि सर्भर इन्टरनेट निकासका रूपमा बनाइएको हो कि होइन पुष्टि गर्नुहोस्; निजी पहुँचका लागि बनाइएको गेटवे सार्वजनिक गन्तव्य असफल हुँदा बिग्रिएको हुँदैन।
सर्भरमा, क्लाइन्टबाट पिङ पठाउँदा इन्टरफेस हेर्नुहोस्: tcpdump -ni wg0 icmp ले अनुरोध देखाउनुपर्छ, र tcpdump -ni eth0 icmp ले त्यो बाहिर जाँदै गरेको देखाउनुपर्छ, अनुवाद भएको होस् वा नहोस्। पहिलोमा देखिएर दोस्रोमा कहिल्यै नदेखिए, रोकिने काम सर्भरमै स्थानीय छ। बाहिर गएर जवाफ फर्किएन भने, समस्या माथि छ, र त्यो अर्को कुराकानी हो।
अन्तमा सुधार रिबुटपछि पनि टिक्ने बनाउनुहोस्। फर्वार्डिङ sysctl फाइलमा, फायरवाल नियम तिनलाई लोड गर्ने सेवामा, र क्लाइन्ट मार्ग इन्टरफेस उठाउने कन्फिगमा हुनुपर्छ, तपाईंले बिर्सने शेलमा होइन। फेरि जोडिनुहोस्, ती दुई परीक्षण दोहोर्याउनुहोस् र काउन्टर चलिरहेको पुष्टि गर्नुहोस्।