NAT तय करता है कि आपका VPN सर्वर वास्तव में कौन-सा स्रोत पता देखता है

आप सोचते हैं कि 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 वही काम करता है और प्रमाणित क्लाइंट को नए पते और पोर्ट से जारी रखने देता है। 2.4 और 2.5 बिल्ड में जहाँ float डिफ़ॉल्ट रूप से बंद है, रीबाइंड सत्र को रीसेट करता है और क्लाइंट फिर से जुड़ता है।

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 पता नहीं।

अगर दोनों कैप्चर टपल पर सहमत हैं और टनल फिर भी विफल होती है, तो अनुवाद आपकी समस्या नहीं है; हैंडशेक और टनल के अंदर की राउटिंग तालिका की ओर बढ़ें।