ASA साइट-टु-साइट VPN मार्फत आन्तरिक सेवा प्रकाशित गर्ने

साइट-टु-साइट VPN पछाडि बस्ने सेवा प्रकाशित गर्नु पाँच असफलता बिन्दु भएको एउटा काम हो, र ती निश्चित क्रममा असफल हुन्छन्। टनेल माथि आउँछ, अनुवाद मिल्छ, शाखाले जवाफ दिन्छ, र जवाफ उही मार्गबाट फर्कन्छ। यीमध्ये कुनै पनि गलत भए ब्राउजरले उही कुरा देखाउँछ: अड्किने वा रिसेट हुने जडान। सूची माथिबाट तलसम्म गर्नुहोस् र असफल हुने पहिलो जाँचमा रोकिनुहोस्।

जाँच 1: टनेलले स्रोतको ठेगाना संरक्षित गर्छ

पहिले नै ट्राफिक पास गरिरहेको टनेलबाट सुरु गर्नुहोस्, त्यसपछि तपाईंले प्रकाशित गर्न खोजेको ठेगाना संरक्षित दायरा भित्र छ भनी पुष्टि गर्नुहोस्। ASA मा त्यो दायरा क्रिप्टो ACL वा VTI का रुटबाट आउँछ, र यसले स्रोतको वास्तविक ठेगाना ढाक्नुपर्छ, शाखाले व्यवस्थापनका लागि प्रयोग गर्ने सबनेट होइन। स्रोत छुटाउने चयनकर्ताले तपाईंलाई माथि रहेको टनेल र त्यसमा कहिल्यै नपस्ने प्रवाह दिन्छ।

अनुवाद छुनु अघि टनेल काउन्टर र रुट तालिकाबाट यो पुष्टि गर्नुहोस्। यदि हबबाट टनेल हुँदै स्रोत पुग्न सकिँदैन भने, यो सूचीमा अगाडिको कुनै पनि कुराले त्यो सुधार्न सक्दैन।

संरक्षित दायरा र स्रोतको ठेगाना नमिले यहीँ रोकिनुहोस्।

जाँच 2: शाखाले कुन स्रोत देख्ने हो निर्णय गर्नुहोस्

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

अनुवादले स्रोतले के लग गर्न सक्छ र स्रोत-आधारित नियम केसँग मिल्न सक्छ पनि बदल्छ। यदि अनुप्रयोगले अनुरोध पछाडिको व्यक्ति जान्नुपर्छ भने, त्यसको ठाउँ प्रमाणित रिभर्स प्रोक्सी हो, NAT को निर्णय होइन।

जाँच 3: वास्तविक इन्टरफेसअनुसार अनुवाद लेख्नुहोस्

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

तपाईंले बनाउँदै गरेको मार्गमा चार भाग छन्, र चारै मिल्नुपर्छ:

त्यो तालिकाका दायराहरूलाई प्लेसहोल्डर मान्नुहोस्। महत्त्वपूर्ण कुरा, अनुवादपछिको टुपल शाखाले टनेलबाट स्वीकार गर्ने ठेगाना होस्, र NAT स्थितिमा उल्टो म्यापिङ होस् ताकि बाहिर जाँदा प्रतिक्रिया पुनर्स्थापित होस्।

जाँच 4: पहुँच नियमलाई प्रकाशित पोर्टमा सीमित गर्नुहोस्

पोर्ट प्रकाशित गर्नुहोस्, होस्ट होइन। हरेक सेवामा स्रोतलाई अनुमति दिने नियमले एउटा प्रकाशित अनुप्रयोगलाई स्रोतले चलाउने सबैतिरको मार्ग बनाउँछ, जसमा तपाईंले जानाजान इन्टरनेटबाहिर राखेको व्यवस्थापन इन्टरफेस पनि पर्छ। अनुवादित स्रोतबाट स्रोतसम्म प्रकाशित पोर्टलाई अनुमति दिनुहोस्, र प्रशासनिक सेवालाई तिनको VPN मात्र मार्गमा छोड्नुहोस्।

त्यही बेला नियमहरूको क्रम जाँच्नुहोस्। तपाईंको विशिष्ट नियममाथि बसेको फराकिलो अनुमतिले विशिष्ट नियमलाई अदृश्य बनाउँछ।

जाँच 5: एउटा अनुरोध र त्यसको प्रतिक्रिया ट्रेस गर्नुहोस्

ब्राउजरबाट सुरु नगर्नुहोस्, किनकि ब्राउजरले कुन भाग असफल भयो लुकाउँछ। हबमा प्रवाह ट्रेस गर्नुहोस् र केही बदल्नु अघि नतिजा पढ्नुहोस्।

packet-tracer input outside tcp 198.51.100.25 50000 203.0.113.20 443 detailed
show nat detail
show xlate
show vpn-sessiondb l2l

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

त्यसपछि बाहिरबाट एउटा वास्तविक अनुरोध पठाउनुहोस् र प्रतिक्रिया उही टनेलबाट फर्केको पुष्टि गर्नुहोस्। प्रकाशित प्रविष्टि, अनुवाद, संरक्षित ठेगाना जोडी र फर्कने रुटलाई प्रकाशन अभिलेखका रूपमा नोट गर्नुहोस्।