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 लाई देखिने गरी छुट्टाछुट्टै राख्छन्, र त्यही प्रतिलिपि गर्न लायक मानसिक ढाँचा हो।