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 वा पहिचान कहिल्यै समस्या थिएन।