साइट-टू-साइट VPN च्या आत NAT कधी आपली जागा मिळवतो

दोन्ही साइट एकाच खाजगी श्रेणीचा वापर करतात, आणि टनेल वर येते पण त्यातून काहीही उपयुक्त जात नाही. भाषांतर हे नेहमीचे उत्तर आहे, आणि ते खरे उत्तर आहे: दूरच्या बाजूला वेगळी श्रेणी दाखवल्यामुळे ओव्हरलॅप किंवा दुसऱ्या नेटवर्कला राउट करता येणार नाही असा परतीचा मार्ग सुटू शकतो. वगळला जाणारा भाग म्हणजे भाषांतर प्रत्येक पुढील निर्णयाला दिसणारे पत्ते बदलते. हे लिखित मॅपिंगसह दस्तऐवजीकृत डिझाइन निर्णय म्हणून घ्या, ping यशस्वी होईपर्यंत जोडला जाणारा नियम म्हणून नाही.

कोणता पत्ता पुन्हा लिहिला जाईल ते ठरवा

स्रोत भाषांतर बदलते की दूरची सेवा आणि तिचे लॉग कोणाला क्लायंट म्हणून पाहतात, त्यामुळे शाखा होस्ट आल्यावर गेटवे पत्ता बनतो. गंतव्य किंवा प्रीफिक्स भाषांतर त्याऐवजी दूरच्या संसाधनासाठी पर्यायी पत्ता सादर करते. काही तैनातींना दोन अन्यथा समान नेटवर्क वेगळे करण्यासाठी दोन्ही बाजूंनी समन्वित भाषांतर लागते, आणि बहुतेक गोंधळ याच संयोजनापासून सुरू होतो.

भाषांतरापूर्वीचा स्रोत, अनुप्रयोग ज्या नावाने गंतव्य म्हणतो, आणि प्रत्येक गेटवे जुळवतो ती पत्ता जोडी लिहा. तीन स्तंभ पुरेसे आहेत, आणि तिसरा स्तंभ लोक विसरतात तोच.

सिलेक्टरचा क्रमही महत्त्वाचा आहे. IPsec धोरणाची निवड आणि भाषांतर ठरलेल्या टप्प्यांवर होते, त्यामुळे भाषांतरापूर्वीच्या पत्त्यांसाठी लिहिलेला सिलेक्टर तुम्ही गृहीत धरलेल्या टप्प्यावर पॅकेटशी कधीही जुळणार नाही. प्रत्यक्ष स्थापित धोरण तपासा, स्थापित करण्याचा उद्देश असलेले धोरण नाही, कारण एक घटक नियम स्वीकारतो आणि दुसरा दुर्लक्ष करतो तेव्हाच दोन्ही वेगळे होतात:

ip xfrm policy show
ip xfrm state show
nft list ruleset | grep -A4 nat

पेलोड आणि परतीचा मार्ग अनुसरा

वेगळ्या शाखा होस्टऐवजी भाषांतरित स्रोत लॉग करणारा सर्व्हर मूळ पत्त्याशी जोडलेला कोणताही नियम किंवा अहवाल तोडेल. मॅपिंग बदलण्यापूर्वी, खालच्या बाजूला काही त्या क्षेत्रातून निर्णय घेते का ते शोधा: प्रवेश सूची, ऑडिट अहवाल, दर मर्यादा, परवाना तपासण्या. यापैकी प्रत्येक ठिकाण असे आहे जिथे भाषांतर नंतर अस्पष्ट अपयश म्हणून दिसते.

जे प्रोटोकॉल आपल्या पेलोडमध्ये पत्ते वाहतात त्यांना वेगळे नियोजन लागते, कारण बाह्य हेडर पुन्हा लिहिल्याने आंतरिक संदर्भाला स्पर्श होत नाही. सक्रिय FTP, SIP आणि काही दूरस्थ-प्रवेश उत्पादने ही पारंपरिक उदाहरणे आहेत, आणि त्यांना दुर्लक्ष करणारे डिझाइन वेब रहदारीसाठी चालेल पण महत्त्वाच्या अनुप्रयोगासाठी अपयशी ठरेल.

