Wi-Fi మారినప్పుడు లేదా Ethernet కలిపినప్పుడు మీ VPN ఎందుకు తెగిపోతుంది
'కొత్త SSID, యాక్సెస్ పాయింట్ల మధ్య రోమింగ్ మరియు కలిపిన కేబుల్ టన్నెల్‌ను మూడు వేర్వేరు ప్రదేశాలలో తెగదీస్తాయి. మూల చిరునామా, తర్వాత మార్గం, తర్వాత ప్రోటోకాల్ తనిఖీ చేయండి.'
రెండు విషయాలు ఒకే లోపంగా నివేదించబడతాయి: ల్యాప్‌టాప్ మరో Wi-Fi నెట్‌వర్క్‌కు మారింది, లేదా Wi-Fi నడుస్తున్నప్పుడే కేబుల్ కలిపారు. క్లయింట్ ఇంకా కనెక్ట్ అయిందని చెబుతుంది, ఐకాన్ ఆరోగ్యంగా కనిపిస్తుంది, టన్నెల్ ఏమీ మోసుకెళ్లదు. లోపల మూడు స్థితి భాగాలు మాత్రమే కదలగలవు - లింక్, స్థానిక చిరునామా, డిఫాల్ట్ మార్గం - ఏది కదిలింది అనేది టన్నెల్ తనంతట తాను కోలుకుంటుందా లేదా మళ్లీ కనెక్ట్ కావాలా అనేది నిర్ణయిస్తుంది. ఖాతా సెట్టింగ్‌లను మార్చడం వీటిలో ఒకటి కూడా ఎప్పుడూ సరిచేయనందున నేను వాటిని అదే క్రమంలో తనిఖీ చేస్తాను.
లింక్, చిరునామా మరియు మార్గం స్వతంత్రంగా కదులుతాయి
ఒకే నెట్‌వర్క్ యాక్సెస్ పాయింట్ల మధ్య రోమింగ్ సాధారణంగా L2 సంఘటన. రేడియో మళ్లీ అనుసంధానమవుతుంది, ఇంటర్‌ఫేస్ తన చిరునామాను గేట్‌వేను నిలుపుకుంటుంది, టన్నెల్ ఆధారపడే ఏదీ మారదు, అందుకే పెద్ద కార్యాలయంలో నడవడం కొన్నిసార్లు గమనించకుండా జరిగిపోతుంది. మరో SSIDలో చేరడం అలా కాదు: పాత ఇంటర్‌ఫేస్ కిందపడవచ్చు, DHCP కొత్త చిరునామా, కొత్త గేట్‌వే మరియు కొత్త రిజాల్వర్లు ఇస్తుంది, టన్నెల్ ఉపయోగించిన బాహ్య ప్రవాహం ఇక ఉండదు.
Ethernet మూడో రూపాన్ని జోడిస్తుంది. Wi-Fi ఎప్పుడూ పడిపోదు, కాబట్టి లింక్ సంఘటన అసలు సంభవించదు, కానీ వైర్ ఇంటర్‌ఫేస్ తన స్వంత చిరునామాతో కనిపిస్తుంది మరియు తరచుగా మెట్రిక్‌పై డిఫాల్ట్ మార్గాన్ని గెలుస్తుంది. టన్నెల్ ఇక ఇష్టపడని మార్గంలో కొనసాగుతుంది, లేదా క్లయింట్ తాను ప్రారంభించిన వైర్‌లెస్ నెట్‌వర్క్‌కే సాకెట్‌ను పిన్ చేసి ఉంచుతుంది. బ్రౌజర్ నుండి రెండూ ఒకేలా కనిపిస్తాయి: కేబుల్ కుదురుకున్న క్షణంలోనే పేజీలు ఆగిపోతాయి.
కాబట్టి మొదటి ప్రశ్న Wi-Fi మారిందా అని కాదు. మీరు బద్ధమై ఉన్న చిరునామా, లేదా చివరి బిందువుకు మార్గం, టన్నెల్ నడుస్తున్నప్పుడు మారిందా అనేది.
బాహ్య సాకెట్ ఇప్పుడే మాయమైన చిరునామాకు పిన్ చేయబడింది
ప్రతి టన్నెల్ ఒక బాహ్య ప్రవాహం: స్థానిక చిరునామా మరియు పోర్ట్ సర్వర్ చిరునామా మరియు పోర్ట్‌తో మాట్లాడతాయి. Linuxలో అది పాత మూలానికి బద్ధమైన UDP సాకెట్; చిరునామాను కలిగి ఉన్న ఇంటర్‌ఫేస్ తొలగించబడినప్పుడు, పంపేవి EADDRNOTAVAILతో విఫలమవుతాయి లేదా సర్వర్ ఎప్పుడూ చూడని మూలంతో కొత్త ఇంటర్‌ఫేస్ ద్వారా బయటకు వెళతాయి.
దూరపు వైపు తన సొంత పిన్నును ఉంచుకుంటుంది. MOBIKE లేని IKEv2 SA చిరునామాల జంటతో గుర్తించబడుతుంది, మరియు ఒక OpenVPN సెషన్ తాను నేర్చుకున్న పీర్ చిరునామాకు బద్ధమవుతుంది, NAT మ్యాపింగ్ దాన్ని సృష్టించిన ప్రైవేట్ చిరునామా, పోర్ట్ మరియు పబ్లిక్ చిరునామాకు చెందుతుంది. మరో NAT వెనుకకు వెళ్తే ప్రతి ప్రత్యుత్తరం ఇక లేని మ్యాపింగ్‌కు వెళ్తుంది. మీ మెషీన్‌లో ఏదీ తప్పుగా కాన్ఫిగర్ కాలేదు; ఐదు-టుపుల్ మీరు విడిచిపెట్టిన నెట్‌వర్క్‌ను చూపిస్తుంది.
సిద్ధాంతం నిర్మించే ముందు స్థితిని చదవండి:
ss -unpప్రతి టన్నెల్ సాకెట్ నిజంగా కలిగి ఉన్న స్థానిక చిరునామా మరియు పోర్ట్‌ను చూపిస్తుంది.ip route get 203.0.113.10కెర్నల్ ఇప్పుడు చివరి బిందువు కోసం ఉపయోగించే మూల చిరునామా మరియు పరికరాన్ని ముద్రిస్తుంది.wg show wg0 endpoints,swanctl --list-sasలేదా క్లయింట్ లాగ్ దూరపు వైపు మాట్లాడుతున్నట్టు భావించే పీర్ చిరునామాను చూపిస్తుంది.
సాకెట్ చిరునామా మరియు మార్గ అన్వేషణ సరిపోకపోతే మీరు విరుగుడును కనుగొన్నారు, ఏ క్రెడెన్షియల్ మార్పు దాన్ని తాకదు.
కొత్త మూల చిరునామాతో ప్రతి ప్రోటోకాల్ ఏమి చేస్తుంది
క్లయింట్లు మార్పును వివిధ స్థాయిల్లో గ్రహిస్తాయి, మళ్లీ కనెక్ట్ అయ్యే ప్రవర్తన నుండి ఊహించడం కంటే నేను క్లయింట్ కాన్ఫిగరేషన్‌తో పోల్చేది ఈ పట్టికను.
| Tunnel | Recovery behaviour | Failure signature |
|---|---|---|
| WireGuard | Updates the peer endpoint when an authenticated packet arrives from a new address; no handshake needed if traffic continues. | Handshake current, no return traffic; wg show still lists the old endpoint. |
| IKEv2/IPsec | MOBIKE (RFC 4555) moves the SA to the new address; without it the responder discards packets from an unknown source. | DPD or keepalive timeouts, then a full rekey or a dead SA. |
| OpenVPN over UDP | --float accepts a packet from a new source mid-session; otherwise the session stays tied to the original peer address. | Idle until ping-restart fires, then a visible reconnect. |
| OpenVPN over TCP | The tunnel is a byte stream, so a changed source address breaks it outright. | Immediate reset and a new connection attempt. |
WireGuard రోమింగ్ నియమం ఒక దిశలో మాత్రమే పనిచేస్తుంది: క్లయింట్ మొదట కొత్త చిరునామా నుండి పంపాలి. పాత ఇంటర్‌ఫేస్‌కు బద్ధమైన సాకెట్ అలా ఎప్పుడూ చేయదు, అందుకే టన్నెల్ సజీవంగా కనిపించవచ్చు, దాని హ్యాండ్‌షేక్ టైమర్ వృద్ధాప్యం చెందుతూనే ఉంటుంది. ప్రోటోకాల్ వివరణ చివరి బిందువు నవీకరణ షరతును ఖచ్చితంగా తెలియజేస్తుంది, కాన్ఫిగరేషన్ మార్చే ముందు దాన్ని చదవడం విలువైనది.
MOBIKE చర్చల ద్వారా నిర్ణయమవుతుంది, ఊహించబడదు. సర్వర్ దాన్ని అందించకపోతే క్లయింట్ మళ్లీ స్థాపించాలి, ఇది SA జాబితా లేదా లాగ్ నుండి నిర్ధారించే వాస్తవం, తిరిగే చక్రం నుండి ఊహించేది కాదు.
మార్గాన్ని నిర్ణయించేది రూట్ ప్రాధాన్యత, Wi-Fi ఐకాన్ కాదు
రెండు ఇంటర్‌ఫేస్‌లు పైన ఉన్నప్పుడు కెర్నల్ మెట్రిక్ మరియు ప్రిఫిక్స్ పొడవు ద్వారా ఎంచుకుంటుంది. ip route show default అభ్యర్థులను జాబితా చేస్తుంది, ip route get 203.0.113.10 మూల చిరునామాతో సహా నిజమైన నిర్ణయాన్ని పరిష్కరిస్తుంది. మెట్రిక్ 100లో వైర్ డిఫాల్ట్ మరియు 600లో వైర్‌లెస్ అంటే కేబుల్ కుదురుకున్న క్షణంలోనే చివరి బిందువు కదులుతుంది, అయితే ముందే సాకెట్ తెరిచిన ప్రతి అప్లికేషన్ తన పాత మూలాన్ని నిలుపుకుంటుంది.
Windows కూడా స్వయంచాలక ఇంటర్‌ఫేస్ మెట్రిక్‌లతో అదే చేస్తుంది, లింక్ వేగంతో పక్షపాతం చెందుతుంది. Get-NetRoute -DestinationPrefix 0.0.0.0/0 అభ్యర్థులను క్రమబద్ధీకరిస్తుంది, Find-NetRoute -RemoteIPAddress 203.0.113.10 స్టాక్ ఎంచుకునే ఇంటర్‌ఫేస్ మరియు మూలాన్ని తిరిగి ఇస్తుంది. తన బాహ్య సాకెట్‌ను ఒక ఇంటర్‌ఫేస్‌కు బంధించే క్లయింట్ మెట్రిక్ తిరిగిన తర్వాత కూడా దాన్నే ఉపయోగిస్తుంది; ఇది బంధన నిర్ణయం, రూటింగ్ లోపం కాదు.
Android విభజనను కనిపించేలా చేస్తుంది: ConnectivityManager అందుబాటులో ఉన్న నెట్‌వర్క్‌లను మరియు ప్రత్యేక డిఫాల్ట్‌ను నివేదిస్తుంది, సాకెట్‌ను Network ఆబ్జెక్ట్‌కు బంధించే VPN యాప్ మళ్లీ బంధించే వరకు ఆ బంధాన్ని ఉంచుతుంది. macOSలో, scutil --nwi ప్రాథమిక ఇంటర్‌ఫేస్ మరియు సిస్టమ్ ఉపయోగించే క్రమాన్ని ముద్రిస్తుంది.
DNS, MTU మరియు IPv6 కనెక్షన్‌తో పాటు కదులుతాయి
కొత్త కనెక్షన్ కొత్త రిజాల్వర్‌లను తెస్తుంది. systemd-resolvedతో DNS ప్రతి లింక్‌కు, resolvectl status ఏ లింక్ పేరుకు సమాధానమిస్తుందో చూపిస్తుంది, తన రిజాల్వర్‌ను పంచే గెస్ట్ నెట్‌వర్క్ లింక్ మళ్లీ ప్రాధాన్యం పొందే వరకు టన్నెల్ నెట్టిన DNSని ఉపయోగించకుండా వదిలేయవచ్చు. క్యాప్టివ్ పోర్టల్ దాన్ని మరింత దిగజార్చుతుంది: మొదటి HTTPS అభ్యర్థనకు చివరి బిందువు బదులు పోర్టల్ సమాధానమిస్తుంది, క్లయింట్ చనిపోయిన సర్వర్‌ను నమోదు చేస్తుంది.
మార్గం యొక్క MTU కూడా మారుతుంది. Ethernet మరియు Wi-Fi సాధారణంగా 1500 బైట్లను మోసుకెళ్తాయి, PPPoE 1492, మొబైల్ లింక్‌లు తరచుగా తక్కువ. చిన్న MTU వారసత్వంగా పొందిన టన్నెల్ పెద్ద ప్యాకెట్లలో ఆగిపోతుంది, చిన్న అభ్యర్థనలు దాటుతాయి, ఇది సగం విరిగిన కనెక్షన్‌గా చదవబడుతుంది. ping -M do -s 1472 203.0.113.10 DF సెట్ చేసిన 1500 బైట్ల ప్యాకెట్ పంపుతుంది; మౌనం అంటే మార్గం మీరు ఊహించిన దాని కంటే చిన్నది.
IPv6 మిగిలిన సగం. కొత్త ప్రిఫిక్స్ ఇచ్చే నెట్‌వర్క్ ద్వంద్వ స్టాక్ క్లయింట్ ఉపయోగించే మూలాన్ని మారుస్తుంది, v4 మాత్రమే ఉన్న టన్నెల్ విధానం వచ్చే వరకు v6 ట్రాఫిక్‌ను బయట ఉంచుతుంది. ip -6 route show default మరియు ip -6 addr show కొత్త లింక్‌కు v6 మార్గం ఉందా అని సమాధానమిస్తాయి.
వివరించడం బదులు పరివర్తనను మళ్లీ సృష్టించండి
ఒక హానిచేయని అభ్యర్థనను ఎంచుకుని మార్పు రెండు వైపులా అదే మూడు ఆదేశాలను నడపండి: ip -br addr, ip route show default, ip route get 203.0.113.10. తర్వాత టన్నెల్ ఇంకా ప్యాకెట్లు విడుదల చేస్తుందా చూడండి - tcpdump -ni any udp port 51820 WireGuard కోసం ఇది, మిగిలిన అన్నింటికి సరిపోయే పోర్ట్. పాత మూలం నుండి బయటకు వెళ్లే ప్యాకెట్లు బంధన సమస్యను సూచిస్తాయి. కొత్త మూలం నుండి ప్రత్యుత్తరం లేకుండా వెళ్లే ప్యాకెట్లు దూరపు వైపు లేదా మధ్యలోని NATను సూచిస్తాయి.
మొదటి లోపంతో ఏ సంఘటన జరిగిందో గుర్తించండి: లింక్ కిందకు, చిరునామా మార్పు, లేదా డిఫాల్ట్ మార్గం మార్పు. ఇవి వేర్వేరు బాధ్యులను సూచిస్తాయి - మళ్లీ బంధించాల్సిన క్లయింట్, మళ్లీ పొందాల్సిన చిరునామా, లేదా కాన్ఫిగరేషన్ ఫైల్‌కు చెందిన, శాశ్వత బైపాస్ నియమానికి చెందని మార్గం.
సరిచేయబడిందని చెప్పే ముందు, ప్రత్యక్ష ట్రాఫిక్ బ్లాక్ విరామం సమయంలో కూడా నిలిచి ఉందని, పేర్లు కొత్త కనెక్షన్ ద్వారా పరిష్కరించబడుతున్నాయని నిర్ధారించండి. మార్పు తర్వాత కూడా క్లయింట్ పాత చివరి బిందువును ఉంచుకుంటే, మొదట రోమింగ్ లేదా float సెట్టింగ్‌ను సరిచేయండి. సరిగ్గా రోమ్ చేసినా ప్రత్యుత్తరం రాకపోతే, సర్వర్ పీర్ గుర్తింపు మరియు మార్గంలోని NAT చూడండి, తదుపరి వ్యక్తి పోల్చగలిగేలా రెండు నెట్‌వర్క్ సందర్భాలను నివేదికలో ఉంచండి.