ASA VPN hairpin: एका इंटरफेसवरून दोन टनेलचे राउटिंग
रिमोट वापरकर्त्याचा रहदारी ज्या ASA इंटरफेसवरून आला त्याच इंटरफेसवरून बाहेर जाऊ शकतो, पण hairpin परवानगी, टनेलची व्याप्ती, NAT आणि ACL या चार वेगळ्या निर्णय आहेत.
एक रिमोट वापरकर्ता 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 दृश्यपणे वेगळे ठेवतात, आणि तोच उतरवण्याजोगा मानसिक नमुना आहे.