तुमचा 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 पत्ता नाही, सर्व्हरने दिलेल्या पत्त्याशी जुळतो याची खात्री करा।

दोन्ही कॅप्चर ट्युपलबाबत सहमत असूनही टनेल अयशस्वी झाल्यास, अनुवाद तुमची समस्या नाही; हँडशेक आणि टनेलमधील राउटिंग तक्त्याकडे जा।