स्प्लिट टनल किसी सार्वजनिक होस्ट को ASA के NAT नियमों से छूट नहीं देता

split-include रूट सार्वजनिक होस्ट को टनल में खींच लेता है, जहाँ ASA को उसे hairpin करना और स्रोत का अनुवाद करना पड़ता है। दोनों में से कोई भी चरण छोड़ें और फ़्लो टूट जाता है।

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

सार्वजनिक पते पर मौजूद एक साझेदार सेवा, जो आपके मुख्यालय का पता देखने पर अड़ी हो, इस कहानी को तोड़ने के लिए काफ़ी है।

मिथक: स्प्लिट टनल फ़ायरवॉल को रास्ते से हटा देता है

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

क्लाइंट राउटर नहीं बना। उसने वही नीति मानी जो आपने उसे दी थी।

split-include रूट वास्तव में क्या करता है

Cisco ASA रिमोट-एक्सेस सेटअप में ग्रुप नीति split-tunnel-policy tunnelspecified और एक split-tunnel-network-list रखती है, जो एक मानक ACL का नाम देता है। उस ACL की हर permit पंक्ति एक गंतव्य है जिसे क्लाइंट को टनल में भेजना चाहिए, और बाकी सब स्थानीय डिफ़ॉल्ट रूट का उपयोग करता रहता है।

एक होस्ट जोड़ना एक ही पंक्ति है, और यही बदलाव का वह इकलौता हिस्सा है जो क्लाइंट देख सकता है: access-list RA-SPLIT standard permit host 203.0.113.20।

उसके बाद क्लाइंट को फिर से कनेक्ट करें। नीति कनेक्ट के समय बदली जाती है, इसलिए स्थापित सत्र पुरानी सूची रखता है और बदलाव को ऐसा दिखाता है जैसे उसने कुछ न किया हो।

पैकेट उसी इंटरफ़ेस पर आता और जाता है

अब डिक्रिप्शन के बाद फ़्लो को ट्रेस करें। पैकेट VPN टनल से बाहरी इंटरफ़ेस पर आया, उसका गंतव्य एक सार्वजनिक पता है, और रूटिंग तालिका उसे उसी बाहरी इंटरफ़ेस से वापस इंटरनेट की ओर भेजती है। एक इंटरफ़ेस पर आने और जाने वाला ट्रैफ़िक छोड़ दिया जाता है, जब तक ASA को अनुमति न दी जाए, और यही same-security-traffic permit intra-interface करता है। इसके बिना कनेक्शन ऐसे विफल होता है जो रूटिंग समस्या जैसा दिखता है और है नहीं।

यह सेटिंग वैश्विक है। यह हर उस फ़्लो के लिए hairpinning की अनुमति देती है जिसे इसकी ज़रूरत है, केवल इस साझेदार होस्ट के लिए नहीं, इसलिए यह किसी समीक्षित बदलाव का हिस्सा होनी चाहिए, तेज़ परीक्षण का नहीं।

गंतव्य-सीमित PAT वैकल्पिक क्यों नहीं है

डिक्रिप्ट किए गए पैकेट का स्रोत पता अब भी क्लाइंट का VPN पता है, आम तौर पर 10.77.0.0/24 जैसे पूल से। उस पते का सार्वजनिक इंटरनेट पर कोई रूट नहीं है, इसलिए साझेदार या तो कभी जवाब नहीं देता या कहीं का जवाब नहीं देता।

अनुवाद स्रोत को ठीक करता है और गंतव्य को अछूता छोड़ता है। चूँकि ऑब्जेक्ट पहले से कहीं और परिभाषित हैं, इस गंतव्य तक सीमित मैनुअल नियम का यह रूप है:

same-security-traffic permit intra-interface

object network RA_POOL
 subnet 10.77.0.0 255.255.255.0
object network PARTNER_HOST
 host 203.0.113.20

nat (outside,outside) source dynamic RA_POOL interface destination static PARTNER_HOST PARTNER_HOST

destination static वाला हिस्सा मायने रखता है। उसे हटाने से नियम एक व्यापक अनुवाद बन जाता है जो इरादे से कहीं अधिक ट्रैफ़िक से मेल खा सकता है, और क्रम में पहले आने वाला व्यापक identity नियम इसे पूरी तरह हरा सकता है। यह मानने से पहले कि आपका नियम ही मेल खाता है, show nat detail और अनुभागों का क्रम जाँचें।

इंटरफ़ेस PAT का यह भी अर्थ है कि साझेदार को ASA का इंटरफ़ेस पता दिखता है, जिसका ऊपर की ओर फिर से अनुवाद हो सकता है। अगर अनुबंध किसी पते का नाम लेता है, तो उसे एक हॉप पर नहीं, सिरे से सिरे तक सत्यापित करें।

सही परीक्षण गंतव्य से इसे साबित करें

साझेदार होस्ट का ही उपयोग करें, कोई सामान्य what-is-my-ip पेज नहीं। वह पेज लगभग निश्चित रूप से split सूची से बाहर है, इसलिए वह आपका स्थानीय इंटरनेट पता बताता है और इस रास्ते के बारे में कुछ नहीं कहता। साझेदार सेवा से नया कनेक्शन खोलें और उनसे पूछें कि उन्होंने कौन-सा स्रोत देखा, या packet-tracer input outside tcp 10.77.0.10 12345 203.0.113.20 443 detailed चलाएँ और NAT तथा रूटिंग चरण पंक्ति-दर-पंक्ति पढ़ें। क्लाइंट से traceroute कमज़ोर जाँच है, क्योंकि वह वह रास्ता दिखाता है जो पहले ही हो चुका है, न कि वह नीति जिसने उसे चुना।

फिर जाँचें कि क्या नहीं बदलना चाहिए। एक सामान्य वेबसाइट को अब भी स्थानीय कनेक्शन से बाहर जाना चाहिए, और टनल सूची में मौजूद निजी संसाधन अब भी पहुँच में होना चाहिए। जो बदलाव साझेदार को ठीक करे और इन दोनों में से किसी एक को तोड़े, वह अलग बग है।

इस डिज़ाइन का काम करने वाला संस्करण छोटा है: split ACL में एक होस्ट, hairpin अनुमति, गंतव्य-सीमित एक PAT नियम। कहानी में बाकी सब मिथक है।

संबंधित लेख