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 विनंतीने तिच्या इच्छित लिसनरपर्यंत पोहोचायला हवे. प्रस्थापित सत्र पूर्वीची स्थिती ठेवू शकते, म्हणून एका मिनिटापूर्वी बदललेल्या मॅपिंगबद्दल ते काहीही सिद्ध करत नाही.
तुम्ही तैनात केलेल्या गोष्टींनी नोंद-यादी अद्ययावत करून चक्र बंद करा, तयार न करता शोधलेल्या प्रत्येक लिसनरसह. त्या पत्त्यावर पुढे सेवा प्रकाशित करणारी व्यक्ती तुमच्या तक्त्यापासून सुरुवात करेल, आणि तिथली चुकीची ओळ येथील चुकीच्या आदेशापेक्षा जास्त महाग आहे.