साइट-देखि-साइट VPN भित्र NAT कहिले आफ्नो स्थान पाउँछ

दुवै साइटले एउटै निजी दायरा प्रयोग गर्छन्, र सुरुङ माथि आउँछ तर त्यसबाट केही उपयोगी जाँदैन। अनुवाद नै सामान्य उत्तर हो, र यो वास्तविक उत्तर हो: टाढाको पक्षलाई फरक दायरा देखाउँदा ओभरल्याप वा अर्को नेटवर्कले रुट गर्न नसक्ने फिर्ती मार्ग समाधान हुन सक्छ। छुट्ने भाग यो हो कि अनुवादले प्रत्येक पछिको निर्णयले देख्ने ठेगानाहरू बदल्छ। यसलाई लिखित म्यापिङसहितको अभिलेखित डिजाइन निर्णयको रूपमा लिनुहोस्, पिङ सफल नहुँदासम्म थपिने नियमको रूपमा होइन।

कुन ठेगाना पुनः लेखिन्छ निर्णय गर्नुहोस्

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

अनुवादअघिको स्रोत, अनुप्रयोगले नाम दिने गन्तव्य, र प्रत्येक गेटवेले मिलाउने ठेगाना जोडी लेख्नुहोस्। तीन स्तम्भ पर्याप्त छन्, र तेस्रो स्तम्भ नै मानिसहरूले छुटाउने हो।

सिलेक्टरको क्रम पनि महत्त्वपूर्ण छ। 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

त्यसपछि म्यापिङमार्फत केवल इच्छित सेवाहरू मात्र पुग्न सकिने पुष्टि गर्नुहोस्। अनुवादले ठेगाना निर्धारण बदल्छ र अधिकारका लागि केही गर्दैन, त्यसैले फायरवाल नीतिले नै के अनुमति छ भन्ने तय गर्छ। अस्पष्ट अनुवादित प्रिफिक्सलाई पहुँच नियन्त्रणका रूपमा भर पर्ने डिजाइनमा पहुँच नियन्त्रण नै हुँदैन।

म्यापिङ, परीक्षण गरिएको सत्र र प्रत्येक पक्षले देखेका ठेगाना अभिलेख गर्नुहोस्। यो सुरुङ डिबग गर्ने अर्को व्यक्तिलाई कन्फिगरेसन फाइलभन्दा ती तीन तथ्य बढी चाहिन्छ।