WireGuard ह्यान्डशेक चल्छ, सेवा चल्दैन

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

जुन पहिलो मिल्दैन त्यहीँ रोक्नुहोस्, र बाँकीका लागि नियम नथप्नुहोस्।

ह्यान्डशेकले टनेल मात्र प्रमाणित गर्छ

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

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

सुन्ने र मार्ग पढ्नुहोस्

क्लाइन्टमा सर्भरको टनेल ठेगाना टनेलमा रुट हुन्छ भनी पुष्टि गर्नुहोस्। सर्भरमा क्लाइन्टले प्रयोग गर्ने ठेगानामा सकेट छ र त्यसपछिको प्रक्रिया इच्छित नै हो भनी पुष्टि गर्नुहोस्।

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

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

क्लाइन्टले प्रयोग गर्ने ठेगानालाई सर्भरले टनेल इन्टरफेसमा वास्तवमै राखेको ठेगानासँग तुलना गर्नुहोस्। कुनै पनि तर्फको पुरानो कन्फिगरेसनले त्यस्तो ठेगाना नभएको सहकर्मीतिर सही रूपमा रुट हुने अनुरोध उत्पन्न गर्छ।

स्थानीय इनपुटका लागि नियम लागू गर्नुहोस्, फर्वार्डिङका लागि होइन

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

होस्ट खोल्नुको सट्टा इच्छित सेवातर्फ एउटै अनुमत पोर्टसँग परीक्षण गर्नुहोस्। त्यसपछि एप्लिकेसनको आफ्नै अधिकृतता जाँच्नुहोस्: अनुमति सूची, खाता आवश्यकता वा कुनै निश्चित होस्टनाममा बाँधिएको हुनुले नेटवर्कले सफलतापूर्वक पुर्याएको अनुरोध अस्वीकार गर्न सक्छ।

प्रमाणपत्र जाँचहरू यथावत् राख्नुहोस्। अप्रत्याशित प्रमाणपत्र पहिचान कुन होस्टले जवाफ दियो भन्ने जानकारी हो, टार्नुपर्ने बाधा होइन। त्यसमाथि क्लिक गरेर अगाडि बढ्दा गलत सेवा पहिचान गर्ने एक मात्र सुराग लुक्छ।

नाम, आकार र पहिचानका असफलता अलग गर्नुहोस्

ठेगानाले चल्ने तर नामले असफल हुने सेवा DNS समस्या हो, र सुधार फायरवालमा होइन, क्लाइन्टमा पठाइने रिजोल्भर कन्फिगरेसनमा हुन्छ। साना अनुरोधको जवाफ दिने तर ठूला प्रतिक्रियामा अड्किने सेवाले प्याकेट आकार र MTU संकेत गर्छ, जो पूर्ण रूपमा फरक अनुसन्धान हो।

गलत होस्ट नाम दिने HTTPS त्रुटिले सामान्यतया अनुरोध अर्को सेवासम्म पुगेको अर्थ दिन्छ, प्रायः प्रोक्सी वा अर्को सुन्नेले त्यो पोर्ट ओगटेको हुनाले। प्रमाणपत्रको विषय पढ्नुहोस् र तपाईं पुग्न चाहेको होस्टसँग तुलना गर्नुहोस्। यो तुलनामा केही खर्च लाग्दैन र प्रायः अनुसन्धान सकिन्छ।

कुन जाँच बिन्दु असफल भयो लेख्नुहोस्: सकेट, इनपुट नियम वा एप्लिकेसन नीति। त्यो एक लाइनले नेटवर्क खराबीलाई अधिकृतता निर्णयबाट अलग गर्छ। अर्को व्यक्तिले कहिल्यै समस्या नभएका पोर्ट खोल्नबाट पनि यसले रोक्छ।