tcpdump IPsec సాదా పాఠాన్ని ఒక దిశలో మాత్రమే ఎందుకు చూపిస్తుంది

మీరు Linux IPsec గేట్‌వే యొక్క బయటి ఇంటర్‌ఫేస్‌పై tcpdump నడుపుతారు మరియు ఒకేసారి రెండు విషయాలు చూస్తారు: లోపలికి వచ్చే ESP ఫ్రేమ్‌లు మరియు వాటి తర్వాత వెంటనే డీక్రిప్ట్ చేయబడిన లోపలి ప్యాకెట్‌లు. బయటికి వెళ్లేటప్పుడు ESP మాత్రమే కనిపిస్తుంది. సహజమైన ముగింపు ఏమిటంటే ప్రతిస్పందనలు పంపబడటం లేదు లేదా IPsec ఒక దిశను గుప్తీకరించి మరొకటి మరచిపోతుంది. రెండూ నిజం కావు.

మీరు చూస్తున్నది క్యాప్చర్ బిందువు. పరికరం యొక్క ప్రసార మార్గం ప్యాకెట్‌లను ప్యాకెట్ సాకెట్‌కు అప్పగించే ముందే కెర్నల్ బయటికి వెళ్లే ప్యాకెట్‌లను మారుస్తుంది, కాబట్టి సాకెట్ బయటికి వెళ్లే లోపలి రూపాన్ని ఎప్పటికీ చూడదు. లోపలికి వచ్చినప్పుడు ప్యాకెట్ మొదట ESPగా పట్టుబడుతుంది మరియు అది తిరిగి స్టాక్‌లోకి ప్రవేశించినప్పుడు డీక్యాప్సులేట్ చేయబడిన ప్రతి కనిపిస్తుంది. అదే ట్రాఫిక్, రెండు వేర్వేరు పరిశీలన విండోలు.

మీరు ఏమి చూస్తారో క్యాప్చర్ బిందువే నిర్ణయిస్తుంది

సాధారణ ఇంటర్‌ఫేస్‌లో AF_PACKET సాకెట్ పరికర పొరకు దగ్గరగా ఉంటుంది. హోస్ట్‌ను విడిచిపెట్టే ప్యాకెట్‌లు మొదట IPsec అవుట్‌పుట్ ప్రాసెసింగ్ గుండా వెళతాయి, అది లోపలి TCP సెగ్మెంట్‌ను ESP లేదా UDP-4500 డేటాగ్రామ్‌గా మారుస్తుంది, ఆ తర్వాతే ఆ పొరకు చేరుతాయి. వచ్చే ప్యాకెట్‌లు తీగ నుండి వచ్చినప్పుడే, ఇంకా గుప్తీకరించబడిన స్థితిలో, సాకెట్‌కు కాపీ చేయబడతాయి, మరియు డీక్రిప్ట్ చేయబడిన ఫలితం తర్వాత కనిపిస్తుంది, స్టాక్ దాన్ని స్థానికంగా అందించినప్పుడు లేదా ముందుకు పంపినప్పుడు.

ఆ క్రమం అసమానతను పూర్తిగా వివరిస్తుంది. ఇది దిశ, విధానం లేదా అప్లికేషన్ ప్రవర్తన గురించి రుజువు కాదు, అలా భావించడం ప్రజలను మొదటి నుండి సరిగ్గా పంపబడిన ప్రతిస్పందన వెంట పడేలా చేస్తుంది. అసాధారణతను నెట్‌వర్క్ కాదు, సాధనమే సృష్టిస్తుంది అనే కొద్ది నెట్‌వర్కింగ్ చిక్కులలో ఇది ఒకటి.

మీరు ఉద్దేశించిన పొరతో ఫిల్టర్‌ను సరిపోల్చండి

tcp port 443 వంటి వ్యక్తీకరణ లోపలి TCP కనెక్షన్‌ను ఎంచుకుంటుంది. బయటికి వెళ్లేటప్పుడు సాకెట్‌ను అడిగే సమయానికి ఆ కనెక్షన్ ఇప్పటికే ESP అయిపోయి ఉంటుంది, కాబట్టి ఫిల్టర్ దేనితోనూ సరిపోలదు. మీరు రక్షిత ట్రాఫిక్‌ను లెక్కించాలనుకుంటే, బదులుగా బయటి రూపంపై ఫిల్టర్ చేయండి: ముడి ESP కోసం ప్రోటోకాల్ 50, లేదా NAT ట్రావర్సల్ ఉన్నప్పుడు UDP పోర్ట్ 4500. రెండు ఫిల్టర్లు రెండు వైపుల మధ్య పోల్చదగిన ప్యాకెట్ సంఖ్యను ఇస్తాయి, సాధారణంగా లెక్కించడానికి కారణం కూడా అదే. ఏదీ లోపలి అభ్యర్థనకు సమాధానం వచ్చిందో లేదో చెప్పదు.

