हेअरपिन 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 कडून काय अपेक्षित आहे याचा संदर्भ आहेत, आणि हे वैशिष्ट्य नसलेला राउटर सामान्यपणे का वागतो हे स्पष्ट करतात. बाहेरील जग पुनरुत्पादित करू शकत नाही अशी स्थानिक अयशस्वीता उलटे सिद्ध होईपर्यंत भाषांतराचा प्रश्न आहे, म्हणून ती त्याच पद्धतीने तपासा.