రౌటర్ రీబూట్ తర్వాత నిలిచిపోయిన VPN: మారిన మూడు విషయాలు
ప్రొఫైల్ మారలేదు, కానీ దాని కింది మార్గం మారింది. ఆధారాలను రీసెట్ చేయడానికి ముందు లోకల్ చిరునామా, అనువదించిన మ్యాపింగ్ మరియు మార్గాన్ని తనిఖీ చేయండి.
రౌటర్ బూట్ అవ్వడం పూర్తవుతుంది, ల్యాప్‌టాప్ అదే SSIDకి తిరిగి చేరుతుంది, మరియు VPN ఏదీ కదలకుండా కనెక్ట్ అయిన స్థితిలో ఉండిపోతుంది. సేవ్ చేసిన ప్రొఫైల్ చెక్కుచెదరలేదు. దాని కింద గడువు ముగిసినది మార్గం, మరియు క్లయింట్ ఇప్పటికీ పాత దాని కోసం నిర్మించిన స్థితిని పట్టుకుని ఉంది.
మూడు షరతులు పరిష్కారాన్ని నిర్ణయిస్తాయి. వాటిని వరుసగా తనిఖీ చేయండి, ఎందుకంటే మొదటి షరతే నిలిచిపోవడాన్ని వివరిస్తే మిగతావి వృథా శ్రమ.
షరతు ఒకటి: లోకల్ చిరునామా మారింది
రీబూట్ యంత్రానికి వేరే చిరునామా ఇవ్వగలదు. అప్పుడు స్థిర లోకల్ ఎండ్‌పాయింట్‌తో కాన్ఫిగర్ చేసిన VPN ఇక లేని కనెక్షన్‌ను ఉపయోగిస్తూనే ఉంటుంది. తన సాకెట్‌ను పాత చిరునామాకు కట్టిన క్లయింట్‌కు కూడా ఇదే వర్తిస్తుంది. టన్నెల్ ఇంటర్‌ఫేస్ పైన ఉండవచ్చు, కానీ అది ఉత్పత్తి చేసే ప్రతి ప్యాకెట్ నిరుపయోగ ప్రదేశానికి వెళ్తుంది.
క్లయింట్ ఉపయోగిస్తున్న చిరునామాను ఇంటర్‌ఫేస్ ఇప్పుడు కలిగి ఉన్న చిరునామాతో పోల్చండి. మారిన గేట్‌వే వైపు చూపే డిఫాల్ట్ మార్గం కూడా అదే సమస్య మరో పేరుతో.
ip -4 addr show
ip route show default
ip route get 203.0.113.10షరతు రెండు: అనువదించిన మ్యాపింగ్ పోయింది
ఇంటి రౌటర్లు బయటకు వెళ్లే ప్రవాహాలను అనువదిస్తాయి, ఆ మ్యాపింగ్‌లు మెమరీలో నివసిస్తాయి. రీబూట్ వాటిలో ప్రతిదీ తుడిచేస్తుంది. ఇది కొత్త కనెక్షన్‌కు హానికరం కాదు, తన ప్రస్తుత ప్రవాహం ఇంకా చెల్లుబాటులో ఉందని నమ్మే టన్నెల్‌కు ప్రాణాంతకం. అప్పుడు అవతలి వైపు ఏమీ చూడదు, కాబట్టి క్లయింట్‌కు చర్య తీసుకోగల లోపం ఎప్పటికీ రాదు.
ఇక్కడే keepalive లేని టన్నెల్ బిగ్గరగా విఫలం కాకుండా నిశ్శబ్దంగా ఆగిపోతుంది. WireGuard యొక్క పత్రబద్ధమైన పరిమితులు అదే రకమైన వైఫల్యాన్ని వివరిస్తాయి. తప్పు ఎండ్‌పాయింట్ స్థితి నిర్ధారణకు బదులు విసిరిన ప్యాకెట్లను ఉత్పత్తి చేస్తుంది.
25 సెకన్ల నిరంతర keepalive సాధారణ ఉపశమనం, ఎందుకంటే నిష్క్రియ కాల పరిమితి ముగిసే ముందు మ్యాపింగ్‌ను రిఫ్రెష్ చేస్తుంది. ఇప్పటికే పోయిన మ్యాపింగ్‌ను అది సరిచేయదు. keepaliveను పరిష్కారంగా భావించకుండా తిరిగి కనెక్ట్ అయ్యే లాజిక్‌తో జోడించండి.
షరతు మూడు: పబ్లిక్ చిరునామా మారింది
ఒకవేళ రౌటర్ సొంత బాహ్య చిరునామా మారితే, అవతలి వైపు మూల చిరునామా ద్వారా ఫిల్టర్ చేసే ప్రతిదీ ఇప్పుడు వేరే భాగస్వామిని చూస్తుంది. టన్నెల్ పైకి రావచ్చు, సర్వర్ ఇప్పటికీ ట్రాఫిక్‌ను విసిరేయవచ్చు; ఇది పాడైన క్లయింట్‌లా కనిపిస్తుంది, నిజానికి అది అవతలి చివరి విధానం.
రీబూట్‌కు ముందు మరియు తర్వాత బాహ్య చిరునామాను నమోదు చేయండి. రెండూ భిన్నంగా ఉంటే, ప్రశ్న క్లయింట్ నుండి అనుమతి జాబితా నిర్వహించేవారి వద్దకు మారుతుంది, ల్యాప్‌టాప్‌లో ఆధారాలను రీసెట్ చేయడం సహాయపడదు.
సరైన క్రమంలో పునరుద్ధరించండి
మొదట అవసరమైన captive portal సైన్-ఇన్ పూర్తి చేయండి, ఆపై ప్రక్రియను చంపేయడం బదులు క్లయింట్ తన మద్దతు ఉన్న ప్రక్రియ ద్వారా తిరిగి కనెక్ట్ అయ్యేలా చేయండి. గుర్తింపు మరియు డేటా ట్రాఫిక్ రెండూ తిరిగి వస్తున్నాయా చూడండి, ఎందుకంటే అవి ఒకే కనెక్షన్‌కు రెండు వేర్వేరు దశలు.
కాష్ చేసిన పేజీ ఏమీ నిరూపించదు, తనంతట తాను తిరిగి కనెక్ట్ అయిన చాట్ యాప్ కూడా. మీకు నిజంగా ముఖ్యమైన ఎండ్‌పాయింట్‌ను కొత్త అభ్యర్థనతో పరీక్షించండి. అంతరాయం సమయంలో ప్రత్యక్ష ట్రాఫిక్ విధానాన్ని అమల్లో ఉంచండి, ఎందుకంటే తిరిగి కనెక్ట్ అయ్యే ప్రయత్నం నిరోధం కాదు.
ప్రతి రీబూట్ తర్వాత ఇది పునరావృతమైతే, తిరిగి ప్రయత్నం కంటే నమోదే ముఖ్యం. ముందు మరియు తర్వాత లోకల్ చిరునామా, గేట్‌వే, బాహ్య చిరునామా మరియు క్లయింట్ స్థితిని నమోదు చేసి, తర్వాత రెండు నిలువు వరుసలను పోల్చండి. ఇది అస్పష్టమైన ఫిర్యాదును ఎవరైనా సరిచేయగల జీవిత చక్ర లోపంగా మారుస్తుంది, మరియు మ్యాపింగ్ కాల పరిమితి కారణంగా ధృవపత్రాలు మూడవసారి మారడాన్ని ఆపుతుంది.