WAN IP बदलला आणि टनेल पडला: क्रमाने तपासणी

टनेल पडते, राउटर पुन्हा जोडणी नोंदवते, आणि LAN वर काहीच हलले नाही। नवीन WAN पत्ता आत काहीही न बदलता बाहेरील जोडणी अवैध करतो: क्लायंटचा स्रोत पत्ता बदलला, जुनी NAT स्थिती अशा स्रोताकडे दाखवते जे आता नाही, आणि दूरचा पीअर कदाचित अजूनही मागील पत्त्यावर पाठवत असेल। पुनर्प्राप्ती सामान्य वर्तन आहे, आणि उपयुक्त प्रश्न हा आहे की कोणती स्थिती अद्ययावत झाली नाही।

लॉग वाचण्यापूर्वी घटनेला नाव द्या

प्रवेश स्तरावर प्रत्यक्षात काय घडले ते तपासा। ISP भाडेपट्ट्याचे नूतनीकरण एक घटना आहे। पुन्हा जोडलेले PPPoE सत्र दुसरी आहे। रीबूट झालेला फायबर मोडेम, किंवा एका अपलिंकवरून दुसऱ्यावर WAN फेलओव्हर, बाहेरील पत्ता किंवा त्याचा मार्ग तिसऱ्या पद्धतीने बदलतो। या एकच घटना नाहीत आणि ते एकच अवशेष ठेवत नाहीत।

VPN लॉगमधील पुन्हा जोडणीची ओळही WAN बदलाचा पुरावा नाही। निष्क्रिय कालमर्यादा, पुनर्प्रमाणीकरण अंतराल आणि मृत पीअर ओळख — सर्व पत्ता बदलाशिवाय पुन्हा जोडणी निर्माण करतात। काहीही निष्कर्ष काढण्यापूर्वी प्रवेश लॉगच्या वेळमुद्रांची VPN लॉगशी तुलना करा, आणि रात्रीत झालेला बदलही पकडता येईल इतकी तुलना विंडो रुंद ठेवा।

रोमिंग आणि पुन्हा जोडणी वेगवेगळे प्रोटोकॉल आहेत

WireGuard मध्ये प्रमाणित रोमिंग प्रोटोकॉलमध्येच आंतरिक आहे: पीअर नव्या स्रोत पत्त्यावरून योग्यरित्या प्रमाणित पॅकेट घेतल्यास ते त्या पीअरचा टोकाचा बिंदू अद्ययावत करते। WireGuard ची झटपट सुरुवात हे शक्य करणारे पीअर संरचना वर्णन करते, म्हणून बदलत्या पत्त्यावरील क्लायंट अनेकदा दृश्यमान रीस्टार्टशिवाय सावरतो।

OpenVPN डीफॉल्टनुसार वेगळे वागते। UDP सत्र संपून पुन्हा जोडले जाऊ शकते, आणि ऐच्छिक float वर्तन प्रमाणित पीअरला संरचना परवानगी देते तिथे नव्या पत्त्यावरून सुरू ठेवू देते। TCP आधारित टनेल अधिक कडक आहेत, कारण जोडणी स्वतः पत्ता जोडीशी बांधलेली आहे। तोच फरक ठरवतो की पुनर्प्राप्ती अदृश्य दिसेल की प्रत्येक वेळी लॉगमध्ये स्वतःची घोषणा करेल।

दोन्हीपैकी कोणतेही वर्तन आतील अनुप्रयोगांबद्दल काहीही सांगत नाही। पुनर्प्राप्त टनेल पीअरने आधीच मृत मानलेले TCP सत्र पुनर्संचयित करत नाही।

टनेलच्या मालकीची नसलेली स्थिती