परतीची रहदारी स्थितीयुक्त मॅपिंगवर अवलंबून असते. गेटवे फेलओव्हर ती स्थिती गमावू शकतो, असममित राउटिंग ती टाळू शकते, आणि रीस्टार्ट ती पुसू शकतो जेव्हा दूरच्या बाजूला सत्रे उघडी राहतात. म्हणूनच गंतव्यापर्यंत पोहोचणारी विनंती आणि पूर्ण होणारे सत्र हे दोन वेगळे स्वीकृती निकाल आहेत.

साइटच्या पुनर्क्रमांकनाशी याची तुलना करा

संघर्ष असलेल्या एका साइटचे पुनर्क्रमांकन मॅपिंग पूर्णपणे काढून टाकते आणि भाषांतर तक्त्यांशिवाय वाचता येणारी पत्ता योजना ठेवते. ते कार्यात्मकदृष्ट्या महाग आहे: DNS नोंदी, स्थिर नियुक्त्या, फायरवॉल नियम आणि प्रत्येक दस्तऐवजीकृत पत्ता एकत्र बदलावा लागतो. खर्च एकदाच, नियोजित खिडकीत, स्पष्ट अंतिम स्थितीसह येतो. तुम्ही जे विकत घेता ते म्हणजे वर्षानंतर शोध तक्त्याशिवाय पॅकेट कॅप्चर वाचण्याची क्षमता.

भाषांतर बहुतेक स्थानिक बदल टाळते आणि DNS, दस्तऐवजीकरण आणि समस्या निवारणात कायम ठेवावे लागणारे मॅपिंग तयार करते. खर्च सतत येतो, टनेलमध्ये एका प्रीफिक्सचा वेगळा अर्थ आहे हे शिकावे लागणाऱ्या प्रत्येक भविष्यातील अभियंत्याच्या रूपात.

तात्पुरत्या कनेक्शनसाठी किंवा तुम्ही नियंत्रित न करणाऱ्या भागीदार नेटवर्कसाठी, सततचा खर्च सहसा योग्य असतो. तुमच्या मालकीच्या आणि वर्षानुवर्षे राहणाऱ्या दोन साइटसाठी, स्थलांतराची प्रामाणिक गणना केल्यास पुनर्क्रमांकन हा अनेकदा स्वस्त निर्णय असतो.

खऱ्या सत्राने दोन्ही दिशा सिद्ध करा

एका प्रोबऐवजी अनुप्रयोग सत्र तपासा. यशस्वी इको विनंती सिद्ध करते की एका प्रोटोकॉलची एक दिशा चालते, आणि ती स्थितीयुक्त कोणत्याही गोष्टीसाठी अपयशी ठरणाऱ्या परतीच्या मार्गाशी पूर्णपणे सुसंगत आहे. ज्या सेवेने डिझाइनला प्रेरणा दिली ती वापरा, आणि दूरच्या टोकावरील तिचा लॉग वाचून कोणता स्रोत पत्ता नोंदवला ते पाहा.

tcpdump -ni any host 10.40.9.20 and port 443
conntrack -L | grep 10.40.9.20
ip route get 10.40.9.20

नंतर मॅपिंगद्वारे फक्त इच्छित सेवाच पोहोचण्यायोग्य आहेत याची खात्री करा. भाषांतर पत्ता-निर्धारण बदलते आणि अधिकृततेसाठी काहीही करत नाही, त्यामुळे फायरवॉल धोरणच काय परवानगी आहे हे ठरवते. अस्पष्ट भाषांतरित प्रीफिक्सवर प्रवेश नियंत्रण म्हणून अवलंबून असलेल्या डिझाइनमध्ये प्रवेश नियंत्रणच नाही.

मॅपिंग, तपासलेले सत्र आणि प्रत्येक बाजूने पाहिलेले पत्ते नोंदवा. हा टनेल डीबग करणाऱ्या पुढील व्यक्तीला कॉन्फिगरेशन फाइलपेक्षा त्या तीन तथ्यांची जास्त गरज आहे.