हेयरपिन NAT: भित्रबाट VPN इन्डपोइन्ट किन असफल हुन्छ

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

प्याकेट बाहिर जान्छ र फेरि भित्र आउँछ

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

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

RFC 4787 ले यो अवस्थामा NAT बाट अपेक्षित व्यवहारको वर्णन गर्छ, र छोटो संस्करण यो हो कि यो सिद्धान्ततः निर्दिष्ट भएको ठाउँमा पनि व्यवहारमा वैकल्पिक छ। केही राउटरले यो सेटिङलाई NAT loopback भन्छन्, अरूले हेयरपिन NAT वा NAT reflection भन्छन्, र केहीले केही पनि देखाउँदैनन्। जुन राउटरमा यो छैन त्यो गलत कन्फिगर गरिएको होइन; त्यो सामान्य काम गर्दैछ, र समाधान अन्तै छ। स्थानीय परीक्षा असफल भयो भनेर सार्वजनिक फर्वार्डिङ नियम गलत छ भन्ने निष्कर्ष ननिकाल्नुहोस्।

जाँच 1: दुवै मार्ग अलग-अलग जाँच्नुहोस्

LAN बाहिरबाट वास्तविक प्रयोगकर्ताले प्रयोग गर्ने त्यही प्रोफाइलसँग जोडिनुहोस् र सत्र स्थापना भएको पुष्टि गर्नुहोस्। भित्रबाट त्यही प्रोफाइलसँग सार्वजनिक ठेगानामा जोडिनुहोस् र ठ्याक्कै त्रुटि तथा समय नोट गर्नुहोस्।

ठ्याक्कै स्थानीय परीक्षाले होस्टनाम राख्छ र केवल ठेगाना बदल्छ: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ अनुरोध सार्वजनिक ठेगानामा पठाउँछ र सही सर्भर नाम प्रस्तुत गर्छ। यसले नाम-समाधानको समस्यालाई अनुवादको समस्याबाट अलग गर्छ, र ती एउटै नाम क्याफेबाट चल्दा सजिलै गडबडिन्छन्। क्लाइन्ट TCP जडानमा असफल हुन्छ कि पछि TLS मा भन्ने नोट गर्नुहोस्, किनकि पहिलोले अनुवादतर्फ र दोस्रोले पहिचानतर्फ संकेत गर्छ।

जाँच 2: सर्भरले के देख्छ पढ्नुहोस्

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

जडान क्लाइन्टको ठेगानाबाट नभई राउटरको LAN ठेगानाबाट आएको छ भने हेयरपिनिङ भइरहेको छ र स्रोत पुनः लेखिएको छ। यो कार्यरत कन्फिगरेसन हो, खराबी होइन।

जाँच 3: बाहिरी मार्गलाई नछोई सुधार्नुहोस्

तीन समर्थित रूप छन्, प्रभावको त्रिज्या बढ्दो क्रममा। सबैभन्दा साँघुरो विभाजित DNS हो: आन्तरिक रेकर्ड प्रकाशित गर्नुहोस् ताकि त्यही सर्भर नाम LAN का क्लाइन्टका लागि आन्तरिक ठेगानामा समाधान होस्, जसले सार्वजनिक मार्ग पूर्ण रूपमा बचाउँछ। अर्को राउटरको कागजात गरिएको loopback वा reflection विकल्प सक्षम गर्ने, यदि छ भने, र त्यसलाई यो सेवामा मात्र लागू गर्ने हो। सबैभन्दा फराकिलो राउटरमा source-NAT नियम हो जसले LAN बाट आउने ट्राफिकलाई सर्भरतर्फ पुनः लेख्छ ताकि जवाफ राउटरबाट फर्कियोस्; Linux राउटरमा त्यो सर्भरको ठेगाना र पोर्टसँग मिल्ने MASQUERADE नियम POSTROUTING हो। तीनैले बाहिरी मार्ग अछूत राख्छन्, र त्यही गुण जोगाउनु छ।

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

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

जाँच 4: पछि दुवै मार्ग प्रमाणित गर्नुहोस्

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

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