WireGuard ह्यान्डसेक सफल हुन्छ, तर कुनै जवाफ फर्केर आउँदैन

हालैका ह्यान्डसेकहरू राम्रो समाचार हुन्, र मानिसहरूले लेख्न चाहने वाक्यभन्दा धेरै सानो दाबी हो। दुवै पक्षले प्रमाणित ह्यान्डसेक सन्देशहरू आदानप्रदान गरे। अनुप्रयोग प्याकेटले अझै पनि आफ्नो आन्तरिक गन्तव्यमा पुगेर फर्कनुपर्छ।

स्वस्थ नियन्त्रण तल्ला र मौन डेटा तल्लाबीचको यही खाडल यहाँ पूरै विषय हो। तिनै काउन्टरका दुई पढाइले तपाईं त्यसको कुन पक्षमा हुनुहुन्छ भनी बताउँछन्।

ह्यान्डसेकले कुञ्जी प्रमाणित गर्छ, डेलिभरी होइन

WireGuard ह्यान्डसेक प्रमाणीकरणसहितको कुञ्जी सम्झौता हो। दुवै पक्ष एकअर्कासम्म पुग्न र मान्य कुञ्जी राख्न सकेपछि यो सफल हुन्छ। राउटिङ, फायरवाल नीति र गन्तव्य आफैं ह्यान्डसेकले कहिल्यै नसोध्ने प्रश्नहरू हुन्।

त्यसैले टनेल पूर्ण रूपमा स्थापित हुन सक्छ जबकि त्यसभित्रको हरेक प्याकेट फालिन्छ। गलत राउट गरिएको आन्तरिक प्याकेट र अर्को बाटो लिने जवाफ क्लाइन्टको तर्फबाट उस्तै देखिन्छन्।

एउटा आन्तरिक ठेगाना नै पूरै परीक्षण हो

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

त्यसपछि क्लाइन्टले छान्ने मार्ग हेर्नुहोस्। बढी विशिष्ट स्थानीय मार्गले WireGuard लाई सोध्नुअघि नै प्याकेट अन्तै पठाउन सक्छ, र घरको LAN दूरको दायरासँग ओभरल्याप हुँदा यो सधैं हुन्छ।

ip route get 10.30.8.10
ip -4 addr show wg0
ip route show table all | grep -w wg0

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

काउन्टर प्रमाण हुन्, फैसला होइन

wg show ले प्रत्येक पक्षका लागि पठाइएका र प्राप्त बाइट जनाउँछ, र ती दुई संख्या स्वतन्त्र रूपमा चल्छन्। एउटा पढाइ लिनुहोस्, एउटा अनुमत अनुरोध गर्नुहोस्, त्यसपछि त्यही मिनेटभित्र अर्को पढाइ लिनुहोस्।

wg show wg0 transfer
wg show wg0 latest-handshakes
ping -c 4 10.30.8.10
wg show wg0 transfer

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

निश्चित बाइट संख्यापनि सफलताको सीमा होइन। काउन्टरका मान ट्राफिकको पछि लाग्छन्, र एउटा संख्यालाई स्वास्थ्यको प्रमाण मान्नु आत्मविश्वासी अर्थहीनता उत्पन्न गर्छ।

सामुको पक्षले फर्कने प्याकेट आफैं जाँच्छ

दूरको पक्षले आन्तरिक प्याकेट तब मात्र स्वीकार्छ जब स्रोत त्यो पक्षको allowedips भित्र पर्छ। पठाउनेमा भएको मार्ग पर्याप्त हुँदैन। प्राप्तकर्तामा स्रोत प्रविष्टि नभए फर्कने ट्राफिक मौन रूपमा फालिन्छ।

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

प्रयोग इमानदार राख्नुहोस्

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

सानो सफल आदानप्रदानले पनि सबै मार्ग समस्या हटाउँदैन। ठूला प्याकेट जहाँ साना जान्छन् त्यहाँ असफल हुन सक्छन्, र आकार वा प्रोटोकलसँग मिल्ने फिल्टर भारमुनि फरक व्यवहार गर्न सक्छ।

ह्यान्डसेकलाई ज्ञात-कार्यरत चरण मानी त्यहीँबाट अगाडि बढ्नुहोस्। अर्को उपयोगी प्रमाण भनेको एउटा आन्तरिक अनुरोध कहाँ रोकिन्छ भन्ने हो, नयाँ कुञ्जी समूह र अर्को अनुमानको चरण होइन।