ASA hairpin: इन्टरनेट एक्जिट कि साइट-टु-साइट VPN लेग?

एउटै ASA पछाडिका दुई रिमोट-एक्सेस प्रयोगकर्ताले एउटै बाहिरी इन्टरफेसबाट ट्राफिक पठाउन सक्छन् र पूर्ण रूपमा फरक व्यवहार पाउन सक्छन्। एउटा सार्वजनिक वेबसाइटतर्फ जाँदै छ, त्यसैले प्याकेटलाई स्रोत अनुवाद र इन्टरनेट रुट चाहिन्छ। अर्को त्यही इन्टरफेसमा अन्त्य हुने साइट-टु-साइट टनेल पछाडिको सर्भरतर्फ जाँदै छ, त्यसैले प्याकेटलाई पहिचान, मिल्ने टनेल सिलेक्टर र क्लाइन्ट पूलतर्फ फर्कने मार्ग चाहिन्छ। एउटै इन्टरफेसको अनुमति दुवैका लागि पूर्वसर्त हो र कुनैका लागि समाधान होइन।

दुई लेग, एउटा इन्टरफेस

NAT नियम लेख्नुअघि कुन लेग बनाउँदै हुनुहुन्छ निर्णय गर्नुहोस्, किनकि नियमहरू एकअर्काका ठाउँमा प्रयोग गर्न मिल्दैन। लेग A क्लाइन्टबाट इन्टरनेटतर्फ हो: पूलको ठेगाना भित्र, अनुवादित सार्वजनिक ठेगाना बाहिर, त्यही इन्टरफेसबाट फर्केर। लेग B क्लाइन्टबाट अर्को IPsec पीयरको अर्को छेउको निजी प्रिफिक्सतर्फ हो: पूलको ठेगाना जोगाइन्छ, फेरि इन्क्रिप्ट हुन्छ र पूललाई कसरी जवाफ दिने थाहा हुनुपर्ने पीयरकहाँ पुर्‍याइन्छ।

दुवैलाई पहिले चाहिने कुरा एउटै इन्टरफेसको अनुमति हो। त्यो बिना ASA ले प्याकेट आएको इन्टरफेसबाटै अगाडि पठाउन इन्कार गर्छ, र असफलता नीतिको समस्याजस्तो नभई रुटिङको समस्याजस्तो देखिन्छ:

same-security-traffic permit intra-interface

त्यो एउटै लाइनले अगाडि पठाउने व्यवस्थालाई अनुमति दिन्छ, जसरी ASA NAT सन्दर्भ एउटै इन्टरफेसका मार्गहरूका लागि वर्णन गर्छ। यसले क्लाइन्ट रुट थप्दैन, स्रोतलाई अनुमति दिँदैन, ठेगाना अनुवाद गर्दैन वा IPsec सिलेक्टरमा वार्ता गर्दैन, त्यसैले यसपछि अझै तीन वा चार कुरा थप्ने अपेक्षा राख्नुहोस् र यसको स्वीकृतिलाई प्रगति ठान्नुहुन्न।

लेग A: क्लाइन्टलाई इन्टरनेट चाहिन्छ

इन्टरनेट एक्जिटका लागि प्याकेट यन्त्र छोड्नुअघि पूलको ठेगाना निजी हुन छोड्नुपर्छ। सामान्य PAT डिजाइनमा नियमले पूललाई बाहिरी इन्टरफेसको ठेगानामा अनुवाद गर्छ, र फर्कने अवस्थाले क्लाइन्टतर्फको प्रवाह पुनःस्थापित गर्छ:

object network VPN_POOL
 subnet 10.80.0.0 255.255.255.0
nat (outside,outside) after-auto source dynamic VPN_POOL interface route-lookup

त्यसपछि क्लाइन्टले साँच्चै ASA लाई त्यो ट्राफिक बोक्न भनेको छ भनी पुष्टि गर्नुहोस्। स्प्लिट-टनेल बहिष्कारले सार्वजनिक गन्तव्यलाई फोनको आफ्नै जडानमार्फत पठाउँछ, जुन ASA सम्म पुग्दैन, र कहिल्यै नपठाइएको प्याकेट कुनै NAT नियमले सुधार्दैन। समूह नीतिको स्प्लिट-टनेल सूचीलाई तपाईं जाँचिरहनुभएको गन्तव्यसँग तुलना गर्नुहोस्।

लेगको बाँकी सामान्य छ: बाहिरी इन्टरफेसबाट प्रयोगयोग्य पूर्वनिर्धारित वा विशेष रुट, प्रवाहलाई अनुमति दिने पहुँच नीति, र तपाईंले छान्नुभएको रिजोल्भर नीतिअनुसार ह्यान्डल गरिएको DNS। यहाँ route-lookup तलको जस्तै कारणले थप्नुहोस्, किनकि प्रवेश र निर्गम इन्टरफेस एकै छन्।

