WireGuard सर्भरले पहिले पठाएपछि मात्र काम गर्छ: अन्त बिन्दुको ज्ञान

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

अन्त बिन्दुको ज्ञान, पहुँच क्षमता होइन

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

wg show त्यो चित्रका दुवै पक्ष प्रिन्ट गर्छ, र आउटपुटमा अन्त बिन्दु नभएको पियरले आफ्नो सार्वजनिक कुञ्जी र अनुमति दिइएका प्रिफिक्स जतिसुकै सही भए पनि केही सुरु गर्न सक्दैन। कुनै पनि नियम बदल्नुअघि ग्राहकको दृष्टिकोण सर्भरसँग तुलना गर्नुहोस्, किनभने कसलाई के थाहा छ भन्नेमा दुवै प्रायः सहमत हुँदैनन्।

पियरले अन्त बिन्दु कसरी सिक्छ

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

wg का लागि उपकरणको कागजातले त्यो अद्यावधिक वर्णन गर्छ, र यसको वरिपरि डिजाइन गर्ने हो भने एकचोटि पढ्न योग्य छ।

स्थिति भएको अनुवादले आफ्नै दिशा थप्छ

UDP अनुवाद गर्ने गेटवेबाट जाँदा, गेटवेले देखेको पहिलो प्याकेटका लागि स्थिति बनाउँछ। RFC 4787 त्यो व्यवहार र अन्ततः म्यापिङ हटाउने समय-सीमाहरू वर्णन गर्छ। निष्क्रिय म्यापिङ सकिन्छ, र टाढाको पट्टिबाट आउने आगमन प्याकेट त्यसपछि होस्टसम्म पुग्नुअघि गेटवेले फ्याँक्छ। बिहानभर काम गरेको सुरुङ ठ्याक्कै यही कारण दिउँसो जवाफ दिन बन्द गर्छ।

यो उही दिशात्मक लक्षण उत्पन्न गर्ने दोस्रो र स्वतन्त्र संयन्त्र हो। अन्त बिन्दुको ज्ञान र अनुवाद स्थिति दुवै सही हुनुपर्छ, र एउटा सुधार्दा अर्को सुध्रिँदैन।

तपाईंले साँच्चै चाहेको दिशा कन्फिगर गर्नुहोस्

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

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

ट्रिगर अघि र पछिको स्थिति तुलना गर्नुहोस्

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

wg show
conntrack -L -p udp 2>/dev/null | grep 51820
tcpdump -ni any -c 20 'udp port 51820'
ip route get 198.51.100.7

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