VPN లో SSH ప్రతి నిమిషానికి తెగిపోతుందా? కారణం keepalive కాదు

SSH కనెక్ట్ అవుతుంది, సుమారు ఒక నిమిషం పనిచేస్తుంది, ఆ తర్వాత ప్రతిసారీ దాదాపు అదే విరామంలో గడ్డకట్టుకుపోతుంది. సాధారణ వివరణ నిష్క్రియ టైమౌట్, కాబట్టి ప్రజలు MTU తగ్గించి క్లయింట్ keepalives సెట్ చేస్తారు. నేను పనిచేసిన WireGuard లింక్ ఇవన్నీ ఇప్పటికే దాటింది: చిన్న టన్నెల్ MTU, client-alive సెట్టింగ్లు, కాన్ఫిగర్ చేసిన టన్నెల్ keepalive. తెగుదలలు మార్పు లేకుండా కొనసాగాయి. కారణం అసమమిత LAN మార్గం అని తేలింది, ఈ నమూనాను గుర్తించడం విలువైనది ఎందుకంటే ఇది టైమర్ ఆధారిత ప్రతి పరిష్కారాన్ని ఓడిస్తుంది.

keepalive మీ హోస్ట్ ఇంకా పంపడానికి సిద్ధంగా ఉందని నిరూపిస్తుంది. ఎప్పుడూ దాని గుండా వెళ్లని ప్రతిస్పందనను స్థితి ఉంచే పరికరానికి చూపించలేదు.

అపోహ: keepalives నిశ్శబ్ద తెగుదలను సరిచేస్తాయి

SSH keepalives ఒకే పని కోసం ఉన్నాయి: నిశ్శబ్దాన్ని లెక్కించే ఏదో నిష్క్రియ సెషన్ను తొలగించకుండా నిరోధించడం. అది అవి బాగా చేస్తాయి. ఒక దిశలో మొదటి ప్యాకెట్ను చూసి ఆ తర్వాత ఎప్పుడూ ప్రతిస్పందనను చూడని స్థితి ఉంచే పరికరాన్ని అవి పరిష్కరించవు, ఎందుకంటే క్లయింట్ పంపే ఏదీ ప్రతిస్పందన ఏ ఇంటర్ఫేస్ ఉపయోగిస్తుందో మార్చదు.

MTU మార్పు మరో ప్రసిద్ధ పరిష్కారం, దానికి కూడా అదే వైఫల్య విధానం ఉంది. MTU తగ్గించడం ఫ్రాగ్మెంటేషన్ మరియు మార్గ-MTU సమస్యలకు సహాయపడుతుంది, మార్గానికి ఏమీ చేయదు. మీ టైమర్లు మరియు MTU ఇప్పటికే సమంజసంగా ఉండి, తెగుదల ఇంకా పునరావృత విరామంలో ఉంటే, ఆ విరామం ఎక్కడో టైమౌట్ గురించి చెబుతుంది, ప్యాకెట్ పరిమాణం గురించి కాదు. విరామాన్ని రాసి, మార్గంలోని ప్రతి పరికరంలోని స్థితి టైమౌట్లతో పోల్చండి.

సంకేతం క్రమబద్ధతతో పాటు ఆ విరామంలో సెషన్ ఉపయోగించదగినదిగా ఉండటం. నిష్క్రియ టైమౌట్లు ఏమీ జరగనప్పుడు కొడతాయి; ఇది మీరు టైప్ చేస్తున్నప్పుడు కొడుతుంది.

అదనపు గేట్వే వాస్తవంగా ఏమి చేస్తుంది

ల్యాప్టాప్ మరియు VPN గేట్వేను ఒకే LAN లో ఉంచండి, వేరే LAN firewall ను డిఫాల్ట్ గేట్వేగా ఉంచండి. ల్యాప్టాప్ VPN వైపు ట్రాఫిక్ను firewall కు పంపుతుంది, firewall దాన్ని గేట్వేకు పంపుతుంది, మరియు గేట్వే ప్రతిస్పందనలు నేరుగా LAN దాటి ల్యాప్టాప్కు తిరిగి వస్తాయి. ఆ రెండవ కాలు ఎప్పుడూ firewall గుండా వెళ్లదు, కాబట్టి దాని స్థితి పట్టిక సగం కనెక్షన్ను ఉంచుతుంది.

క్రింది చిరునామాలు ఆ ఏర్పాటును ప్రతిబింబిస్తాయి:

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

రీడైరెక్ట్లు మరియు స్థితి నిర్వహణ తర్వాత పనిచేసే handshake ను వెంటనే కాకుండా తర్వాత చనిపోయే కనెక్షన్గా మారుస్తాయి. ఆలస్యం అనేది స్థితి నమోదు పాతబడటం లేదా కఠినమైన తనిఖీ విఫలమవడం, అందుకే విరామం ఇంత యాంత్రికంగా కనిపిస్తుంది.

