NAT मागील FortiGate: local-gw, localid आणि सार्वजनिक IP

NAT मागील FortiGate त्याच्या WAN इंटरफेसवर 10.0.0.2 धरू शकतो, तर इंटरनेट तो 198.51.100.40 म्हणून दाखवते, आणि दोन्ही संख्या वास्तविक आहेत. डिव्हाइस ज्या पत्त्याशी बांधले जाते आणि IKE प्रमाणीकरणादरम्यान जी ओळख पाठवते ते वेगळे निर्णय आहेत, वेगळ्या फील्डमध्ये, वेगळ्या प्रेक्षकांसाठी घेतलेले. NAT वाटेत बाह्य पत्ता पुन्हा लिहिते; प्रमाणित ओळख दूरच्या पीअरच्या अपेक्षेप्रमाणे पुन्हा लिहीत नाही. या स्वरूपातील बहुतेक फेज 1 अपयश योग्य मूल्य चुकीच्या फील्डमध्ये ठेवण्यामुळे येतात.

तीन मूल्ये, तीन मालक

तीन मूल्ये आणि प्रत्येकाचा मालक कोण आहे हे नाव देऊन सुरुवात करा. local-gw हा तो पत्ता आहे जो FortiGate बाह्य इंटरफेसवर IKE साठी स्रोत म्हणून वापरतो, आणि तो डिव्हाइसकडे प्रत्यक्षात असलेला पत्ता असावा. सार्वजनिक एंडपॉइंट हा NAT डिव्हाइसचा पत्ता आहे, आणि तो अनुवाद करणाऱ्याच्या मालकीचा आहे. IKE ओळख ही एक स्ट्रिंग आहे जी पीअर स्वतःच्या कॉन्फिगरेशनशी जुळवतो, आणि ती IP पत्ता असणे अजिबात आवश्यक नाही.

फील्डची नावे बदलीसाठी आमंत्रण देण्याइतकी जवळ आहेत, आणि तोच सापळा आहे. localid आणि localid-type ओळख वर्णन करतात; local-gw स्थानिक बांधणी वर्णन करते.

उदाहरण फरक ठोस करते. FortiGate वर config vpn ipsec phase1-interface उघडा, नंतर set interface "wan1" आणि set local-gw 10.0.0.2 — बॉक्सकडे असलेला पत्ता, आणि हेच IKE सॉकेट यशस्वीरित्या बांधण्यास कारणीभूत ठरते. local-gw 0.0.0.0 वर ठेवल्यास इंटरफेसचा पत्ता वापरला जातो, जो सहसा तोच असतो पण कमी स्पष्ट. local-gw 198.51.100.40 वर सेट करू नका, कारण डिव्हाइसकडे तो पत्ता नाही आणि सॉकेट त्याला बांधले जाणार नाही. दोन मूल्ये कागदावर समान दाखवणे हे कॉन्फिगरेशन नाही.

पायरी 1: पीअर स्वीकारणारी ओळख निवडा

आता ओळख, जी वेगळा निर्णय आहे. set localid पीअर तुलना करणारे मूल्य घेते, आणि set localid-type FortiGate ला ते कसे अर्थ लावायचे ते सांगते: पत्ता, FQDN, वापरकर्ता FQDN किंवा की ID. auto सह डिव्हाइस ते काढते, सहसा बाहेर जाणाऱ्या इंटरफेसच्या पत्त्यावरून, जे NAT डिव्हाइस बदलणार असलेले मूल्यच आहे.

हेच काढणे या टोपोलॉजीमध्ये स्पष्ट ओळख महत्त्वाची का आहे याचे कारण आहे. पीअर पत्ता-ओळखीची अपेक्षा करत असल्यास, localid-type address आणि localid पीअर दिसणाऱ्या सार्वजनिक पत्त्यावर सेट करा, नंतर पीअर ते मूल्य राउटिंग लक्ष्य म्हणून नाही तर ओळख म्हणून स्वीकारतो याची खात्री करा. पीअर FQDN ची अपेक्षा करत असल्यास, localid-type fqdn आणि ज्या नावाने ते कॉन्फिगर केले होते ते वापरा. प्रत्यक्षात काय पाठवले गेले हे diagnose vpn ike gateway list ने तपासा, जे गेटवेची स्थिती आणि वापरातील ओळखकर्ते दाखवते, तुम्ही टाइप करू इच्छित होता ते नाही. ओळख-प्रकाराचा पर्याय कोणताही स्थानिक-नसलेला पत्ता स्वीकारतो असे गृहीत धरू नका; आधी आवृत्तीचे दस्तऐवजीकृत अर्थशास्त्र तपासा.

पायरी 2: UDP 500 आणि 4500 डिव्हाइसवर पाठवा