UDP 4500 సంఖ్యను ESP ప్యాకెట్ సంఖ్యగా భావించవద్దు. IKE ఆ పోర్ట్‌ను NAT-T సజీవతా సందేశాలకు మరియు క్యాప్సులేటెడ్ మార్పిడికి కూడా ఉపయోగిస్తుంది, కాబట్టి ఆ సంఖ్యలో మీరు కొలవాలనుకున్న డేటా కాని ట్రాఫిక్ కూడా ఉంటుంది. UDP 500పై ప్రారంభ IKE మార్పిడికి అదే ప్రశ్న అయితే దాని సొంత ఫిల్టర్ కావాలి. నియంత్రణ ట్రాఫిక్‌ను డేటాతో కలిపే సంఖ్య ఏదైనా బ్యాండ్‌విడ్త్ అంచనాను తెలియని మొత్తంలో తప్పుగా చేస్తుంది. వేర్వేరు లెక్కలు వేర్వేరు ప్రశ్నలకు సమాధానం ఇస్తాయి.

ఫిల్టర్ ఏ ప్రశ్నకు సమాధానం ఇస్తుందో దాని పక్కన రాయండి. «బాక్స్ నుండి ఎంత ESP బయటికి వెళ్లింది» మరియు «వెబ్ అభ్యర్థన బాక్స్ నుండి బయటికి వెళ్లిందా» అనేవి వేర్వేరు ఫిల్టర్లతో వేర్వేరు కొలతలు, ఒక క్యాప్చర్ రెండింటినీ తీర్చలేదు. ఆ గమనిక లేకుండా ఇద్దరు వ్యక్తులు ఎప్పుడూ ఒకే విషయాన్ని లెక్కించని సంఖ్యలను పోలుస్తారు.

పరివర్తనకు ముందు గమనించండి, తర్వాత కాదు

బయటికి వెళ్లే సాదా పాఠాన్ని చూడాలంటే, పరిశీలన బిందువును ముందుగా, IPsec అవుట్‌పుట్ ప్రాసెసింగ్‌కు ముందు జరపండి. NFLOG మీకు Netfilter హుక్‌ను ఇస్తుంది, అక్కడ నియమం ఎంచుకున్న ప్యాకెట్‌లను వినియోగదారు స్థల సాకెట్‌కు కాపీ చేయగలదు, దాన్ని tcpdump చదవగలదు. strongSwan యొక్క ట్రాఫిక్ డంప్ మార్గదర్శిని ఈ విధానాన్ని అదే కారణంతో నమోదు చేస్తుంది.

విధాన సరిపోలిక నియమాన్ని సొరంగంలోకి ప్రవేశించబోయే ట్రాఫిక్‌కు మాత్రమే పరిమితం చేస్తుంది. బాక్స్ పంపే ప్రతి ప్యాకెట్‌ను లాగ్ చేయడం బదులు నియమాన్ని నిర్దిష్టం చేసేది -m policy --pol ipsec --dir out. తర్వాత లాగ్ సమూహాన్ని పరిమిత క్యాప్చర్‌తో చదవండి: చిన్న స్నాప్‌షాట్ సంఖ్య మరియు పరిమాణ పరిమితి నిర్ధారణ ట్రాఫిక్ ఆర్కైవ్‌గా మారకుండా నిరోధిస్తాయి. పరిమిత క్యాప్చర్‌ను సమీక్షకుడికి అప్పగించడం కూడా సులభం, అసంబంధిత భారాన్ని లాగకుండా. ఎంత వచ్చిందో చూసిన తర్వాత కాదు, ప్రారంభించే ముందే సంఖ్యను నిర్ణయించండి.

iptables -I OUTPUT 1 -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5
tcpdump -ni nflog:5 -s 128 -c 20 'host 10.83.0.44 and tcp port 8443'

