IPsec ESP: అది ఏమి మోసుకెళ్తుంది మరియు అది ప్రవహిస్తున్నదని ఎలా నిరూపించాలి
ESP టనల్ మోడ్లో లోపలి IP ప్యాకెట్ను చుట్టి SPI ద్వారా తన అనుబంధాన్ని గుర్తిస్తుంది. స్థితిని చదవండి, ఆపై ఒక ప్రవాహం కౌంటర్లను ఎలా కదిలిస్తుందో చూడండి.
ESP IPsec VPN లో ట్రాఫిక్ను మోసుకెళ్తుంది, దాని runbook ఒక నియమంతో ప్రారంభమవుతుంది: విధానాన్ని మార్చే ముందు భద్రతా అనుబంధాన్ని చదవండి. వివరించలేని ESP ప్రవర్తనలో ఎక్కువ భాగం సరిపోలని ఎంపికదారుకు, చదవడానికి బదులు ఊహించిన మోడ్కు, లేదా ఒక ప్రవాహం పంపబడుతున్నప్పుడు ఎవరూ తనిఖీ చేయని కౌంటర్కు తిరిగి వెళ్తుంది. క్రింది మూడు దశలు ఏది ఏమి మోసుకెళ్తుందో నిర్ణయిస్తాయి, ఒక ప్రవాహం దాన్ని ఉపయోగిస్తుందని నిరూపిస్తాయి, జ్ఞాపకంపై ఆధారపడని వెనక్కి తిరగడాన్ని మిగులుస్తాయి. ప్రతి దశ రాయదగిన ఒక పరిశీలనను ఇస్తుంది.
చదవడానికి ముందు ఫీల్డ్లను తెలుసుకోండి
ESP రక్షిత డేటా ముందు హెడర్ను, వెనుక ట్రైలర్ను ఉంచుతుంది. హెడర్ స్వీకర్త ఏ అనుబంధాన్ని ఉపయోగించాలో గుర్తించే భద్రతా పరామితి సూచికను, పునరావృత్తిని గుర్తించడానికి క్రమ సంఖ్యను మోసుకెళ్తుంది; ట్రైలర్లో సైఫర్ కోసం పేలోడ్ను సమలేఖనం చేసి ఉంచే ప్యాడింగ్ ఉంటుంది. ట్రైలర్లోని తదుపరి హెడర్ ఫీల్డ్ రక్షిత కంటెంట్ ఏమిటో చెబుతుంది, అలా స్వీకర్త తాను ఏమి డీక్యాప్సులేట్ చేశాడో తెలుసుకుంటాడు.
మోడ్ ఆ రక్షణ లోపల ఏమి ఉందో మారుస్తుంది. టనల్ మోడ్లో రక్షిత పదార్థం పూర్తి లోపలి IP ప్యాకెట్, కొత్త బయటి హెడర్ దాన్ని రెండు చివరల మధ్య మోసుకెళ్తుంది. రవాణా మోడ్లో రక్షణ ఉన్న ప్యాకెట్ పై పొర పేలోడ్ను చుట్టుతుంది, కాబట్టి తెరవడానికి రెండవ IP హెడర్ లేదు. ఏ మోడ్ ఉపయోగించబడుతోంది అనేది కాన్ఫిగరేషన్ వాస్తవం, వ్యాఖ్యాన విషయం కాదు. చిత్రం నుండి ఊహించకుండా స్థితి నమోదు నుండి చదవండి.
రెండు మోడ్లలో ఏదీ ప్యాకెట్ను చేరవేయాల్సిన బయటి చిరునామాను దాచదు. అది రూపకల్పన లక్షణం, లోపం కాదు, అందుకే పేలోడ్ అపారదర్శకంగా ఉన్నా మధ్య పరిశీలకుడు ఏ రెండు చిరునామాలు మాట్లాడుతున్నాయో ఇంకా చూడగలడు.
మొదటి దశ: స్థితిని చదవండి, ఆపై విధానం
స్థితి నమోదులు కీలు మరియు కౌంటర్లను ఉంచుతాయి; విధాన నమోదులు ఎవరు వాటిని ఉపయోగించవచ్చో నిర్ణయించే ఎంపికదారులను ఉంచుతాయి. Linux లో రెండూ ప్యాకెట్ క్యాప్చర్ లేకుండా కనిపిస్తాయి, ఆ క్రమంలో చదవడం రెండు ప్రశ్నలను వేరుగా ఉంచుతుంది.
ip xfrm state
ip xfrm policy
స్థితి అవుట్పుట్లో అనుబంధం యొక్క మూలం మరియు గమ్యం, మోడ్, మరియు ఎన్క్యాప్సులేషన్ UDP పోర్టులను చూపుతుందో లేదో తనిఖీ చేయండి. ఆ పోర్టులు NAT ట్రావర్సల్ ఉపయోగించబడుతోందని అర్థం, ఇది మధ్య ఫైర్వాల్ ఏమి అనుమతించాలో మారుస్తుంది, కానీ చివరల్లో ఏ ఎంపికదారులు లేదా కీలు వర్తిస్తాయో కాదు.
తర్వాత విధానంలోని ఎంపికదారులను చదవండి. మీరు పరీక్షిస్తున్న ట్రాఫిక్ కంటే సన్నని ప్రీఫిక్స్ పేర్కొనే ఎంపికదారే పనిచేసే టనల్ ప్రవాహాన్ని నిర్లక్ష్యం చేస్తున్నట్లు కనిపించడానికి సాధారణ కారణం, తప్పు ప్రోటోకాల్ ఎంపికదారు అదే మౌనాన్ని ఇస్తుంది.
| Field | Where it appears | What it decides |
|---|---|---|
| Security parameter index | ESP header, and the receiving state entry | Which association and keys the receiver applies |
| Sequence number | ESP header | Replay detection for that association |
| Next header | ESP trailer | What the decapsulated payload contains |
| Inner IP header | Inside tunnel-mode payload only | The original source and destination the endpoints act on |
| Traffic selectors | Policy, not the packet | Which local traffic is allowed to use the association |
విక్రేత సాధనాలు అదే సమాచారాన్ని మరింత సౌకర్యవంతమైన రూపంలో ముద్రిస్తాయి. ipsec statusall strongSwan లో అది చైల్డ్ అనుబంధాలు, వాటి ఎంపికదారులు మరియు బైట్ కౌంటర్లను జాబితా చేస్తుంది, ఏ చైల్డ్ చూడాలో ముందే తెలిస్తే ఇది ముడి xfrm అవుట్పుట్ చదవడం కంటే తరచుగా వేగవంతం.
రెండవ దశ: ఒక ప్రవాహం కౌంటర్లను కదిలిస్తుందని నిరూపించండి
కౌంటర్లు వాటిని ఏది కదిలించాల్సి ఉందో తెలిస్తేనే అర్థవంతం, కాబట్టి ఎంపికదారు ఖచ్చితంగా కవర్ చేసే మూలం మరియు గమ్యాన్ని ఎంచుకుని ఒక హానిచేయని అభ్యర్థన పంపండి. తర్వాత అదే నమోదును మళ్లీ చదివి పోల్చండి.
ip -s xfrm state
tcpdump -ni any esp
రెండు పఠనాలు వేర్వేరు కథలు చెబుతాయి. బయటికి వెళ్లే వైపు పెరిగి లోపలికి వచ్చే వైపు ఎప్పుడూ పెరగని ప్యాకెట్లు కీ సమస్యను కాకుండా ఫార్వర్డింగ్ లేదా తిరిగి వచ్చే మార్గ సమస్యను సూచిస్తాయి, ఎందుకంటే ప్యాకెట్ ఎన్క్యాప్సులేట్ అయి వెళ్లిపోయింది. ఏ కౌంటరూ కదలకపోతే ట్రాఫిక్ విధానంతో ఎప్పుడూ సరిపోలలేదు, మరియు చూడాల్సిన స్థలం ఎంపికదారే.
అదే దశలోని క్యాప్చర్ వైర్పై ఎన్క్యాప్సులేషన్ను నిర్ధారిస్తుంది, బయటి ప్యాకెట్లు ESP లేదా UDP లో ఎన్క్యాప్సులేట్ చేసిన ESP అనేది కూడా కలిపి. ప్రవాహాన్ని నిజంగా మోసిన చిరునామాలను కూడా అది చూపుతుంది, అవి కొన్నిసార్లు మీరు చదువుతున్న కాన్ఫిగరేషన్లోని వాటి నుండి భిన్నంగా ఉంటాయి.
మూడవ దశ: ఒక విషయాన్ని మార్చి వెనక్కి తిరగడాన్ని ఉంచండి
ఏదైనా సవరించే ముందు అనుబంధం యొక్క మూలం, గమ్యం, మోడ్, ఎంపికదారులు మరియు కౌంటర్లను నమోదు చేయండి. ఒక మార్పు పరిస్థితిని మరింత దిగజార్చితే, ఊహ నుండి పనిచేసే కాన్ఫిగరేషన్ను తిరిగి నిర్మించడానికి బదులు మునుపటి స్థితిని పునరుద్ధరించడానికి ఆ నమోదే అనుమతిస్తుంది. ఆ నమోదు రాయడానికి ఒక నిమిషం పడుతుంది, తర్వాత ఒక గంట ఆదా చేస్తుంది. మార్పు చేసిన వ్యక్తి తర్వాత మిగిలే ఏకైక కళాఖండం కూడా అదే.
ఒక ఎంపికదారును లేదా ఒక పరామితిని మార్చి, తిరిగి లోడ్ చేసి, అదే ప్రవాహంపై రెండవ దశను పునరావృతం చేయండి. అనుబంధాన్ని తొలగించడం దాన్ని ఉపయోగించే ప్రతి ప్రవాహాన్ని విరగ్గొడుతుంది, కాబట్టి లక్ష్య సవరణ మరియు చైల్డ్ తిరిగి లోడ్ చేయడం ఏమి జరుగుతుందో చూడటానికి స్థితిని ఖాళీ చేయడం కంటే దాదాపు ఎప్పుడూ మెరుగైనది.
ఎంపికదారు సవరణకు వెనక్కి తిరగడం అంటే మునుపటి విధానాన్ని పునరుద్ధరించి తిరిగి లోడ్ చేయడం, ఎంపికదారు స్థానికం కాకుండా చర్చ ద్వారా నిర్ణయమైతే ప్రత్యర్థికి సరిపోయే మార్పు అవసరం కావచ్చనే షరతుతో. ఆ ఆధారాన్ని అది తాజాగా ఉన్నప్పుడే రాయండి, ఎందుకంటే సగం పునరుద్ధరించిన జంట రెండు చివరి స్థితులలో దేనినైనా కంటే ఆలోచించడం కష్టం.
చివరగా, పరిధిని నిజాయితీగా ఉంచండి. ప్రవహిస్తున్న ESP అనుబంధం రెండు గేట్వేలు విభాగాన్ని రక్షిస్తూ చేరవేస్తున్నాయని నిరూపిస్తుంది, పైన ఉన్న అనువర్తనం తన వినియోగదారులను ప్రామాణీకరిస్తుందా లేదా నిల్వ చేసేది గుప్తీకరిస్తుందా అనే దాని గురించి ఏమీ చెప్పదు. అవి వేర్వేరు సాక్ష్యాలతో కూడిన వేర్వేరు నియంత్రణలు, తదుపరి వ్యక్తి గమనికల నుండి దాన్ని పునరావృతం చేయగలిగితేనే runbook పూర్తవుతుంది.