IKEv2 మృత సహచరి గుర్తింపు మీ యాప్ను పరీక్షించదు
జీవనశీలత తనిఖీ సహచరుల సంబంధాన్ని పరీక్షిస్తుంది, వెబ్సైట్ ప్రతిస్పందన సమయాన్ని కాదు. ప్రతిస్పందించే గేట్వే పాడైన యాప్ మార్గం పక్కన ఉండవచ్చు.
IKEv2 జీవనశీలత తనిఖీ ఒక ప్రశ్న అడుగుతుంది: రక్షిత నియంత్రణ సంబంధంలో మరో సహచరి ఇంకా సమాధానం ఇస్తోందా. అంతర్గత యాప్ ఆరోగ్యకరంగా ఉందా, గేట్వే వెనుక మార్గం ఉందా, లేదా బ్రౌజింగ్ వేగంగా అనిపిస్తుందా అని ఇది కొలవదు. సొరంగం వెనుక ఉన్న ప్రతి ఉపయోగకరమైన విషయం విఫలమైనా తనిఖీ ఉత్తీర్ణం కావచ్చు.
టైమర్ను మార్చే ముందు రెండు రకాల సాక్ష్యాలను విడివిడిగా చదవండి.
జీవనశీలత తనిఖీ నిజంగా ఏమి అడుగుతుంది
జీవనశీలత మార్పిడి స్థాపిత IKE భద్రతా సంఘం లోపల పంపబడుతుంది మరియు కాన్ఫిగర్ చేసిన విండో లోపు సమాధానాన్ని ఆశిస్తుంది. విజయం అంటే సహచరి IKE అమలు ఇంకా అక్కడ ఉంది మరియు ఇంకా మాట్లాడటానికి సిద్ధంగా ఉంది. ట్రాఫిక్ను మోసే చైల్డ్ భద్రతా సంఘాల గురించి ఇది ఏమీ చెప్పదు, గేట్వేకు ఆవల ఉన్న మార్గనిర్దేశనం గురించి ఏమీ చెప్పదు, మరియు మీరు సొరంగాన్ని తెరిచిన సేవ గురించి ఏమీ చెప్పదు. ఇవి మూడు వేర్వేరు ప్రశ్నలు, మూడు వేర్వేరు వైఫల్య పద్ధతులతో.
సెషన్ నిశ్శబ్దమైనప్పుడు ఎక్కడ చూడాలో ఆ భేదమే నిర్ణయిస్తుంది. డేటా మార్గం పాడైనప్పుడు కూడా సమాధానం ఇస్తూనే ఉన్న సహచరి విధానం, మార్గనిర్దేశనం లేదా దిగువ సేవను సూచిస్తుంది. సమాధానం ఇవ్వడం ఆపే సహచరి చేరుకోగల సామర్థ్యం లేదా దూరపు చివరి సొంత స్థితిని సూచిస్తుంది.
బ్రౌజర్ ముందు భద్రతా సంఘాలను చదవండి
డెమోన్ను అడిగినప్పుడు నియంత్రణ స్థితి మరియు డేటా స్థితి విడివిడిగా జాబితా చేయబడతాయి, ఏదైనా ప్రయత్నించబడిందా అని కౌంటర్లు చెబుతాయి. ఎప్పుడూ ఇన్స్టాల్ చేయని చైల్డ్ సంఘం ఇన్స్టాల్ అయి తరువాత ప్యాకెట్లను పంపడం ఆపిన దానితో పోల్చలేనంత భిన్నంగా కనిపిస్తుంది, అయినా రెండూ ఒకే వినియోగదారు ఫిర్యాదును కలిగిస్తాయి.
ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'
ఫిర్యాదు క్షణంలోని కౌంటర్లతో పాటు స్థితుల పేర్లను టికెట్లో ఉన్నట్టుగానే రాయండి. సొరంగం కింద అనే వివరణ రెండు సంఘాలలో ఏది ముగిసిందో దాస్తుంది, మరియు సాధారణంగా అదే ఉంచుకోదగిన ఏకైక వాస్తవం.
మార్గ వైఫల్యం మృత సహచరిలాగానే కనిపిస్తుంది
ప్రైవేట్ సర్వర్ ఆఫ్లైన్లో ఉన్నప్పుడు, పంపిన మార్గం లేకపోయినప్పుడు, లేదా అంతర్గత పేరు పరిష్కారం పూర్తిగా విఫలమైనప్పుడు గేట్వే నియంత్రణ మార్పిడులకు సమాధానం ఇవ్వగలదు. క్లయింట్ దృష్టికోణం నుండి, ఇవన్నీ సెషన్ నడుస్తోంది మరియు గమ్యం నడవడం లేదు అన్నట్టు కనిపిస్తాయి. తిరిగి వచ్చే మార్గాన్ని ముందుకు వెళ్లే మార్గంతో సమానంగా జాగ్రత్తగా తనిఖీ చేయండి, ఎందుకంటే దూరపు వైపు అసమాన మార్గనిర్దేశనం ఒక దిశలో మాత్రమే నిశ్శబ్దాన్ని కలిగిస్తుంది.
సొరంగం నడుస్తోందా అని పరీక్షించడం బదులు ఉద్దేశించిన యాప్ను నేరుగా పరీక్షించి అది ప్రయత్నించిన చిరునామాను పేర్కొనండి. గేట్వేకు పింగ్ గేట్వే సమాధానం ఇస్తుందని నిరూపిస్తుంది; యాప్ సమాధానం ఇచ్చిందని అది ఎప్పుడూ నిరూపించలేదు. యాప్ ప్రయత్నించిన ఖచ్చితమైన చిరునామాను నమోదు చేయండి. ఆ స్ట్రింగ్ తరువాత శోధనను సన్నగిస్తుంది, మరియు టికెట్ సాధారణంగా వదిలేసే ఏకైక వాస్తవం అదే.
టైమర్లను నిర్ధారణ నుండి దూరంగా ఉంచండి
గుర్తింపు విరామాన్ని తగ్గించడం పనితీరు మార్పు కాదు మరియు సామర్థ్యాన్ని జోడించదు. ప్యాకెట్ నష్టంలో వైఫల్యం ఎంత త్వరగా గుర్తించబడుతుందో మారుస్తుంది, ఇది ఏదీ మెరుగుపరకుండా లక్షణం భిన్నంగా కనిపించేలా చేయగలదు. మొదట వైఫల్యం యొక్క నిజమైన సమయాన్ని నమోదు చేయండి, తరువాత మీకు నిజంగా ఉన్న లింక్కు సహనశీలత తప్పా అని నిర్ణయించండి.
NAT మ్యాపింగ్ రిఫ్రెష్లు కూడా అదే వర్గంలో ఉంటాయి. అవి అనువదించిన మార్గాన్ని ఉపయోగించగలిగేలా ఉంచుతాయి, మరియు దూరపు యాప్ పనిచేస్తుందనడానికి అవి సాక్ష్యం కాదు.
పూర్తి పునరుద్ధరణ విధానం సహచరి మృతంగా ప్రకటించబడినప్పుడు క్లయింట్ ఏమి చేయాలో చెబుతుంది: పునఃప్రారంభం, మూసివేత లేదా పట్టుకోవడం, మరియు అప్పుడు ఇతర ట్రాఫిక్ ఏమి చేయవచ్చో. అది లేకుండా అదే సంఘటన ప్రతి త్రైమాసికంలో మొదటి నుండి మళ్లీ నిర్ధారించబడుతుంది.