ప్రవాహానికి సరిపోయే హుక్‌ను ఎంచుకోండి. OUTPUT గేట్‌వే స్వయంగా ఉత్పత్తి చేసే ట్రాఫిక్‌ను కవర్ చేస్తుంది; LAN క్లయింట్ నుండి వెళ్లే ప్రయాణం బదులుగా FORWARD గొలుసు గుండా వెళుతుంది, OUTPUTపై ఉన్న నియమం దాన్ని ఎప్పటికీ చూడదు. పైన ఉన్న చిరునామా మరియు పోర్ట్ ఆమోదించబడిన పరీక్ష గమ్యానికి ప్లేస్‌హోల్డర్‌లు.

పరిశీలన ఏమి రుజువు చేస్తుంది

NFLOG లాగింగ్ లక్ష్యం, అంగీకార నిర్ణయం కాదు. అక్కడ కనిపించే ప్యాకెట్ అది హుక్‌ను చేరి నియమంతో సరిపోలిందని చూపిస్తుంది. తర్వాతి ఫిల్టర్ దాన్ని అనుమతించింది, పరికరం దాన్ని పంపింది, లేదా ప్రత్యర్థి ఏదైనా స్వీకరించింది అని అది చూపదు.

ఖాళీ లాగ్ కూడా అంతే అస్పష్టం. నియమం యొక్క ప్యాకెట్ కౌంటర్‌ను తనిఖీ చేయండి, దిశను నిర్ధారించండి, ప్రవాహం నిజంగానే IPsec విధానంతో సరిపోలిందని నిర్ధారించండి, మరియు గమ్యాన్ని నిర్ధారించండి. రెండు వైపులా సరిపోలే కౌంటర్ మాత్రమే పరిశీలనను ముగింపుగా మారుస్తుంది. తర్వాత అదే నియంత్రిత ప్రయత్నానికి రెండు వైపులా భద్రతా సంఘం కౌంటర్లను పోల్చండి, ఎందుకంటే SA కౌంటర్లే ఏది రక్షించబడింది మరియు పంపబడింది అనే దానికి అధికారిక నమోదు.

మరో ఉచిత్రం: ఈ సందర్భంలో «సాదా పాఠం» అంటే IPsec గుప్తీకరణ పొరకు వెలుపల. లోపలి HTTPS సెషన్‌కు ఇంకా దాని సొంత TLS ఉంది. డీక్యాప్సులేట్ చేయబడిన ప్యాకెట్‌ను పట్టుకోవడం అప్లికేషన్ యొక్క TLSను డీక్రిప్ట్ చేయదు, అక్కడ చదవగల HTTP కనిపిస్తే ఆ అప్లికేషన్ మొదటి నుండి HTTPS ఉపయోగించలేదని అర్థం.

శుభ్రం చేయండి మరియు రెండు చివరలను పోల్చండి

పరిశీలన ముగిసిన వెంటనే మీరు చేర్చిన సరిగ్గా అదే నియమాన్ని, దాని యజమాని ప్రకారం, తీసివేయండి. లాగింగ్ నియమాన్ని అలాగే వదిలేయడం ప్రతి సరిపోలే ప్యాకెట్‌పై CPU ఖర్చు చేస్తుంది మరియు నిశ్శబ్దంగా డేటా నిలుపుదల సమస్యను సృష్టిస్తుంది. మీకు చెందని గొలుసును ఫ్లష్ చేయడం బదులు -D తో నియమాన్ని పునరావృతం చేసి తొలగించండి.

iptables -D OUTPUT -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5

అమలు వినియోగదారు స్థల IPsec, XFRM ఇంటర్‌ఫేస్ లేదా హార్డ్‌వేర్ ఆఫ్‌లోడ్ ఉపయోగిస్తే, పరిశీలన బిందువులు కదులుతాయి మరియు ఈ వంటకం అసలు వర్తించకపోవచ్చు. libipsecతో లోపలి ట్రాఫిక్‌ను గమనించడానికి నమోదు చేయబడిన స్థలం TUN పరికరం. మొదట మార్గాన్ని గుర్తించండి, తర్వాత ప్రశ్నకు సమాధానం ఇచ్చే బిందువును ఎంచుకోండి, మరియు పరివర్తన యొక్క తప్పు వైపు చూసినప్పుడు మాత్రమే రెండు దిశలు భిన్నంగా కనిపిస్తాయని ఆశించండి.