तपाईंको VPN सर्भरले वास्तवमा कुन स्रोत ठेगाना देख्छ भन्ने NAT ले निर्धारण गर्छ

VPN सर्भरले प्याकेटबाट तपाईंको ल्यापटपको ठेगाना पढेर लगमा लेख्छ भनी तपाईं कल्पना गर्नुहुन्छ। उसले पढ्ने कुरा अन्तिम NAT हपले बाहिरी हेडरमा राखेको हुन्छ, र हटस्पटका रूपमा प्रयोग भएको फोनमा यो प्रायः सयौं अन्य ग्राहकसँग साझा गरिएको ठेगाना हुन्छ। तपाईंको मेसिनको आफ्नै 192.168.x.x त्यो हेडरमा कहिल्यै इन्टरनेट तर्दैन, र टनेलको ठेगाना सर्भरले जडान पहिले नै स्थापित भएपछि दिन्छ। त्यसैले सर्भरको लग र ल्यापटपको ip addr नमिल्दा दुवैमध्ये कुनै पनि गलत हुँदैन; तिनीहरू एउटै सत्रका फरक तहहरू वर्णन गर्छन्।

तीन ठेगाना, र लगमा एउटा मात्र

अलमल तीन ठेगानालाई एउटैमा मिलाउनबाट आउँछ। प्रत्येकको फरक मालिक छ, फरक हेडरमा बस्छ, र फरक बाटोबाट सर्भरसम्म पुग्छ।

जडान गर्दा बीचको पङ्क्ति मात्र अज्ञात हुन्छ। डेमनअनुसार सर्भरले त्यसलाई आफ्नो पियर तालिका, स्थिति फाइल वा फ्लो लगमा लेख्छ: WireGuard ले यसलाई इन्डप्वाइन्ट भन्छ, OpenVPN स्थिति फाइलले यसलाई Real Address भनी चिन्ह लगाउँछ, र strongSwan ले यसलाई IKE_SA को टाढाको होस्टका रूपमा जनाउँछ। त्यो मान फरक स्रोतबाट प्याकेट आउँदा हरेक पटक ताजा हुन्छ, त्यसैले कसैले केही पनि पुनःसुरु नगरी यो बदलिन्छ।

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

टनेल चालु रहँदा लग गरिएको टुपल किन बदलिन्छ

ठेगाना अनुवाद टाइमरसहितको तालिका हो, स्थायी बन्धन होइन। घरको राउटरले अन्तिम प्याकेटपछि केही समय आफ्नो UDP म्यापिङ राख्छ, अपरेटरको गेटवेले आफ्नै तालिकाअनुसार पोर्ट पुनःप्रयोग गर्छ, र Wi-Fi बाट LTE मा जाने फोन पूर्ण रूपमा फरक स्रोतसहित फर्किन्छ। यहाँ Linux conntrack का पूर्वनिर्धारित मानहरू उपयोगी मापदण्ड हुन्: nf_conntrack_udp_timeout 30 सेकेन्ड हो र स्ट्रिमिङ संस्करण 120, त्यसैले शान्त टनेलले प्रयोगकर्ताले थाहा पाउनुभन्दा धेरै अघि आफ्नो म्यापिङ गुमाउन सक्छ।

टनेल टिक्छ किनभने प्रोटोकलले ठेगाना होइन, पियर प्रमाणित गर्छ। ह्यान्डसेकपछि WireGuard स्थितिहीन हुन्छ, त्यसैले कुनै पनि प्रमाणित प्याकेटले भण्डारण गरिएको इन्डप्वाइन्ट अद्यावधिक गर्छ र पुनःबन्धन अर्को प्याकेटमा निको हुन्छ; persistent-keepalive = 25 यही कारणले छ, निष्क्रिय हुँदा म्यापिङ तातो राख्न। OpenVPN को --float ले पनि त्यही काम गर्छ र प्रमाणित क्लाइन्टलाई नयाँ ठेगाना र पोर्टबाट अगाडि बढ्न दिन्छ। float पूर्वनिर्धारित रूपमा बन्द भएका 2.4 र 2.5 बिल्डमा, पुनःबन्धनले सत्र रिसेट गर्छ र क्लाइन्ट फेरि जोडिन्छ।

IPsec त्यहाँ बढी चल्ने भागहरूसहित पुग्छ। IKEv2 ले NAT पत्ता लगाउने पेलोडमा स्रोत र गन्तव्यका ह्यास तुलना गरेर अनुवाद पहिचान गर्छ, UDP 4500 इन्क्याप्सुलेसनमा जान्छ, र keepalive लाई नयाँ टुपलसम्म पछ्याउँछ। keepalive अवरुद्ध हुँदा SA कागजमा चालु रहन्छ अरू एक दिशाको ट्राफिक चुपचाप रोकिन्छ।

