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 और न ही पहचान कभी समस्या थी।