ESP సరిగ్గా డీక్రిప్ట్ చేస్తుంది మరియు లోపలి ప్యాకెట్ ఇప్పటికీ ఎక్కడికీ వెళ్లదు
యాప్కు ఏమీ కనిపించకుండానే ESP కౌంటర్లు పెరుగుతున్నాయి. ట్రైలర్లోని తదుపరి హెడర్ లోపలి ప్యాకెట్తో సరిపోలాలి, ఇది సెలెక్టర్ తప్పిపోవడం నుంచి భిన్నమైన లోపం.
ESP స్వీకరణ కౌంటర్ పెరుగుతుంది, టన్నెల్ పైనే ఉంటుంది, మరియు అప్లికేషన్కు ప్యాకెట్ ఎప్పటికీ కనిపించదు. డీక్రిప్షన్ జరిగింది, సమగ్రత తనిఖీ పాస్ అయింది, ఆ తర్వాత స్వీకర్త రక్షిత పేలోడ్ నిజానికి ఏమిటో నిర్ణయించాల్సి వచ్చింది. ఆ చివరి దశలోనే ఫార్మాట్ అసమతుల్యత కనిపిస్తుంది, మరియు బయటినుంచి చూస్తే అది ఫైర్వాల్ సమస్యలా అసలు కనిపించదు.
లేబుల్ అబద్ధం చెప్పినప్పుడు ఏమి కనిపిస్తుంది
క్లయింట్ లాగ్లో దీన్ని రూటింగ్ బ్లాక్ హోల్ నుంచి వేరు చేసేది ఏమీ లేదు. రెండూ ఆరోగ్యకరమైన టన్నెల్ పక్కన అప్లికేషన్ టైమౌట్ను సృష్టిస్తాయి, అందుకే మొదట కౌంటర్లపై నింద వేస్తారు.
పెరుగుతున్న స్వీకరణ కౌంటర్ నిజంగా మంచి వార్త: ప్యాకెట్లు వస్తున్నాయి మరియు ధృవీకరించబడుతున్నాయి. కానీ లోపలి ప్యాకెట్ క్రిప్టో పొరకు పైన ఏదైనా అర్థవంతంగా ఉందని ఇది రుజువు కాదు.
రకం ట్రైలర్లో నివసిస్తుంది
సాధారణ IPsec టన్నెల్ మోడ్లో, ESP రక్షించిన పేలోడ్ పూర్తి లోపలి IP ప్యాకెట్ను కలిగి ఉంటుంది. ట్రైలర్లోని తదుపరి హెడర్ ఫీల్డ్ ఆ పేలోడ్ ఏమిటో నిర్ణయిస్తుంది, అది TCP పోర్ట్ కాదు, బయటి హెడర్లోని ప్రోటోకాల్ నంబర్ కాదు, మరియు ప్రారంభ SPI మరియు క్రమ సంఖ్య ఫీల్డ్లో భాగం కాదు. RFC 4303 విభాగం 2.6 దాన్ని పేలోడ్-రకం ఫీల్డ్గా నిర్వచిస్తుంది, ఇది ఖచ్చితమైన పనికి ఖచ్చితమైన పేరు.
మీరు ఎదుర్కొనే విలువలు చిన్నవి మరియు గుర్తుంచుకోదగినవి: IPv4 అంటే 4 (0x04), IPv6 అంటే 41 (0x29).
ఆ సంఖ్యలు స్థానిక ఆచారం నుంచి కాదు, IANA ప్రోటోకాల్ నంబర్ కేటాయింపుల నుంచి వస్తాయి. IPv4 అని ప్రకటించి IPv6 ప్యాకెట్ను చుట్టే పంపినవాడు ఫార్మాట్ అసంగతిని సృష్టించాడు, తన స్వంత లేబుల్కు వ్యతిరేకమైన బైట్లను ఏ ఫైర్వాల్ నియమం సరిచేయదు.
సాధారణ అనుమానితుల నుంచి దీన్ని ఎలా వేరు చేయాలి
పోయిన ప్యాకెట్లలో చాలావరకు ఎన్కోడింగ్ లోపాలు కావు. మొదట సెలెక్టర్లను తనిఖీ చేయండి, ఎందుకంటే IPv6 ప్రిఫిక్స్ను మినహాయించే ట్రాఫిక్ సెలెక్టర్ ఏదైనా ఎన్క్యాప్సులేట్ కాకముందే ట్రాఫిక్ను పడవేస్తుంది. తర్వాత రూటింగ్, ఆ తర్వాత స్వీకరించే హోస్ట్లో స్థానిక ఫిల్టరింగ్ తనిఖీ చేయండి. ఇవి మినహాయించిన తర్వాతే పేలోడ్-ఫార్మాట్ అసమతుల్యత నమ్మదగిన వివరణ అవుతుంది.
ఎన్క్రిప్ట్ చేసిన క్యాప్చర్ దీన్ని తేల్చదు, ఎందుకంటే రక్షిత తదుపరి హెడర్ ఎన్క్రిప్ట్ చేసిన పేలోడ్ లోపల ఉంటుంది. మీకు అమలు నిర్ధారణ లేదా మద్దతు ఉన్న డీక్రిప్ట్ చేసిన పరిశీలన బిందువు అవసరం, రెండింటికీ వాడకానికి ముందు అనుమతి కావాలి.
ఆ రుజువును ఎవరూ ఇవ్వలేకపోతే, మీకు ఫార్మాట్ బగ్ లేదు. మీకు ఒక సిద్ధాంతం ఉంది, సెలెక్టర్లే ఇప్పటికీ మంచి పందెం.
మరమ్మతు ఏమి కాదు
ట్రాఫిక్ దాటడానికి సమగ్రత తనిఖీలను ఆపవద్దు. మధ్యవర్తి రౌటర్లో ఎన్క్రిప్ట్ చేసిన ప్యాకెట్లను తిరిగి రాయవద్దు, ఎందుకంటే అది పని చేయలేదు మరియు క్యాప్చర్లో సహాయకరంగా కనిపిస్తున్నా ప్రవాహాన్ని పాడు చేస్తుంది. పోర్ట్ బ్లాక్ అవుతోందనే సిద్ధాంతంపై యాప్కు మరింత విశాలమైన ఫైర్వాల్ నియమాన్ని తెరవద్దు. వాటిలో ఏదీ లేబుల్ అసమతుల్యతను తాకదు.
ధృవీకరించిన అసమతుల్యత సహచర అమలు నుంచి వస్తే, కనిష్ఠ శుభ్రపరిచిన పునరుత్పత్తిని ఉంచి దాన్ని ఆ అమలు మద్దతు ఉన్న ఛానెల్కు తీసుకెళ్లండి.
ప్రవాహాన్ని ధృవీకరించండి, కౌంటర్ కాదు
సవరణ తర్వాత అసలైన IPv6 ప్రవాహాన్ని మొదటి నుంచి చివరి వరకు పరీక్షించండి: టన్నెల్ ద్వారా యాప్ అభ్యర్థన, దాని ప్రతిస్పందన, మరియు ప్రతి వైపు చూసే చిరునామా జత. పెరుగుతున్న ESP కౌంటర్ ప్యాకెట్లు స్వీకరించబడుతున్నాయని, ధృవీకరించబడుతున్నాయని మాత్రమే రుజువు చేస్తుంది. లోపలి ప్యాకెట్ ఉపయోగించదగినదా అనే దాని గురించి అది ఏమీ చెప్పదు.
రెండు ఫలితాలను టికెట్లో నమోదు చేయండి. కౌంటర్ కదలికతో పాటు పని చేసే ప్రవాహం ఉంటే అది మరమ్మతు; కౌంటర్ కదలిక మాత్రమే అంటే ప్రారంభించే ముందు మీ దగ్గర ఉన్నదే అది.