AWS NAT गेटवेबाट GRE र ESP किन असफल हुन्छन्

टनेल असफल हुन्छ, सुरक्षा समूहले पहिले नै सबै ट्राफिकलाई अनुमति दिन्छ, र निष्कर्ष AWS ले VPN रोकिरहेको छ भन्ने निकालिन्छ। यसले केही पनि रोकिरहेको छैन। व्यवस्थित NAT गेटवेले बाह्य प्रोटोकलको अभिलेखित समूह अगाडि पठाउँछ, र स्थानीय GRE वा स्थानीय ESP त्यसमा छैनन्, त्यसैले तपाईंले थप्ने कुनै पनि नियमले गेटवेलाई तिनीहरू बोक्न बाध्य पार्दैन। अनुमति नियम र ढुवानी क्षमता दुई फरक कुरा हुन्, र तीमध्ये एउटा मात्र तपाईंले बदल्न सक्नुहुन्छ।

नियमको समूह प्रोटोकलको समूह होइन

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

AWS को NAT गेटवे प्रोटोकल विनिर्देश ले व्यवस्थित सेवाका लागि TCP, UDP र ICMP सूचीबद्ध गर्छ। त्यही पूरै समर्थित समूह हो। अर्को IP प्रोटोकलका लागि अनुमति नियमले यसलाई विस्तार गर्न सक्दैन, किनभने नियम गेटवेको अगाडि पठाउने मार्गमा पुग्नुभन्दा धेरै अघि मूल्याङ्कन गरिन्छ।

यो भिन्नता महत्त्वपूर्ण छ किनभने दुवै असफलता ग्राहकको दृष्टिकोणबाट उस्तै देखिन्छन् र तिनका समाधान पूर्ण रूपमा फरक छन्।

PPTP ले पोर्ट परीक्षण किन झुटो बोल्छ देखाउँछ

केही पनि प्रमाणित नगर्ने पोर्ट जाँचको सबैभन्दा स्पष्ट पुरानो उदाहरण PPTP हो। यसले पोर्ट 1723 मा TCP नियन्त्रण जडान खोल्छ र त्यसपछि टनेल डेटा GRE मार्फत बोक्छ, जो IP प्रोटोकल 47 हो। प्रोटोकल 47 TCP पोर्ट 47 होइन, र यी दुई सङ्ख्याको एकअर्कासँग अङ्क साझा गर्नुबाहेक कुनै सम्बन्ध छैन।

1723 मा जडान परीक्षण गरेर पूरा भएको ह्यान्डशेक देख्ने अपरेटरले मार्ग काम गरिरहेको निष्कर्ष निकाल्छ। त्यसपछि डेटा च्यानलले एक पनि प्याकेट पार गर्दैन, किनभने गेटवेसँग दिनका लागि कुनै GRE समर्थन छैन। यो पुरानो प्रोटोकलको आवश्यकताको व्याख्या हो, PPTP तैनाथ गर्ने सल्ला होइन, जो वर्षौंदेखि अप्रचलित छ।

यही तर्क नियन्त्रण च्यानल TCP वा UDP भएको तर डेटा मार्ग त्यस्तो नभएको कुनै पनि प्रोटोकलमा लागू हुन्छ।

IPsec UDP को रूपमा मात्र टिक्छ

IPsec त्यो अवस्था हो जहाँ उत्तर सोझो होइन होइन, सशर्त हुन्छ। NAT गेटवेमार्फत IPsec का लागि NAT ट्राभर्सललाई AWS ले समर्थित व्यवस्थाका रूपमा अभिलेख गर्छ। NAT-T मा वार्ता भएपछि ESP UDP भित्र इन्क्याप्सुलेट हुन्छ र गेटवेले प्रोटोकल 50 को सट्टा साधारण UDP देख्छ।

UDP 4500 लाई अनुमति दिँदा इन्डपोइन्टहरूले NAT ट्राभर्सल प्रयोग गर्न थाल्दैनन्। यसले प्याकेटहरूलाई पहिले नै त्यो रूपमा भएमा मात्र अनुमति दिन्छ। ग्राहकको आफ्नै वार्ता आउटपुटबाट कुन इन्क्याप्सुलेशन छानियो भनी पुष्टि गर्नुहोस्, र प्राप्त गर्ने पक्षमा साथीले स्वीकार गरेको पुष्टि गर्नुहोस्। स्थानीय ESP का लागि कन्फिगर गरिएका दुई इन्डपोइन्टले नियमको समूहले जे भने पनि स्थानीय ESP पठाइरहनेछन्।

TCP वा UDP आधारित VPN अभिलेखित ढुवानी समूहमा मिल्छ र तैपनि रुटिङ, फिल्टरिङ वा प्रमाणीकरणका कारण असफल हुन सक्छ। समूहमा मिल्नु आवश्यक छ, पर्याप्त होइन।

नीति विस्तार गर्नुअघि मार्ग जाँच्नुहोस्

कार्यभार सबनेटको वास्तविक मार्ग र यसको अर्को हपको पहिचान पहिले प्रमाणित गर्नुहोस्। सिधा सार्वजनिक मार्ग, NAT इन्स्टेन्स, व्यवस्थित NAT गेटवे र ट्रान्जिट गेटवेमार्फत निजी मार्ग चार फरक डिजाइन हुन्, र तीमध्ये एउटा मात्र यहाँ वर्णित व्यवस्थित सेवा हो।

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

सेवाले बोक्न नसक्ने ढुवानीको क्षतिपूर्ति गर्न सबै ट्राफिक नखोल्नुहोस्। नियम परिवर्तनले यसलाई सुधार्ने छैन, र यो घटनापछि पनि रहनेछ।

जब ढुवानी मिल्दैन

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

इनबाउन्ड VPN सर्भर होस्ट गर्नु फरक उत्तर भएको फरक समस्या हो। NAT गेटवेले आउटबाउन्ड अनुवाद दिन्छ र सामान्य इनबाउन्ड पोर्ट फर्वार्डिङ दिँदैन, त्यसैले यसको पछाडिको सर्भरलाई आफ्नै सर्तमा डिजाइन गरिएको स्वीकृत सार्वजनिक प्रवेश आवश्यक हुन्छ।

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