सर्भरले के आरोपित गर्न सक्छ, र के सक्दैन

मार्न लायक मिथक भनेको अनुवादले तपाईंलाई अपरेटरबाट लुकाउँछ भन्ने हो। यसले लेबल बदल्छ, अवलोकन होइन। अपरेटरको NAT पछाडिको गेटवेले 100.64.0.0/10 ठाउँ वा धेरै ग्राहकले साझा गर्ने एउटा सार्वजनिक ठेगाना देख्छ, र तैपनि प्रवाहलाई प्रमाणपत्रको विषय, WireGuard सार्वजनिक कुञ्जी, तोकिएको टनेल ठेगाना, बाइट काउन्टर र समय विन्डोसँग जोड्न सक्छ। यीमध्ये कसैलाई पनि तपाईंको LAN ठेगाना चाहिँदैन।

सीमाहरू उल्टो दिशामा पनि जान्छन्। लगमा भएको साझा ठेगानाले घर होइन, गेटवेतर्फ सङ्केत गर्छ; एउटै अनुवादित ठेगानाबाट फरक पोर्टमा भएका दुई सत्र फरक उपकरण हुन्; पोर्ट पुनःप्रयोग भएको खण्डमा दुई फरक दिनको एउटै ठेगाना दुई असम्बन्धित ग्राहक हुन सक्छ। केवल पियर कुञ्जीहरू रेकर्ड गर्ने सर्भरले खाता डेटाबेसबिना तिनलाई ग्राहकसँग जोड्न सक्दैन, र केवल ठेगाना रेकर्ड गर्ने सर्भरले एउटै राउटर पछाडिको ल्यापटप र फोन छुट्याउन सक्दैन।

अनुमान गर्नुको सट्टा दुवै छेउको तुलना गर्नुहोस्

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

ss -uapn 'dport = :51820'
ip -4 route get 203.0.113.10
wg show wg0 endpoints

त्यसपछि राउटर वा CGNAT गेटवेमा अनुवाद प्रविष्टि र अन्ततः सर्भरमा के पुग्छ पढ्नुहोस्:

conntrack -L -p udp --dport 51820
tcpdump -ni eth0 udp port 51820

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

फरकले कहाँ कुरा बिगार्छ

सर्भर त्रुटिजस्तो देखिने अवरोध प्रायः यहीँबाट सुरु हुन्छ। तपाईंको घरको ठेगानामा पिन गरिएको पहुँच नियम ISP लिज बदलिएपछि असफल हुन्छ। अनुवादित ठेगानासँग मिल्ने fail2ban नियमले त्यो गेटवे पछाडिका सबै ग्राहकलाई एकैचोटि प्रतिबन्ध लगाउँछ। स्थिर टाढाको ठेगाना भएको साइट-देखि-साइट पियरले मोबाइल लिंक बदलिएपछि कुञ्जी नवीकरण रोक्छ। टनेल प्रोटोकल ठीक थियो; बाहिरी टुपलको अनुमान थिएन।

त्यही अलमल सर्भरतर्फ पनि देखिन्छ। VPN बक्स आफैं NAT पछाडि छ भने पोर्ट फर्वार्डिङ र काम गर्ने फर्वार्डिङ मार्ग चाहिन्छ; strongSwan फर्वार्डिङ गाइड ले IPsec का लागि त्यो अवस्था समेट्छ। केवल निजी ठेगानामा पुग्न सकिने सर्भरले आफ्ना क्लाइन्टले प्रस्तुत गर्ने अनुवादित टुपल कहिल्यै देख्दैन, र यो क्लाइन्ट अनुवाद हुनुभन्दा फरक समस्या हो।

यी चार जाँच क्रममा गर्नुहोस् र पहिलो असफल भएकोमा रोक्नुहोस्:

• दुवै छेउमा एउटै समयमा क्याप्चर गर्नुहोस्; स्रोत पोर्ट, गन्तव्य पोर्ट र टाइमस्ट्याम्प मिल्ने पुष्टि गर्नुहोस्।
• तपाईंले अपेक्षा गरेको ठेगाना होइन, सर्भरले अहिले राखेको ठेगाना पियर सूचीमा पढ्नुहोस्।
• प्रविष्टि र त्यसको बाँकी आयु conntrack वा NAT तालिकामा जाँच्नुहोस्।
• क्लाइन्टको टनेल इन्टरफेस ठेगाना LAN ठेगाना होइन, सर्भरले तोकेकोसँग मिल्छ भनी पुष्टि गर्नुहोस्।

दुवै क्याप्चर टुपलमा सहमत भए पनि टनेल असफल भयो भने, अनुवाद तपाईंको समस्या होइन; ह्यान्डसेक र टनेलभित्रको राउटिङ तालिकातर्फ जानुहोस्।