तिसरे मूल्य NAT डिव्हाइसचे आहे, आणि लोक तपासायला विसरतात तेच ते. सार्वजनिक एंडपॉइंटने UDP 500 आणि UDP 4500 FortiGate वर पाठवले पाहिजेत, कारण NAT-T शोध आणि त्यानंतरचा एन्कॅप्स्युलेटेड ESP दोन्ही या पोर्टच्या आगमनावर अवलंबून आहेत. ही रचना एक-ते-एक मॅपिंग गृहीत धरते; एक सार्वजनिक पत्ता अनेक पीअरमध्ये पोर्टनुसार सामायिक करणे ही वेगळ्या मर्यादा असलेली वेगळी टोपोलॉजी आहे.

पाठवणी कॅप्चरने सिद्ध करा, आशेने नाही: diagnose sniffer packet any "udp port 500 or udp port 4500" 4 पॅकेट येत आहेत का आणि उत्तरे जात आहेत का हे दाखवते.

Google Cloud VPN NAT मागील पीअरसाठी समर्थित व्यवस्था म्हणून NAT-T सह एक-ते-एक NAT चे दस्तऐवजीकरण करते, आणि दूरचे टोक Cloud VPN गेटवे असल्यास याच मर्यादेच्या विरुद्ध रचना करावी. एक-ते-अनेक किंवा पोर्टनुसार सामायिक करणे ही तीच समर्थित टोपोलॉजी नाही, आणि स्थानिक ओळख ट्यूनिंगने ते बदलत नाही. दूरची बाजू दुसरे उपकरण असल्यास, त्याचे स्वतःचे दस्तऐवज ओळख म्हणून काय स्वीकारेल आणि अनुवादित पीअर पत्ता सहन करेल का हे ठरवते. स्थानिक फील्ड बदलण्यापूर्वी ते वाचा, कारण दूरची बाजू जो नियम लागू करत नाही तो स्थानिक बाजू वाटाघाटी करू शकत नाही.

पायरी 3: फेज 1 काय सोडवत नाही ते तपासा

NAT ट्रॅव्हर्सल टनेल उभारते, ओळखीची सहमती पीअर ती स्वीकारेल का हे ठरवते, आणि आंतरिक प्रीफिक्स राउटिंग प्रत्यक्षात काय जाते हे ठरवते. योग्य स्थानिक ID हरवलेला स्टॅटिक मार्ग किंवा हरवलेला ट्राफिक निवडक देऊ शकत नाही.

म्हणून स्तरांनुसार तपासा. get vpn ipsec tunnel details टनेल वर आहे का आणि कोणते निवडक वाटाघाटी झाले हे दाखवते, आणि कॉन्फिगर केलेले दूरचे सबनेट व वाटाघाटी झालेला निवडक यातील तफावत ही फेज 2 च्या पोशाखातील राउटिंग समस्या आहे. execute vpn ike gateway clear पुन्हा वाटाघाटी करण्यास भाग पाडते, त्यामुळे तुम्ही सध्याचे कॉन्फिगरेशन तपासत आहात, तुमच्या शेवटच्या बदलापूर्वी स्थापन झालेले सत्र नाही. नंतर दूरच्या प्रीफिक्समधील होस्टवर ट्राफिक पाठवा आणि काउंटर हलतात याची खात्री करा, कारण वर असलेली पण काहीही पाठवत नसलेली टनेल तपासेपर्यंत कार्यरत टनेलसारखीच दिसते.

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

NAT डिव्हाइसचे पुनर्क्रमांकन FortiGate च्या local-gw ला स्पर्श करण्याचे कारण नाही, आणि ओळख बदलणे काहीही पुनर्क्रमांकित करण्याचे कारण नाही. दोन्ही मिसळणे म्हणजे असंबंधित देखभाल विंडोमध्ये कार्यरत टनेल पुन्हा बांधण्याचा मार्ग. Cloud VPN NAT मार्गदर्शक त्या बाजूच्या समर्थित टोपोलॉजीसाठी संदर्भ आहे.

हे ठरवणारी चाचणी कंटाळवाणी आणि जलद आहे: बाह्य इंटरफेसवर कॅप्चर करा, पीअरकडून UDP 500 आणि 4500 येतात याची खात्री करा, IKE देवाणघेवाणीतील ओळख पीअरने अपेक्षा करण्यासाठी कॉन्फिगर केलेल्याशी जुळते याची खात्री करा, नंतर वाटाघाटी झालेले निवडक तुम्हाला महत्त्वाच्या सबनेटना व्यापतात याची खात्री करा. पहिली तपासणी अयशस्वी झाल्यास, संशयित NAT डिव्हाइस आहे. दुसरी अयशस्वी झाल्यास, ओळख फील्ड आहेत. तिसरी अयशस्वी झाल्यास, NAT किंवा ओळख कधीही समस्या नव्हती.