వీటిలో ఏదీ క్లయింట్ కాన్ఫిగరేషన్లో కనిపించదు, అందుకే దాని అన్వేషణ సాధారణంగా తప్పు ఫైల్లో ప్రారంభమవుతుంది.

ఒక ఉద్దేశపూర్వక మార్గాన్ని ఎంచుకోండి

పై ఏర్పాటు కోసం, దూర సబ్నెట్ను నేరుగా VPN గేట్వేకు రూట్ చేయడం సగం కనెక్షన్ను తొలగిస్తుంది:

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

ఇవి ఉదాహరణ చిరునామాలు. తదుపరి హాప్ మీ LAN లో చేరుకోగలిగినదిగా ఉండాలి, ప్రిఫిక్స్ ఉద్దేశించిన దూర నెట్వర్క్ ఉండాలి, మరియు రెండవ ఆదేశం దానిపై ఆధారపడే ముందు ఫలితాన్ని చూపుతుంది. గేట్వే మీ సబ్నెట్లో లేకపోతే, ఈ మార్గం మీకు కావలసిన పరిష్కారం కాదు.

firewall ఆ వ్యవస్థల మధ్య ట్రాఫిక్ను పర్యవేక్షించడానికి ఉద్దేశించబడితే, దాని చుట్టూ రూట్ చేయడం తప్పు డిజైన్. బదులుగా రెండు దిశలు సరిహద్దును దాటనివ్వండి మరియు తిరిగి వచ్చే మార్గం సరిపోలేలా ప్రతి వైపు మార్గాలను కాన్ఫిగర్ చేయండి. లక్ష్యం ఒక ఉద్దేశపూర్వక మార్గం, తక్కువ స్థితి తనిఖీ కాదు.

Netgate యొక్క అసమమిత రౌటింగ్ గురించి గమనికలు అదే ఇంటర్ఫేస్ స్థాయి అసమమితిని మరియు అది సృష్టించే స్థితి సమస్యలను వివరిస్తాయి, కాబట్టి స్థితి నిర్వహణను ప్రపంచవ్యాప్తంగా సడలించే ముందు వాటిని చదవండి. ఈ కేసును పోలిన సమయబద్ధ డిస్కనెక్ట్లు తామే సాక్ష్యం కావు. వ్యాసాన్ని ఒక వైఫల్య విధానం వివరణగా పరిగణించి, ప్రపంచ స్థితి విధానాన్ని మార్చే ముందు మీ స్వంత నెట్వర్క్ దానికి సరిపోతుందని నిరూపించండి.

రెండు చివరల నుండి పరీక్షించండి

ల్యాప్టాప్ నుండి గమ్యం వైపు మార్గాన్ని మరియు గమ్యం నుండి ల్యాప్టాప్ వైపు తిరిగి వచ్చే మార్గాన్ని చదవండి; ఇవి రెండు వేర్వేరు నిర్ణయాలు మరియు వాటిలో ఒకటి మాత్రమే తప్పు కావచ్చు. గేట్వే నుండే విజయవంతమయ్యే ping సమస్యను పూర్తిగా దాచగలదు, ఎందుకంటే అది మార్గం ఇప్పటికే సరిగ్గా ఉన్న యంత్రం నుండి ప్రారంభమవుతుంది. నిజమైన సెషన్ రెండు చివరలు చూసే విధంగా రెండు దిశలు మీకు కావాలి.

పరిష్కారం తర్వాత SSH ను మళ్లీ తెరిచి, మునుపు విఫలమైన విరామానికి చాలా దూరంగా సెషన్ను తెరిచి ఉంచండి. ఆ తర్వాత ఆమోదించిన నెట్వర్క్ కాన్ఫిగరేషన్లో మార్గాన్ని శాశ్వతం చేయండి, ఎందుకంటే ఒకసారి చేసే ఆదేశం రీబూట్ ప్రణాళిక కాదు మరియు తదుపరి రీబూట్లో సమస్య కొత్త రహస్యంతో తిరిగి వస్తుంది.

అసమమితి ఎప్పుడు సరైనది

అసమమిత రౌటింగ్ అనేక నెట్వర్క్లలో సాధారణం మరియు నిర్వచనం ప్రకారం పాడైనది కాదు. స్థితి ట్రాకింగ్, అనువాదం లేదా విధానం తాము చూడని మార్గాన్ని చూడటంపై ఆధారపడినప్పుడు అది సమస్య అవుతుంది, మరియు వాటిలో ప్రతిదానికి వేరే పరిష్కారం ఉంది. దాని చుట్టూ పునఃరూపకల్పన చేసే ముందు మధ్య పరికరానికి నిజంగా ఏమి కావాలో తనిఖీ చేయండి.

శాశ్వత సమాధానం రెండు మార్గాలను, రెండింటినీ చూడాల్సిన పరికరాన్ని మరియు దాన్ని సాధ్యం చేసే మార్గాన్ని పేర్కొంటుంది. పరికరాన్ని పేర్కొనలేకపోతే, మీరు ఇంకా కారణాన్ని కనుగొనలేదు.