हेयरपिन 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 से क्या अपेक्षित है इसका संदर्भ हैं, और समझाती हैं कि इस सुविधा के बिना राउटर सामान्य व्यवहार क्यों करता है। बाहरी दुनिया जिसे दोहरा नहीं सकती ऐसी स्थानीय विफलता विपरीत सिद्ध होने तक अनुवाद का प्रश्न है, इसलिए इसे उसी तरह जाँचें।