WireGuard ले नयाँ ह्यान्डशेक देखाउँदैन: पहिले के जाँच्ने

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

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

निष्क्रिय इन्टरफेससँग रिपोर्ट गर्न केही छैन

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

दुवैतर्फ काउन्टर शून्यमा रहे समस्या सुरुङभन्दा माथि छ। इन्टरफेससम्म केही पुगेन जसले केही सुरु गरोस्।

peer ले बोक्न पाउने ट्राफिक ट्रिगर गर्नुहोस्

स्थानीय मेसिनमा peer का अनुमति दिइएका प्रिफिक्सभित्रको ठेगाना छान्नुहोस् र राउटिङ तालिकाले त्यसलाई इन्टरफेसबाट पठाउँछ भन्ने पुष्टि गर्नुहोस्। ती प्रिफिक्सबाहिरको गन्तव्यले WireGuard को कुनै संलग्नता बिना सामान्य राउट गरिएको अनुरोध उत्पन्न गर्छ। चाँडो जवाफ दिने सेवा प्रयोग गर्नुहोस्, जस्तै ping वा छोटो TCP जडान, ताकि प्रयासको देखिने सुरुवात र अन्त्य होस्। त्यसपछि स्क्रिन हेरेर पर्खनुको सट्टा ह्यान्डशेक लाइन फेरि पढ्नुहोस्।

ip route get 10.60.9.5
ping -c 3 -W 2 10.60.9.5
wg show wg0 latest-handshakes
wg show wg0 transfer

मार्ग प्रश्न ping भन्दा महत्त्वपूर्ण छ। यदि यसले भौतिक इन्टरफेसको नाम लिन्छ भने प्याकेट कहिल्यै सुरुङमा प्रवेश गरेन र खाली ह्यान्डशेक क्रिप्टोग्राफिक नभई राउटिङको जवाफ हो। peer डिबग गर्नुअघि मार्ग सुधार्नुहोस्।

कुञ्जी जोडी र एन्डपोइन्ट तुलना गर्नुहोस्

ट्राफिक साँच्चै प्रस्ताव भएपछि अर्को जाँच पहिचान हो। स्थानीय निजी कुञ्जी अर्को पक्षले अधिकृत गर्ने सार्वजनिक कुञ्जीसँग मिल्नुपर्छ, कन्फिगर गरिएको टाढाको सार्वजनिक कुञ्जीले इच्छित peer पहिचान गर्नुपर्छ, र कुनै पनि पहिले साझा गरिएको कुञ्जी दुवै छेउमा मिल्नुपर्छ। base64 कुञ्जीमा एक अक्षरको फरकले कन्फिगर गरिएको जस्तो देखिने र कहिल्यै आदानप्रदान पूरा नगर्ने peer बनाउँछ। कुञ्जी पुनः उत्पन्न गर्नुको सट्टा प्रोभिजनिङ रेकर्डसँग तुलना गर्नुहोस्, किनकि नयाँ कुञ्जीले पुरानोमा विश्वास गरेका सबै peer अमान्य गर्छ।

एन्डपोइन्टलाई पनि त्यही जाँच चाहिन्छ: होस्टनाम, ठेगाना, UDP पोर्ट र त्यहाँ पुग्न प्रयोग गरिने परिवार। पुरानो ठेगाना वा गलत पोर्टले सन्देशको सट्टा मौनता दिन्छ।

बाह्य UDP बाटोमा नजर राख्नुहोस्

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

ss -lunp | grep 51820
sudo tcpdump -ni eth0 udp port 51820
wg show wg0 endpoints
conntrack -L -p udp | grep 51820

सुरुवात देखाएर जवाफ नदेखाउने क्याप्चरले मेसिनबाहिर संकेत गर्छ, किनकि टाढाको छेउ या त सुन्दैन, या फिल्टर भएको छ, या गलत ठेगाना दिइएको छ। केही नदेखाउने क्याप्चरको अर्थ प्याकेट कहिल्यै बाहिर गएन, जसले तपाईंलाई मार्ग र खेलमा रहेको कुनै पनि सकेट चिन्हतर्फ फर्काउँछ। दुवै छेउ व्यवस्थापन गर्दा सामान्य क्याप्चरको सट्टा सर्भरमा साँघुरो क्याप्चरसँग समय-छापद्वारा प्रयासलाई सहसम्बन्धित गर्नुहोस्। TCP पोर्ट परीक्षणले यहाँ केही प्रमाणित गर्दैन, किनकि प्रोटोकल UDP मात्र हो।

ह्यान्डशेक देखिनासाथ, सुरुङबाट एप्लिकेसन परीक्षण गर्नुहोस्, किनकि पूरा भएको आदानप्रदानले पहिचान र पहुँच प्रमाणित गर्छ, उपयोगी थ्रुपुट वा सही DNS होइन। परिवर्तनअघि र पछिको स्थिति आउटपुट राख्नुहोस्, र फरक तपाईंको प्रमाण बन्नेछ।