लेग B: क्लाइन्टलाई निजी साइट चाहिन्छ

यो लेग धेरै ठाउँमा असफल हुन्छ, त्यसैले क्रममा लेख्नुहोस्। पहिले क्लाइन्ट रुट: गन्तव्य प्रिफिक्स स्प्लिट-टनेल सूचीमा हुनुपर्छ, नत्र क्लाइन्टले यसलाई टनेलमा राख्दैन। दोस्रो टनेल सिलेक्टर: साइट-टु-साइट क्रिप्टो ACL ले पूल ठेगानादेखि टाढाको प्रिफिक्ससम्म समेट्नुपर्छ, स्थानीय LAN देखि टाढाको प्रिफिक्ससम्म मात्र होइन। तेस्रो पहिचान, ताकि पूलको ठेगाना बाटोमा इन्टरनेट PAT मा अनुवाद नहोस्।

nat (outside,outside) source static VPN_POOL VPN_POOL
    destination static SITE_PREFIX SITE_PREFIX route-lookup

टाढाको पक्ष त्यो भाग हो जुन मानिसहरूले जाँच्न बिर्सन्छन्। पीयरलाई पूलतर्फ फर्कने रुट र यसलाई समावेश गर्ने सिलेक्टर चाहिन्छ, र यसको आफ्नै नीतिले यसले देख्ने स्रोत ठेगानाहरूलाई अनुमति दिनुपर्छ. यदि साइटको सट्टा अनुवादित दृश्यबाट प्रयोग गरिन्छ भने त्यो वैध डिजाइन हो, तर त्यसपछि दुवै पीयर, दुवै सिलेक्टर र दुवै रुटिङ तालिकाले अनुवादित ठेगानाहरूमा सहमति जनाउनुपर्छ।

नियमहरूको क्रम पनि जाँच्नुहोस्। पहिचान नियममाथिको फराकिलो PAT नियमले निजी आदानप्रदानलाई पहिचान नियमको मूल्याङ्कन हुनुअघि नै अनुवाद गर्छ, र लक्षण NAT त्रुटि नभई मिल्ने SA नभएको साइट टनेल हुन्छ।

कुन लेग बनाउनुभयो भनी बताउने परीक्षण

कन्फिगरेसन पढेर आशा गर्नुको सट्टा ASA को आफ्नै मार्ग मूल्याङ्कन प्रयोग गर्नुहोस्। packet-tracer input outside tcp 10.80.0.25 40000 203.0.113.10 443 detailed एउटा प्रवाहका लागि NAT निर्णय, रुट र ACL नतिजा देखाउँछ; निजी गन्तव्यसँग यसलाई दोहोर्‍याउनुहोस्। NAT चरणले निजी-देखि-निजी प्रवाह पुनःलेख्छ भने, तपाईंले लेग B चाहिने प्याकेटका लागि लेग A बनाउनुभयो।

अझै दुई आदेशले खाली ठाउँ भर्छन्। show nat detail packet-tracer ले पछ्याएको नियम क्रम प्रिन्ट गर्छ, र show crypto ipsec sa तपाईंले अपेक्षा गर्नुभएको जोडीका लागि सिलेक्टर छ कि छैन देखाउँछ। छुटेको SA सिलेक्टर वा पीयर कन्फिगरेसनको कुरा हो, NAT नियमले सुधार्न सक्ने कुरा होइन।

प्रत्येक लेगलाई यसले सेवा गर्ने ट्राफिकले प्रमाणित गर्नुहोस्

लेग A लाई क्लाइन्टको सामान्य सार्वजनिक अनुरोधले स्वीकार गर्नुहोस्, र लेग B लाई साँच्चै अवस्थित निजी स्रोतको अनुरोधले स्वीकार गर्नुहोस्। त्यसपछि प्रत्येकलाई अस्वीकृत स्रोतसँग दोहोर्‍याउनुहोस्, किनकि “अनुमति दिइयो” र “पहुँच नीतिले स्वीकृत गर्‍यो” एउटै प्रमाण होइन, र हबबाट उठ्ने ping ले क्लाइन्ट मार्गमध्ये कुनैलाई पनि अभ्यास गर्दैन।

टिकटमा दुई परीक्षण रेकर्ड अलग राख्नुहोस्: स्रोत ठेगाना, गन्तव्य, मिलेको NAT नियम र नतिजा। अर्को प्रतिवेदनले “VPN बिग्रियो” भन्यो भने, त्यो जोडीले एक मिनेटभित्र कुन लेग पछाडि परेको हो भनी बताउँछ, र जवाफ सामान्यतया रुट वा सिलेक्टर हुन्छ, सबैले पहिले शंका गर्ने त्यही-इन्टरफेस लाइन होइन।