ప్రత్యుత్తరం లేని బయటకు వెళ్లే ESP అంటే VPN చనిపోయిందని కాదు
ESP ప్రతి అసోసియేషన్కు ఒక దిశను మాత్రమే రక్షిస్తుంది మరియు ఏదీ నిర్ధారించదు. సర్వర్ను ప్రతిస్పందించడం లేదని పిలిచే ముందు లోపలి సంభాషణను మరియు ఇన్బౌండ్ SAను సరిపోల్చండి.
మీరు IPsec హోస్ట్పై ట్రాఫిక్ను క్యాప్చర్ చేసారు, ESP ప్యాకెట్లు బయటకు వెళ్లడం చూసారు, ఏదీ తిరిగి రావడం చూడలేదు, మరియు దూరపు వైపు పాడైందని నిర్ణయించారు. ఆ క్యాప్చర్ ఆ నిర్ణయానికి మద్దతు ఇవ్వదు. ESP సంభాషణలోని ఒక దిశను మాత్రమే రక్షిస్తుంది మరియు IP పొరపై ఏదీ నిర్ధారించదు, కాబట్టి తిరిగి వచ్చే ESP లేకపోవడం అనేది అప్లికేషన్కు చెప్పడానికి ఏమీ లేదని కూడా అర్థం కావచ్చు, టన్నెల్ చనిపోయిందని కూడా అర్థం కావచ్చు. ఏ చివరను నిందించే ముందు లోపలి మార్పిడిని మరియు స్వీకరించే వైపు స్థితిని చదవండి.
అపోహ: ప్రతి రక్షిత ప్యాకెట్కు ప్రత్యుత్తరం లభిస్తుంది
ESP అనేది అభ్యర్థన-ప్రతిస్పందన ప్రోటోకాల్ కాదు. విధానం ఎంచుకున్న దాన్ని అది ఎన్క్రిప్ట్ చేసి ప్రామాణీకరిస్తుంది, మరియు స్వీకర్త ఆ లోపలి ప్యాకెట్ను తనే ప్యాకెట్ను సృష్టించకుండా ధృవీకరించి, డీక్రిప్ట్ చేసి, అందిస్తాడు. గమ్యం పట్టించుకోని UDP ప్రశ్న, లేదా ఇన్బౌండ్ విధానం విసిరే ICMP ప్రతిధ్వని, రెండు దిశలలో నిశ్శబ్దాన్ని సరైన ఫలితంగా సృష్టిస్తాయి. ఆ నిశ్శబ్దాన్ని రవాణా వైఫల్యంగా భావించడం ఎప్పుడూ లేని నెట్వర్క్ లోపాన్ని వెతకడానికి మిమ్మల్ని పంపుతుంది.
ఒక-దిశ క్యాప్చర్ నిజానికి నిరూపించేది ఆ పర్యవేక్షణ బిందువు వద్ద పంపినవారి స్టాక్ ఏదో ఎన్క్రిప్ట్ చేసిందని మాత్రమే. రావడం గురించి ఏమీ లేదు, ప్రత్యుత్తరం ఇవ్వాలనే ఉద్దేశం గురించి కూడా ఏమీ లేదు. ఉపయోగకరమైన ప్రశ్న „ప్రత్యుత్తరం ఎందుకు లేదు“ అని కాదు, „లోపలి సంభాషణ ఏమి ఉత్పత్తి చేసి ఉండాలి“ అని.
రెండు SA, రెండు SPI, ఒక సంభాషణ
IPsec భద్రతా అసోసియేషన్లు ఒక-దిశగా ఉంటాయి, కాబట్టి సాధారణ రక్షిత మార్పిడి వేర్వేరు గుర్తింపులు మరియు స్వతంత్ర స్థితితో ఇన్బౌండ్ అసోసియేషన్ను మరియు అవుట్బౌండ్ అసోసియేషన్ను నడుపుతుంది. అవుట్బౌండ్ ప్యాకెట్ SPI కోసం తిరిగి వచ్చే ట్రాఫిక్ను వెతకడం కాబట్టి ఒక వర్గ లోపం, ఎందుకంటే ఏ ప్రత్యుత్తరమైనా భాగస్వామి స్వంత అవుట్బౌండ్ SA కింద దాని స్వంత SPIతో ప్రయాణిస్తుంది. బదులుగా జతను ట్రాఫిక్ ఎంపికలు మరియు భాగస్వామి చిరునామాల ద్వారా సరిపోల్చండి.
కీ పునరుద్ధరణ కొన్ని సెకన్ల పాటు చిత్రాన్ని సంక్లిష్టం చేస్తుంది, ఎందుకంటే పాత మరియు ప్రత్యామ్నాయ స్థితి ఒకదానిపై ఒకటి అతివ్యాప్తి చెందవచ్చు. లక్షణం కీ మార్పు చుట్టూ ప్రారంభమైతే, కనెక్షన్ పేరు మాత్రమే కాకుండా అసోసియేషన్ గుర్తింపులు మరియు సమయ ముద్రలను కలిపి సేకరించండి.
ఏదైనా ప్రత్యుత్తరం ఇవ్వడానికి ముందు స్వీకర్త ఏమి చేయాలి
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
ప్రతి వరుస స్వతంత్రంగా విఫలమవుతుంది మరియు ప్రతి వైఫల్యానికి వేరే యజమాని ఉంటాడు, అందుకే ఒక క్యాప్చర్ వాటిని వేరు చేయలేదు. ఇన్బౌండ్ కౌంటర్ మాత్రమే రావడానికి నేరుగా సాక్ష్యం, ఎందుకంటే ప్రామాణీకరణ లేదా పునరావృత పరీక్షలో విఫలమైన ప్యాకెట్ ఎలాంటి ప్రతిస్పందన లేకుండా విసిరివేయబడుతుంది. కాబట్టి ఇన్బౌండ్ కౌంటర్ కదలని భాగస్వామి తన విధానం గురించి మీకు ఎలాంటి సమాచారం ఇవ్వడు.
డెలివరీ డీక్రిప్షన్ నుండి వేరే దశ. స్థితి చెల్లుబాటు కావచ్చు మరియు ప్యాకెట్ తర్వాత ఇన్బౌండ్ విధానం లేదా లోపలి గమ్యాన్ని చేర్చని మార్గం ద్వారా విసిరివేయబడవచ్చు, కాబట్టి శుభ్రమైన కౌంటర్ అంటే ప్యాకెట్ మీరు కోరుకున్న చోటికి వెళ్ళిందని ఊహించడం బదులు లక్ష్య హోస్ట్ స్పష్టమైన వచనాన్ని చూసిందా అని తనిఖీ చేయండి.
స్థానిక ESP అనేది UDP కాదు
స్థానిక ESP అనేది IP ప్రోటోకాల్ 50, ఇది TCP కాదు UDP కాదు మరియు దానికి పోర్టులు అసలు లేవు. కాబట్టి UDP 500పై IKEను అనుమతించే ఫైర్వాల్ నియమం డేటా మార్గం గురించి ఏమీ చెప్పదు, పోర్టుల చుట్టూ రాసిన ఫిల్టర్ టన్నెల్ను సంప్రదింపులు చేయనివ్వగలదు, తర్వాత దానిలో తీసుకెళ్లే అన్నింటినీ విసిరివేయగలదు. డేటా మార్గాన్ని మీరు నిజంగా గమనించిన మోడ్లో విడిగా పరీక్షించండి.
NAT వెనుక ఆకారం మారుతుంది: రక్షిత పేలోడ్ UDP లోపల ప్రయాణిస్తుంది, సాధారణంగా 4500 పోర్టులో, RFC 3948 నిర్వచించినట్లు. ఏదైనా నియమం రాసే ముందు క్రియాశీల మోడ్ను నమోదు చేయండి, ఎందుకంటే మార్గంలోని పరికరం స్థానిక ESP మరియు UDPలో చుట్టబడిన ESPను పూర్తిగా భిన్నంగా నిర్వహించగలదు, కొన్ని మధ్య పెట్టెలు ఒకదాన్ని అనుమతించి మరొకదాన్ని విసిరివేస్తాయి.
ఈ సంఘటనకు చెందిన కౌంటర్లను చదవండి
strongSwan హోస్ట్పై swanctl --list-sas రెండు దిశలలో ప్రతి అసోసియేషన్ యొక్క ప్యాకెట్ మరియు బైట్ కౌంటర్లను నివేదిస్తుంది, ఇది „ఎప్పుడూ రాలేదు“ మరియు „వచ్చింది కానీ ప్రత్యుత్తరం ఇవ్వలేదు“ మధ్య వేరు చేయడానికి సరిపోతుంది. Linuxలో /proc/net/xfrm_stat లేని స్థితి, లేని విధానం మరియు ప్రోటోకాల్ లోపాలు వంటి సమగ్ర వైఫల్యాలను లెక్కిస్తుంది. ఆ మొత్తాలు బూట్ నుండి పోగవుతాయి మరియు ఒక నెట్వర్క్ పేరు స్థలానికి చెందుతాయి, కాబట్టి పెద్ద సంఖ్య ఆరోపణ కాదు.
సరైన పేరు స్థలంలో సంఘటన విండో చుట్టూ రెండు పఠనాలు తీసుకుని తేడాలను పోల్చండి, లేకపోతే గత వారం లోపాలను ఈ మధ్యాహ్నం టికెట్కు ఆపాదిస్తారు. పేరు స్థలాన్ని మరియు రెండు సమయ ముద్రలను టికెట్లో పెట్టండి, తద్వారా తదుపరి పాఠకుడు మొత్తాన్ని నమ్మడం బదులు పోలికను పునరుత్పత్తి చేయగలడు.
దశకు పేరు పెట్టండి, అనుమానితుడికి కాదు
ఉపయోగకరమైన ముగింపు ప్యాకెట్ ఎక్కడ ఆగిందో చెబుతుంది: ఎప్పుడూ అందలేదు, అంది విసిరివేయబడింది, పంపబడింది కానీ ప్రత్యుత్తరం లేదు, లేదా ప్రత్యుత్తరం ఇచ్చి తిరిగి వచ్చే మార్గంలో పోయింది. వీటిలో ప్రతి ఒక్కటి వేరే యజమానిని మరియు వేరే తదుపరి ఆదేశాన్ని సూచిస్తుంది. „VPN సర్వర్ నుండి ప్రతిస్పందన లేదు“ అనేది క్యాప్చర్ ఎప్పుడూ సమర్థించని ఒక వాక్యంలో నాలుగు భిన్న లోపాలను కుదిస్తుంది.
క్యాప్చర్లను ఇరుకుగా ఉంచండి, కర్నెల్ ముడి స్థితిని టికెట్లలో పెట్టకండి, ఎందుకంటే అది హోస్ట్ను విడిచిపెట్టకూడని కీ మెటీరియల్ను తీసుకెళ్లవచ్చు. కౌంటర్ తేడాలు మరియు సమయ ముద్రలు తదుపరి వ్యక్తికి అప్పగించదగిన భాగాలు.