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 फाइलमध्ये, फायरवॉल नियम ते लोड करणाऱ्या सेवेमध्ये, आणि क्लायंट मार्ग इंटरफेस उभा करणाऱ्या कॉन्फिगमध्ये हवेत, तुम्ही विसरणार असलेल्या शेलमध्ये नाही। पुन्हा कनेक्ट व्हा, त्या दोनच चाचण्या पुन्हा करा आणि काउंटर हलत असल्याची खात्री करा।