भाषांतर आणि मार्गनिर्देशन स्थिती लोकांना चकित करणाऱ्या पद्धतींनी पुन्हा जोडणीतून टिकून राहते। जुन्या स्रोतासाठी तयार केलेली conntrack नोंद उत्तरेचा मार्ग आता नसलेल्या पत्त्याला खिळवून ठेवते, आणि ती टनेल परत आल्यावर नाही तर स्वतःच्या वेळापत्रकानुसार संपते। टनेल सेवा पुन्हा सुरू केल्याने ती प्रतीक्षा कमी होत नाही, म्हणून दुरुस्त केलेली लिंक काही काळ तुटलेली दिसू शकते।

मार्ग आणि धोरण नियम जुन्या गेटवे किंवा इंटरफेसचा संदर्भ घेऊ शकतात। WAN बदलापूर्वी बरोबर असलेला नियम संच आता बंद असलेल्या उपकरणाकडे दाखवू शकतो, ज्यामुळे जोडलेले असल्याचे नोंदवणारे टनेल आणि कुठेही न जाणारा रहदारी तयार होते। तुम्ही होस्ट करता त्या सर्व्हरसाठीचे गतिशील DNS नवीन स्रोत मिळवणाऱ्या क्लायंटपेक्षा वेगळी समस्या आहे। दूरच्या क्लायंटांना तुम्हाला शोधता येण्यासाठी नोंद अद्ययावत करावी लागेल, आणि वरच्या स्तरावरील भाषांतर पुढे न पाठवणाऱ्या पत्त्याची भरपाई कोणतेही क्लायंट-बाजू संरचनेतून होत नाही।

तपासण्या बाहेरून आतल्या क्रमाने लावा

खालील क्रम बाहेरील जोडणीपासून आत जातो, आणि पहिल्या अयशस्वी पायरीवर थांबणे हेच त्याला उपयुक्त बनवते: प्रत्येक तपासणी वरचा थर वगळते। दोष स्पष्ट दिसत असला तरी हा क्रम पाळा।

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

पहिला आदेश प्रत्येक पीअरसाठी सध्याचा टोकाचा बिंदू आणि हस्तांदोलनाचे वय दाखवतो। दुसरा आणि तिसरा बाहेरील इंटरफेस आणि टोकाच्या बिंदूपर्यंतचा मार्ग अजूनही अर्थपूर्ण आहे का ते दाखवतात। conntrack संख्या मागील पत्त्यापासून उरलेल्या स्थितीची ढोबळ तपासणी आहे, आणि जर्नल हे पुन्हा जोडणीचे कारण नोंदवले जाणारे ठिकाण आहे।

नंतर राउटरऐवजी LAN क्लायंटवरून चाचणी करा। राउटरनेच पाठवलेला पिंग फॉरवर्ड केलेल्या रहदारीपेक्षा वेगळा मार्ग वापरतो, म्हणून यशस्वी राउटर पिंग टनेल अस्तित्वात असल्याचे सिद्ध करतो, आणि क्लायंटच्या पोहोचीबद्दल काहीही सांगत नाही।

अपेक्षित वर्तन ठरवा आणि ते लिहून ठेवा

बहुतेक तैनातीसाठी पुन्हा जोडणे हे योग्य वर्तन आहे, म्हणून उद्देश ते रोखणे नाही। त्याऐवजी अंतराच्या काळात रहदारीचे काय व्हावे ते ठरवा: थांबवणे, धरून ठेवणे, किंवा दुसऱ्या मार्गावर फेलओव्हर करणे। तो निर्णय फायरवॉल आणि मार्गनिर्देशन धोरणाचा आहे, VPN प्रोफाइलचा नाही।

एका आठवडाभर प्रवेश घटना आणि पुन्हा जोडणीच्या वेळा एकत्र नोंदवा। जुळणारी प्रवेश घटना नसताना वारंवार होणारे बदल प्रवेश सेवेकडे निर्देश करतात, आणि VPN प्रोफाइल बदलल्याने सतत पुन्हा वाटाघाटी करणारी अपलिंक दुरुस्त होणार नाही। एकाच मिनिटातील नोंदींची एक जोडी त्या घटनेचा प्रश्न निकाली काढते आणि पुढच्यासाठी आधाररेषा देते।