WireGuard मा होस्ट उपसर्ग: एउटा ठेगाना किन काम गर्छ र बाँकी गर्दैन

टनेल चालु छ, handshake हरेक दुई मिनेटमा हुन्छ, र अर्को तिर ठ्याक्कै एउटा ठेगानाले जवाफ दिन्छ। पियरको टनेल ठेगानामा ping काम गर्छन्; त्यसको पछाडि केही पनि काम गर्दैन। कसैले इन्टरफेसको कन्फिगरेसन पढ्छ, होस्ट उपसर्ग देख्छ र मास्क गलत छ भन्ने निष्कर्ष निकाल्छ। यसलाई /24 सम्म फैलाउँदा ping केही बेर सुधार्छ र त्यसपछि अरू केही बिगार्छ। उपसर्ग कहिल्यै कारण थिएन, र हराएको मार्ग त्यो होइन जुन मास्कले नियन्त्रण गर्छ।

इन्टरफेस उपसर्गले वास्तवमा के बनाउँछ

Linux मा इन्टरफेसमा ठेगाना दिँदा त्यो उपसर्गका लागि जोडिएको मार्ग बन्छ। होस्ट उपसर्ग दिनुभयो भने जोडिएको मार्गले एउटा ठेगाना ढाक्छ। /24 दिनुभयो भने त्यसले 256 ढाक्छ, र तीमध्ये हरेक अब त्यो लिङ्कमा पुग्न सकिने मानिन्छ।

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

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

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

AllowedIPs एउटै नाममुनि दुई नियम हुन्

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

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

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

मार्ग कहाँबाट आउँछ

तपाईंले wg-quick प्रयोग गर्नुभयो भने, मार्गहरू तपाईंका लागि हरेक पियरको अनुमति सूचीबाट बनाइन्छ, जबसम्म तपाईंले Table = off सेट गर्नुभएको छैन र नियन्त्रण आफैं लिनुभएको छैन। यही उपकरणको अभिलेखित व्यवहार हो, र यही कारण हो कि स्पष्ट मार्ग निर्देशनबिना पनि कन्फिगरेसन काम गर्छ।

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

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

जब तपाईं यसलाई हातले चलाउनुहुन्छ, मार्ग एउटा लाइन हो र यसको आकार स्पष्ट छ: गन्तव्य इन्टरफेसबाट, गेटवे बिना किनकि लिङ्क बिन्दु-देखि-बिन्दु हो। यसलाई थप्नु खराब उपसर्गका लागि कुनै उपाय होइन; यो त्यस्तो डिजाइनको हराएको आधा भाग हो जसले रुटिङ आफैं लियो।

फराकिलो उपसर्गले पियर प्रविष्टि थप्दैन

लोभ्याउने सुधार भनेको ठेगाना /24 बनाउनु हो ताकि जोडिएको मार्गले सर्भरको स्थानीय नेटवर्क ढाकोस्। यो काम गरेजस्तो देखिन्छ, र काम गरेजस्तो देखिनुको कारण जोडिएको मार्ग अब मिल्नु हो, WireGuard ले नयाँ केही सिक्नु होइन।

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

क्रिप्टो पक्ष कुनै पनि हालतमा प्रभावित हुँदैन। WireGuard लाई पियर छान्न अनुमति सूचीमा गन्तव्य ढाक्ने प्रविष्टि अझै चाहिन्छ, र अर्को तिरलाई तपाईंको स्रोत स्वीकार गर्न त्यो ढाक्ने प्रविष्टि अझै चाहिन्छ। फराकिलो इन्टरफेस उपसर्ग यीमध्ये एउटै दिन सक्दैन।

केही बदल्नुअघि दुवै दिशा पुष्टि गर्नुहोस्

दुवै छेउ अलग-अलग लिनुहोस् र प्रत्येकले के भन्छ लेख्नुहोस्। क्लाइन्टमा मार्ग र पियर प्रविष्टि; सर्भरमा ऐनाको प्रतिबिम्ब र त्यसको आफ्नै फर्किने बाटो:

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

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

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