సమాన ఖర్చు గల మార్గాలు VPN లోపాలను చూడటం ఎందుకు కష్టతరం చేస్తాయి
అనేక సొరంగాలు ఒకే ఖర్చును పంచుకున్నప్పుడు, ప్రతి ప్రవాహం వేరొకదాన్ని ఎంచుకోవచ్చు. విజయవంతమైన ping మీ అప్లికేషన్ నిజంగా ఉపయోగించే మార్గం గురించి ఏమీ చెప్పదు.
ఒక వినియోగదారు అంతర్గత అప్లికేషన్ ఒక యంత్రం నుండి పనిచేస్తుందని, మరొకదాని నుండి విఫలమవుతుందని నివేదిస్తారు, అయితే గేట్‌వే నుండి మీరు నడిపే ping రెండు సందర్భాల్లోనూ విజయవంతమవుతుంది. సమాన ఖర్చు గల అనేక సొరంగాలు ఉన్నప్పుడు ఇది వైరుధ్యం కాదు. ప్రతి ప్రవాహం దాని స్వంత తదుపరి హాప్‌పై ఉంచబడుతుంది, కాబట్టి మీ తనిఖీ మరియు వినియోగదారు సెషన్ వేర్వేరు మార్గాలను ఉపయోగిస్తూ ఉండవచ్చు. క్రింది వివరణ ఏదైనా మార్చే ముందు ఆ ఎంపికను తిరిగి ఉత్పత్తి చేస్తుంది.
ఒక ping, అనేక సాధ్యమైన మార్గాలు
ఒక మార్గంలో ఒకే ఖర్చుతో ఒకటి కంటే ఎక్కువ తదుపరి హాప్‌లు ఉంటే, రౌటర్ ప్రతి ప్యాకెట్‌కు ఒకదాన్ని ఎంచుకోవాలి. చాలా అమలులు ప్యాకెట్‌లోని ఫీల్డ్‌లను హాష్ చేస్తాయి, సాధారణంగా మూలం మరియు గమ్యస్థాన చిరునామాలను ప్రోటోకాల్ మరియు పోర్టులతో పాటు, ప్రతిస్పందనలు అదే మార్గంలో ఉండేలా. వేర్వేరు అప్లికేషన్‌లు, లేదా ఒకే అప్లికేషన్ యొక్క వేర్వేరు కనెక్షన్‌లు కూడా వేర్వేరు హాష్‌లను ఉత్పత్తి చేస్తాయి.
అందుకే గేట్‌వే నుండి చేసిన నిర్ధారణ చాలా తక్కువ నిరూపిస్తుంది. గేట్‌వే యొక్క స్వంత తనిఖీకి దాని స్వంత చిరునామాలు మరియు పోర్టులు ఉంటాయి, అందువల్ల దాని స్వంత హాష్ కూడా. అది ఆరోగ్యకరమైన సొరంగంపై దిగవచ్చు, వినియోగదారు మాత్రం విరిగిన దానిపై దిగుతూనే ఉంటారు.
వేదిక తదుపరి హాప్‌ను ఎలా ఎంచుకుంటుంది
ఊహించడం బదులు ఎంపికను తిరిగి ఉత్పత్తి చేయండి. విఫలమవుతున్న సెషన్‌తో సమానమైన మూలం మరియు గమ్యస్థానానికి కర్నెల్ ఏ మార్గాన్ని ఉపయోగిస్తుందో అడగండి. ఆ శోధనలో సాధారణ గమ్యస్థాన శోధన నిర్లక్ష్యం చేసే ఫీల్డ్‌లు కూడా ఉంటాయి. పనిచేస్తున్న క్లయింట్ నుండి కూడా దాన్ని నడిపి రెండు సమాధానాలను పోల్చండి:
ip route get 10.20.5.7 from 10.20.0.14కొత్త iproute2 విడుదలలు ప్రోటోకాల్ మరియు గమ్యస్థాన పోర్టును కూడా అంగీకరిస్తాయి, హాష్ వాటిని కలిగి ఉన్నప్పుడు ఇది ముఖ్యం. ఆ అవుట్‌పుట్‌ను పనిచేస్తున్న క్లయింట్ నుండి చేసిన అదే శోధనతో పోల్చండి, భేదమే మీకు లేని సాక్ష్యం.
| Observation | Likely cause | First check |
|---|---|---|
| Ping works, application fails | A different flow hash selects another tunnel | Per-flow lookup from the client's address |
| Some users fail, others do not | One tunnel lacks a prefix or selector | Compare both tunnels' installed routes |
| Fails only at larger sizes | Tunnels have different effective MTU | Probe the same size over each path |
| Fails after a reconnect | Stateful asymmetry between paths | Session state on both gateways |
విఫలమయ్యే ప్రవాహాన్ని అనుసరించండి, మార్గ పట్టికను కాదు
మార్గ పట్టిక రెండు సొరంగాలను జాబితా చేస్తుంది మరియు నిర్వచనం ప్రకారం సరిగ్గా కనిపిస్తుంది. ప్రశ్న ఏమిటంటే, ఎంపిక చేసిన తర్వాత ప్రతి సొరంగం ప్యాకెట్‌తో ఏమి చేస్తుంది. రెండూ ఒకే రక్షిత ప్రిఫిక్స్‌లు, ఒకే ఫార్వార్డింగ్ అనుమతి మరియు అదే క్లయింట్‌ను చేరుకునే తిరిగి వచ్చే మార్గాన్ని కలిగి ఉన్నాయని ధృవీకరించండి.
మధ్యలో ఉన్న స్థితి పరికరాలపై శ్రద్ధ వహించండి. ఒక అభ్యర్థన ఒక సొరంగం ద్వారా బయటకు వెళ్లి, సమాధానం మరొక దాని ద్వారా తిరిగి వస్తే, అసలు ప్రవాహాన్ని ఎప్పుడూ చూడని ఫైర్వాల్ లేదా NAT దాన్ని పడవేస్తుంది. రెండు సొరంగాలు ట్రాఫిక్ను సరిగ్గా ఫార్వార్డ్ చేస్తాయి, అయినా కనెక్షన్ విఫలమవుతుంది.
ప్రతి మార్గానికి MTU కూడా తనిఖీ చేయండి. అదనపు ఎన్‌క్యాప్సులేషన్ ఉన్న మార్గం ఉపయోగించగల పరిమాణాన్ని తగ్గిస్తుంది, ఒక సొరంగంలో విజయవంతమయ్యే బదిలీ మరొక దానిలో చిన్నది విరిగే అదే పరిమాణంలో ఆగిపోతుంది.
ఒకసారి ఒక మార్గాన్ని పోల్చండి
నిర్మాణం నిర్వహణను అనుమతించే చోట, ఒక సొరంగాన్ని సేవ నుండి తీసివేసి వినియోగదారు పనిని పునరావృతం చేయండి. లోపం మాయమైతే, సమస్య మీరు తీసివేసిన మార్గానిదే, తదుపరి దశ మార్గదర్శక పట్టికను మళ్లీ పరిశీలించడం కాకుండా దాని కాన్ఫిగరేషన్‌ను పొరుగు మార్గంతో పోల్చడం.
పునరావృత ping కాదు, నిజమైన అప్లికేషన్‌ను పోల్చండి. లోపం ఒక నిర్దిష్ట తదుపరి హాప్, ప్యాకెట్ పరిమాణం లేదా తిరిగి కనెక్ట్ అయిన తర్వాతి మార్పును అనుసరిస్తుందో లేదో నమోదు చేయండి, ఎందుకంటే ఆ మూడు నమూనాలు వేర్వేరు మరమ్మతులను సూచిస్తాయి.
చివరగా, మార్గాలు సమానమని ఎందుకు భావిస్తారు మరియు లోపం వాటిలో ఒకదాన్ని సేవ నుండి ఎలా తీసివేయాలో రాయండి. మార్గాలు నిజంగా పరస్పరం మార్చుకోగలిగినప్పుడే బహుమార్గం సురక్షితం, మరియు అది ఊహించవలసినది కాదు, తనిఖీ చేయవలసిన నిర్మాణ ప్రకటన.