एउटै मार्ग प्रमाणित गर्ने दुई पियरको WireGuard परीक्षण कसरी बनाउने

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

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

कुञ्जी, ठेगाना र एउटै एन्डपोइन्ट

हरेक प्रणालीमा कुञ्जी जोडी बनाउनुहोस् र तिनीहरूबीच सार्वजनिक आधा भाग मात्र सार्नुहोस्। wg genkey | tee privatekey | wg pubkey > publickey दस्तावेज गरिएको एक-लाइन आदेश हो, र यसले निजी कुञ्जीलाई पछि सुरक्षित गर्न सकिने फाइलमा छोड्छ। तपाईंको अरू कुनै पनि कन्फिगरेसनमा नदेखिने दायराबाट टनेल ठेगाना छान्नुहोस्, जस्तै 10.99.0.1/24 र 10.99.0.2/24। कुन ठेगाना कुन मेसिनको हो लेख्नुहोस्, किनकि पछिको हरेक जाँच त्यही म्यापिङमा निर्भर छ।

निजी कुञ्जीहरू कहिल्यै यात्रा गर्दैनन्। यदि परीक्षणलाई एउटा अर्को पट्टि प्रतिलिपि गर्न आवश्यक पर्यो भने परीक्षण पहिले नै बिग्रिसकेको छ। जब दुई प्रणाली NAT पछाडि हुन्छन्, कम्तीमा एउटालाई पुग्न सकिने UDP पोर्ट चाहिन्छ भने अर्कोले त्यसतर्फ सङ्केत गर्ने Endpoint बोक्छ, र सार्वजनिक ठेगाना र पोर्ट तपाईंको टिप्पणीमा हुनुपर्छ, 51820 बारेको अनुमानमा होइन।

फरक बाह्य पोर्टमा म्याप गर्ने पोर्ट फर्वार्डिङ Endpoint मिल्नेसम्म राम्रोसँग चल्छ। यहाँको असमझदारीले त्रुटिको सट्टा नीरवता उत्पन्न गर्छ, त्यसैले तारमा डिबग गर्नुअघि कागजमा जाँच्नु उपयुक्त हुन्छ।

wg सँग सम्बन्धित फिल्ड र नसम्बन्धित

मुख्य फिल्ड समूह सानो छ: Interface मुनि PrivateKey र ListenPort, Peer मुनि PublicKey, AllowedIPs र Endpoint। Address र DNS wg आफैंलाई होइन, wg-quick लाई सम्बन्धित छन्, र त्यही कन्फिगरेसन अर्को उपकरणमा जाने क्षणमा यो भिन्नताले डस्छ।

[Interface]
PrivateKey = <peer-a-private>
Address = 10.99.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <peer-b-public>
AllowedIPs = 10.99.0.2/32
Endpoint = 203.0.113.10:51820

AllowedIPs ले एकैचोटि दुई काम गर्छ। कुन गन्तव्य टनेलभित्र जान्छन् छान्छ, र आउँदा ती स्रोत ठेगाना प्रयोग गर्न पियरलाई अधिकार दिन्छ। त्यसैले अर्को पट्टिको ऐना प्रविष्टिले तपाईंको टनेल ठेगाना ठ्याक्कै उल्लेख गर्नुपर्छ; गलत पियरका लागि /32 रुटिङ समस्याका रूपमा पढिन्छ र अधिकार समस्याजस्तै व्यवहार गर्छ। WireGuard द्रुत सुरुवात फिल्ड नाम तुलना गर्न चाहनुहुन्छ भने त्यही दुई-पियर आकार मानक शब्दावलीसहित देखाउँछ।

आइकनको सट्टा ह्यान्डसेक पढ्ने

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

दुई असफलताले फरक अनुसन्धान सङ्केत गर्छन्। ह्यान्डसेक बिल्कुल नहुनु कुञ्जी अमिल्दो, गलत Endpoint, अवरुद्ध UDP वा ह्यान्डसेक नै खसाल्ने फायरवालतिर सङ्केत गर्छ। ह्यान्डसेक सफल भई डेटा कतै नजानु AllowedIPs, टनेल ठेगानामा नसुन्ने सेवा, वा LAN का लागि पोर्ट स्वीकार गर्ने तर टनेल इन्टरफेसका लागि नगर्ने होस्ट फायरवालतिर सङ्केत गर्छ। यी प्रणालीका फरक आधा भाग हुन्, र नियम बदल्नुअघि आधारले तिनलाई अलग्याउँछ।

एउटा अनुमति दिइएको सेवा प्रमाणित गर्ने, त्यसपछि उल्टो दिशा

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

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

आधारलाई सन्दर्भका रूपमा राख्ने

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

आइकन मात्र हरियो बनाउने आधारले अर्को असफलता कुन थपले निम्त्यायो भन्नेबारे केही भनेको छैन। एकमात्र अनुमति दिइएको मार्गलाई सन्दर्भका रूपमा चलिरहन दिनुहोस्, र पछिका हरेक परिवर्तन त्यसैको तुलनामा मापन गरिन्छ।