ASA: एउटै सार्वजनिक IP मा VPN पोर्ट र DMZ स्ट्याटिक PAT
एउटा सार्वजनिक ठेगाना, दुई सेवा। VPN लिस्नर र DMZ PAT का लागि ठेगाना, ट्रान्सपोर्ट र पोर्टको सूची बनाउनुहोस्, एकले अर्काको प्रविष्टि ओगट्नु अघि।
दुई सेवा, एउटा सार्वजनिक ठेगाना, र पोर्ट आरक्षित गरेको जस्तो लाग्ने DNS नाम। त्यसो गर्दैन। ASA मा VPN प्रविष्टिको छेउमा DMZ सर्भर प्रकाशित गर्नु अघि प्रविष्टिका टुपलहरू लेख्नुहोस् र क्रममा जाँच्नुहोस्; अवस्थित सेवासँग मिल्ने पहिलो फिल्ड नै योजना रोकिने ठाउँ हो. तलका सबै कुराले VPN उपकरणमै अन्त्य हुन्छ भन्ने मान्छ, भित्री सर्भरमा होइन।
कमाण्ड लेख्नु अघि पाँच फिल्ड लेख्नुहोस्
प्रत्येक सार्वजनिक प्रविष्टिका लागि ठेगाना परिवार, सार्वजनिक ठेगाना, ट्रान्सपोर्ट, सार्वजनिक पोर्ट र मालिक रेकर्ड गर्नुहोस्। मालिक ASA-स्थानीय सेवा वा अनुवादित भित्री सर्भर हो। दुई प्रविष्टिले एउटै ठेगाना बाँड्न सक्छन् र तैपनि फरक टुपल हुन सक्छन्, र दुई प्रविष्टि रेखाचित्रमा फरक देखिन सक्छन् तर उपकरणमा ठोक्किन सक्छन्।
वास्तविक पोर्टका लागि दोस्रो स्तम्भ राख्नुहोस्, जुन भित्री सर्भरले साँच्चै सुन्छ। सार्वजनिक पोर्ट र वास्तविक पोर्ट स्वतन्त्र छनोट हुन्, र तिनलाई एउटै स्तम्भमा मिलाएको क्षणमा पछि आफ्नै अनुवाद पढ्ने क्षमता गुमाउनुहुन्छ।
| Public entry | Owner | Real side |
|---|---|---|
| TCP 443 on the outside address | ASA VPN listener | Appliance-local, no translation |
| TCP 8443 on the outside address | Static PAT | DMZ server TCP 443 |
| UDP 443 on the outside address | Check the effective listeners | Possibly the VPN data path |
वास्तविक र म्याप गरिएका स्थानहरू सही ढंगले पढ्नुहोस्
तपाईं थप्न चाहनुभएको सर्भरबाट होइन, पहिले नै भएको टुपलबाट सुरु गर्नुहोस्। एउटा उदाहरणीय विभाजनले स्वीकृत VPN प्रविष्टिलाई सार्वजनिक TCP 443 मा राख्छ र सार्वजनिक TCP 8443 मा DMZ HTTPS सर्भर प्रकाशित गर्छ, जबकि त्यो सर्भर 443 मा सुन्न जारी राख्छ:
Public TCP 443 -> ASA VPN listener
Public TCP 8443 -> DMZ server TCP 443तैनाथ कमाण्डमा वास्तविक सेवा र म्याप गरिएको सेवा स्थिर स्थानमा हुन्छन्, र तिनलाई उल्टाउँदा टुटेको होइन, फरक म्यापिङ वर्णन हुन्छ। चलिरहेको अनुवाद पहेली बन्ने यो सबैभन्दा सामान्य बाटो हो: कन्फिगरेसन मान्य छ, यो केवल अन्तै सङ्केत गर्छ।
Cisco को ASA 9.16 NAT मार्गदर्शक ले स्ट्याटिक PAT, इन्टरफेस-ठेगानाको प्रयोग र वास्तविक तथा म्याप गरिएको पोर्टका अर्थहरू अभिलेख गर्छ। तपाईंले साँच्चै चलाउनुभएको रिलिजको खण्ड पढ्नुहोस्; पुरानो प्लेटफर्मबाट सम्झिएको कमाण्ड पूर्ण हालको कन्फिगरेसन होइन।
ट्रान्सपोर्टलाई आरक्षणको भाग ठान्नुहोस्
TCP 443 र UDP 443 फरक टुपल हुन्, र त्यो भिन्नताले तपाईंलाई UDP निःशुल्क दिँदैन। VPN का छुट्टै TLS र DTLS लिस्नर हुन सक्छन्, र अरू कन्फिगर गरिएका सेवाले तपाईंले चाहेको ट्रान्सपोर्ट पहिले नै ओगटेका हुन सक्छन्। वेब पृष्ठ नै पूरै VPN प्रविष्टि हो भनी मान्नुको साटो प्रभावकारी लिस्नर र पहुँच नीतिको सूची बनाउनुहोस्।
एउटै ठेगानामा रिजोल्भ हुने दोस्रो होस्टनामले पनि ट्रान्सपोर्ट-तहको ठक्कर हल गर्दैन। DNS नाम-देखि-ठेगाना म्यापिङ हो, पोर्ट दलाल होइन, र PAT मार्फत सर्भर प्रकाशित गर्नु VPN लिस्नरलाई अर्को पोर्टमा सार्नु जस्तै एउटै कार्य होइन।
यदि VPN प्रविष्टि साँच्चै सार्नै पर्ने हो भने चार कुरा सँगै बदलिन्छन्: क्लाइन्ट प्रोफाइल, सार्वजनिक URL, माथिल्लो फिल्टरिङ र तैनाथीले प्रयोग गर्ने हरेक ट्रान्सपोर्ट। एक-एक गर्नुको साटो एउटै विन्डोमा गर्नुहोस्। उपकरणसम्म पुग्न प्रयोग गर्ने सेवा छुनु अघि उपकरणसम्म छुट्टै व्यवस्थापन मार्ग खुला राख्नुहोस्। दोस्रो मार्ग बिना, सार्नु बाहिरबाट फर्काउन नसकिने परिवर्तन हो।
बाहिरबाट नयाँ जडानसँग जाँच्नुहोस्
प्रभावकारी पहुँच नीतिअन्तर्गत केवल अभिप्रेत DMZ अनुप्रयोगलाई अनुमति दिनुहोस्, त्यसपछि मिल्ने अनुवाद क्रम, सर्भरको फर्किने मार्ग र प्रमाणपत्रमा भएको होस्टनाम जाँच्नुहोस्। PAT ले सञ्जाल गन्तव्य बदल्छ; यसले अनुप्रयोग पहुँच दिँदैन र अर्को होस्ट नाम भएको प्रमाणपत्र मर्मत गर्दैन।
अधिकृत बाहिरी होस्टबाट नयाँ जडानसँग दुवै सेवा परीक्षण गर्नुहोस्: VPN अझै स्थापित हुनुपर्छ, र DMZ अनुरोधले यसको अभिप्रेत लिस्नरमा पुग्नुपर्छ। स्थापित सत्रले अघिल्लो अवस्था राख्न सक्छ, त्यसैले एक मिनेट अघि बदलेको म्यापिङबारे यसले केही प्रमाणित गर्दैन।
तपाईंले तैनाथ गरेको कुराले प्रविष्टि सूची अद्यावधिक गरी चक्र बन्द गर्नुहोस्, बनाएर होइन भेट्टाएका हरेक लिस्नर सहित। त्यो ठेगानामा अब सेवा प्रकाशित गर्ने व्यक्ति तपाईंको तालिकाबाट सुरु गर्नेछ, र त्यहाँको गलत पङ्क्ति यहाँको गलत कमाण्डभन्दा महँगो पर्छ।