सार्वजनिक IP बदलला आणि VPN ने रहदारी पार करणे थांबवले

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

चार तपासण्या क्रमाने करा आणि पहिली अयशस्वी होते तिथे थांबा.

खरंतर कोणता पत्ता बदलला

स्थानिक इंटरफेसच्या स्थितीची तुलना दूरचा टोक ज्या स्रोताला पाहतो त्याच्याशी करा, जिथे तुम्हाला पाहण्याचा अधिकार आहे तिथून. नवीन सार्वजनिक पत्ता म्हणजे नवीन स्थानिक गेटवे नाही, आणि स्थानिक इंटरफेस बदलल्याने सार्वजनिक स्रोत सरकल्याची हमीही मिळत नाही. मधले भाषांतर म्हणजे ही दोन स्वतंत्र तथ्ये आहेत. अचूक मार्ग आणि तुम्ही तो कधी पाहिला तो वेळ नोंदवा, कारण जुन्या अहवालातून कॉपी केलेले भौगोलिक स्थान लेबल वेगळ्या प्रश्नाचे उत्तर देते.

बाहेरील स्रोत बदलला, आतील बोगद्याचा पत्ता बदलला, की दोन्ही — हे विशेष विचारा. फक्त पहिलेच अशा सोबत्याचे स्पष्टीकरण देते जो आता अस्तित्वात नसलेल्या मार्गावर पाठवत राहतो.

स्थलांतर प्रोटोकॉलला हाताळू द्या

सोबती सरकला हे जाणून घेण्याच्या पद्धतीत प्रोटोकॉल वेगळे आहेत, आणि तुम्ही अजिबात हस्तक्षेप करावा का या प्रश्नात हा फरक महत्त्वाचा आहे. WireGuard त्या सोबत्याच्या किल्लीने प्रमाणित होणारे पॅकेट मिळाल्यावर त्याचा एंडपॉइंट अद्ययावत करते, म्हणून कोणत्याही संरचनेशिवाय पत्ता बदल स्वीकारता येतो. IKEv2 मध्ये त्याच उद्देशासाठी MOBIKE आहे, जिथे दोन्ही टोके त्याला आधार देतात. जुनी रचना त्याऐवजी बोगदा पुन्हा बांधून सावरतात.

जे करू नये ते म्हणजे प्रमाणित न केलेला संदेश सोबत्याची ओळख सरकली याचा पुरावा म्हणून स्वीकारणे. नवीन पत्ता दावणारा डेटाग्राम बनावट करणे सोपे आहे, आणि क्लायंटला हल्लेखोराच्या एंडपॉइंटकडे वळवता येते असे त्याला वाटते. प्रमाणित प्रोटोकॉल हेच साधन आहे; सूचना नाही.

wg show wg0 endpoints
wg show wg0 latest-handshakes
conntrack -L -p udp --dport 51820 | head -n 10

जुने बाहेरील बंधन साफ करा

प्रोटोकॉल रोमिंगला आधार देतो पण रहदारी अजूनही अयशस्वी होत असेल, तर अडथळा बहुतेक वेळा मध्यभागी असलेले स्थिती ठेवणारे उपकरण असते किंवा दूरच्या टोकावरील धोरण. जुन्या प्रवाहाचा मागोवा घेणारा फायरवॉल जुनी नोंद ठेवू शकतो, आणि जुन्या स्रोताशी बांधलेला सर्व्हर-बाजूचा प्रवेश नियम नव्याला गुपचूप वगळेल. मॅपिंग साफ करून नियम पुन्हा तपासणे अधिकृतता बदलण्यापेक्षा वेगवान आहे.

तपासणीदरम्यान आवश्यक प्रतिबंध लागू ठेवा. बोगदा सावरतो का हे पाहण्यासाठी धोरण मोकळे करणे कारणाबद्दल काहीच शिकवत नाही आणि तैनाती आढळल्यापेक्षा वाईट ठेवते.

नवीन विनंतीने पुन्हा चाचणी करा

बदलापूर्वी स्थापन झालेले अनुप्रयोग सत्र त्याला टिकत नाही, कारण ज्या चौकडीवर ते उभे होते ती आता अस्तित्वात नाही. पुनर्प्राप्तीनंतर नवीन विनंती तयार करा आणि ती पूर्ण होते याची खात्री करा; जुने डाउनलोड शून्यावर थांबलेले पाहून बोगदा अजूनही तुटलेला आहे असा निष्कर्ष काढू नका. हाच एक फरक अशा अहवालांचा मोठा भाग सोडवतो.

नंतर निदानाचे दोन्ही अर्धे नोंदवा: वरच्या टप्प्यात काय बदलले, आणि कोणत्या समर्थित पुनर्प्राप्ती पायरीने प्रवाह परत आणला. पुढची वेळ वेगवान होईल, आणि टीपच ती वेगवान करते.

नवीन विनंती यशस्वी झाली आणि जुनी कधीही पुन्हा सुरू झाली नाही, तर बोगदा दुरुस्त झाला आहे आणि अनुप्रयोगाला फक्त पुन्हा जोडणे आवश्यक आहे.