ASA VPN hairpin: एक इंटरफ़ेस से दो टनल का रूटिंग

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

एक पैकेट, दो टनल

प्रवाह का पालन करें और संचालन का क्रम रहस्यमय होना बंद कर देता है। पैकेट रिमोट-एक्सेस टनल के भीतर पहुंचता है, डिक्रिप्ट होता है और क्लाइंट पूल से स्रोत वाला साधारण IP पैकेट बन जाता है। फिर ASA उसे रूट करता है, साइट-टू-साइट crypto ACL से मिलाता है, दोबारा एन्क्रिप्ट करता है और बाहरी इंटरफ़ेस से शाखा की ओर भेजता है।

नीचे दिए गए पते उदाहरण हैं, लेकिन आकार मायने रखता है: स्रोत पूल है, ASA का आंतरिक LAN नहीं।

remote client 10.77.0.20
  -> remote-access tunnel, terminated on ASA outside
  -> decrypted, routed, matched against site-to-site policy
  -> site-to-site tunnel, sent from ASA outside
  -> branch host 10.60.20.10

इससे दो बातें निकलती हैं। क्लाइंट को अपने रिमोट-एक्सेस कनेक्शन के जरिए शाखा के प्रीफ़िक्स के लिए रूट चाहिए, यानी split-tunnel या भेजी गई रूट सूची में इसे शामिल करना होगा। और शाखा को पता होना चाहिए कि ट्रैफ़िक 10.77.0.20 पर या उस पते पर कैसे लौटाया जाए जिसे आपके NAT डिज़ाइन ने बदला है।

hairpin अनुमति वैश्विक है

जिस कमांड की ओर लोग बढ़ते हैं वह है same-security-traffic permit intra-interface. यह ट्रैफ़िक को उसी इंटरफ़ेस में आने और बाहर जाने देता है, जो ठीक वही है जो इस पथ को चाहिए। यह एक वैश्विक सेटिंग भी है: इसे सक्षम करने से उन अन्य प्रवाहों का व्यवहार बदल जाता है जो संयोगवश उसी इंटरफ़ेस से दो बार गुजरते हैं।

इसीलिए यह डिबगिंग सत्र के बजाय परिवर्तन रिकॉर्ड में आता है। पूछें कि बॉक्स पर और क्या अब उसी इंटरफ़ेस का रास्ता ले सकता है, और क्या उसमें से किसी को लेना चाहिए। अतिथि नेटवर्क या ओवरलैपिंग पार्टनर टनल वाले व्यस्त किनारे पर जवाब अपने आप नहीं नहीं होता। कारण सेटिंग के बगल में लिखें, क्योंकि अगला इंजीनियर कमांड पाएगा, बातचीत नहीं।

सुरक्षा का दायरा और NAT अलग हैं

साइट-टू-साइट टनल उसकी रक्षा करती है जिसे उसका crypto ACL चुनता है। अगर वह ACL ASA के आंतरिक सबनेट को स्रोत के रूप में नाम देता है, तो रिमोट-एक्सेस पूल सुरक्षित नहीं है और पैकेट या तो गिरा दिया जाएगा या खुले रूप में भेजा जाएगा, यह प्लेटफ़ॉर्म के बेमेल ट्रैफ़िक व्यवहार पर निर्भर है। जब डिज़ाइन पूल के पते बनाए रखे तो पूल को सुरक्षित प्रवाह में जोड़ें।

फिर NAT तय करता है कि पूल का पता बचता है या नहीं। Identity NAT उसे बनाए रखता है, और शाखा 10.77.0.20 को स्रोत के रूप में देखती है। अनुवाद अनुबंध बदल देता है: शाखा अब ट्रैफ़िक अनुवादित पते पर लौटाती है, और उसकी अपनी नीति को इसे स्वीकार करना होगा। नियमों का क्रम तय करता है कि crypto ACL अनुवाद से पहले मेल खाता है या बाद में, इसलिए यह मानने के बजाय कि कौन जीतता है, प्रभावी प्रवाह पढ़ें।

एक ट्रांज़िट केस काम कराने के लिए सामान्य इंटरनेट PAT नियम मत हटाइए। लक्षित छूट या जानबूझकर बनाया गया identity नियम, बाहर जाने वाली नीति में सेंध बनाने से समझाना और वापस लेना आसान है।

एन्क्रिप्शन अधिकृतता नहीं है

काम करती टनल केवल यह साबित करती है कि दो पक्ष कुंजियों और सिलेक्टरों पर सहमत हैं. यह नहीं बताती कि यह उपयोगकर्ता उस सेवा तक पहुंच सकता है या नहीं। रिमोट-एक्सेस कनेक्शन से जुड़े VPN फ़िल्टर या समूह नीति को अभी भी शाखा के गंतव्य और पोर्ट की अनुमति देनी होगी, और बाहरी पथ पर इंटरफ़ेस ACL अभी भी लागू है।

जवाब को दोनों दिशाओं में जांचें। ऐसा कनेक्शन जो सफल हो जबकि पड़ोसी सेवा को विफल होना चाहिए, एक सफल ping से अधिक जानकारीपूर्ण है, क्योंकि यह दिखाता है कि नीति चयनात्मक है, पूरी तरह खुली नहीं। अगर जिस परीक्षण को अस्वीकार होना चाहिए वह सफल हो जाए, तो दोष टनल का नहीं; नीति का है। दोनों परिणाम परिवर्तन रिकॉर्ड में रखें ताकि अगले व्यक्ति को पता हो कि कौन-सा व्यवहार इरादा था।

hairpin या दूसरा इंटरफ़ेस

hairpin ट्रांज़िट डिज़ाइन को छोटा रखता है और एक वैश्विक सेटिंग का खर्च उठाता है। अलग इंटरफ़ेस, या अपने वर्चुअल इंटरफ़ेस वाली रूट-आधारित टनल, ट्रांज़िट पथ को अलग करती है और आपको प्रति-इंटरफ़ेस नीति देती है, बदले में एड्रेसिंग और एक और crypto map या प्रोफ़ाइल के खर्च पर। कोई भी अधिक सही नहीं है; वे अलग-अलग तरह से विफल होते हैं।

रूट-आधारित डिज़ाइन एक अलग व्यवस्था है, उसी कॉन्फ़िगरेशन पर एक चेकबॉक्स नहीं। अगर आप उसकी ओर बढ़ते हैं, तो ऊपर की नीति-आधारित crypto ACL चर्चा लागू होना बंद कर देती है और रूटिंग तालिका चयन का काम करने लगती है।

असली क्लाइंट से सत्यापित करें

ASA से शुरू की गई जांच का स्रोत पता अलग होता है और वह पूल-से-शाखा पथ का अभ्यास नहीं करेगी। पांच-टपल की जांच के लिए packet-tracer का उपयोग करें, फिर वास्तविक रिमोट क्लाइंट से असली कनेक्शन खोलें, क्योंकि ट्रेसर अनुकरण करता है और क्लाइंट के अपने रूटिंग और नीति का स्थान नहीं लेता।

नियोजित परिवर्तन के बाद उस सेवा से जुड़ें जिसे काम करना चाहिए, फिर उससे जिसे अस्वीकार होना चाहिए, और फिर शाखा का वापसी मार्ग पुष्टि करें। Cisco के VPN hairpin NAT उदाहरण intra-interface अनुमति, NAT और ACL को दृश्य रूप से अलग रखते हैं, और यही वह मानसिक मॉडल है जिसकी नकल करने लायक है।