గేట్‌వేయా లేక పంపిన క్లయింటా? మూల చిరునామా చదవడం

వెబ్ సర్వర్ ఒక చిరునామాను నమోదు చేస్తుంది, అది గేట్‌వే యొక్క స్వంత ప్రక్రియకు చెందుతుందని అందరూ భావిస్తారు. అనువాద దశలో ప్రైవేట్ చిరునామా మాయమైన పంపిన క్లయింట్‌కు అది చెంది ఉండవచ్చు. గమ్యం కనిపించే నెట్‌వర్క్ మూలాన్ని మాత్రమే చూస్తుంది, అంతకంటే ఎక్కువ ఏమీ లేదు. ఇది సరిహద్దు గురించిన ప్రకటన, మూలాన్ని ఎప్పటికీ నిర్ధారించలేము అనే వాదన కాదు.

గమ్యం వాస్తవంగా ఏమి చూస్తుంది

10.20.0.7 వద్ద ఒక క్లయింట్, బయటి చిరునామా 198.51.100.10 ఉన్న గేట్‌వే, మరియు ఇంటర్నెట్‌లో ఒక గమ్యాన్ని తీసుకోండి. గేట్‌వే క్లయింట్ మూలాన్ని అనువదిస్తే, గమ్యం యొక్క సాకెట్ 198.51.100.10 నమోదు చేస్తుంది. ప్రైవేట్ చిరునామా ప్యాకెట్ నుండి పోతుంది, మరియు గమ్యం ఆ హెడర్ నుండి దాన్ని తిరిగి చదవలేదు. ఈ సంఖ్యలు ఉదాహరణ కోసం, మీ నెట్‌వర్క్ నుండి తీసిన క్యాప్చర్ కాదు.

పరిశీలన ఇప్పటికీ ఉపయోగకరం: గమ్యం అనుమతించాల్సిన లేదా బ్లాక్ చేయాల్సిన నెట్‌వర్క్ మూలాన్ని ఇది గుర్తిస్తుంది. దాని వెనుక ఉన్న వ్యక్తిని లేదా ప్రక్రియను మాత్రం గుర్తించదు. గమ్యం నిర్వాహకుడికి, ఈ భేదం బ్లాక్ నెట్‌వర్క్ నిర్ణయమా లేక ఖాతా నిర్ణయమా అని నిర్ణయిస్తుంది.

అనువాద స్థితి గమ్యానికి కనిపించదు

గేట్‌వే అనువదించిన కనెక్షన్ మరియు అసలు క్లయింట్ మధ్య మ్యాపింగ్‌ను ఉంచుతుంది, గమ్యానికి లేనిది సరిగ్గా ఆ స్థితి. సాంప్రదాయిక NAT వివరణ అనువాద రికార్డును తర్వాత కనిపించే హెడర్ల నుండి వేరు చేస్తుంది. ఒక వైపు చదివితే మరొక వైపు రాదు.

వివిధ డిజైన్లు వివిధ సాక్ష్యాలను ఇస్తాయి. సంరక్షించిన మూల చిరునామాలతో రూట్ చేయబడిన ట్రాఫిక్ క్లయింట్ యొక్క నిజమైన చిరునామాను చూపుతుంది, అయితే అప్లికేషన్ ప్రాక్సీ కనెక్షన్‌ను ముగించి కొత్తదాన్ని సృష్టిస్తుంది. సంరక్షించిన మూలం ఉన్న మార్గానికి క్లయింట్ చిరునామా గమ్యం నుండి తిరిగి రూట్ చేయగలిగి ఉండాలి కూడా, దాన్ని ప్రతి అమరిక అందించదు. లాగ్ లైన్‌ను వివరించే ముందు ఏ డిజైన్ అమర్చబడిందో అడగండి.

conntrack -L -s 198.51.100.10
tcpdump -ni eth0 host 198.51.100.10

TTL మరియు వేలిముద్రలు సూచనలు, సాక్ష్యం కాదు

IPv4 లో TTL పంపినవారు ఎంచుకునే ప్రారంభ విలువ మరియు ప్యాకెట్ దాటిన హాప్‌ల సంఖ్యపై ఆధారపడి ఉంటుంది. రెండు వాస్తవాలు లేకుండా, ఒక విలువ VPN హాప్ జరిగిందని నిరూపించలేదు. తెలిసిన అదనపు రూట్ చేయబడిన హాప్ కూడా LAN రౌటర్, సొరంగ మార్గం లేదా మరో ఫార్వార్డింగ్ ఏర్పాటును వేరు చేయలేదు. TTL భేదాన్ని ప్రశ్నగా పరిగణించండి, ముగింపుగా కాదు.

ఇతర సంకేతాలు కూడా అలాగే ప్రవర్తిస్తాయి. User-Agent హెడర్‌ను అప్లికేషన్ సెట్ చేయవచ్చు, మరియు సమయ సామ్యం పంచుకున్న వ్యక్తికి బదులు పంచుకున్న మౌలిక సదుపాయాలను ప్రతిబింబించవచ్చు. పలువురు వినియోగదారులు ఒక నిష్క్రమణను పంచుకోవచ్చు, ఒక వినియోగదారు సెషన్ల మధ్య మార్గాన్ని మార్చవచ్చు. కలిపి సేకరిస్తే, పలు బలహీన సంకేతాలు గేట్‌వే రికార్డులను సన్నిహితంగా చూడటాన్ని సమర్థించవచ్చు, కానీ పోగుపడటం ద్వారా అవి బలమైన సాక్ష్యాలు కావు.

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

గమ్యం గేట్‌వే పరిపాలనను దూర వినియోగదారు కార్యకలాపాల నుండి వేరు చేయాల్సి ఉంటే, ఆ పాత్రలకు వేర్వేరు ధృవీకరించిన గుర్తింపులు మరియు అనుమతించిన కార్యకలాపాలను ఇవ్వండి. పంచుకున్న పబ్లిక్ మూలం ఇప్పటికీ నెట్‌వర్క్ పరిమితిగా పనిచేయగలదు, కానీ అది వినియోగదారు లేదా పరికర ధృవీకరణకు ప్రత్యామ్నాయం కాదు.

సాక్ష్యాలను లేబుల్‌తో ఉంచండి: గమనించిన మూలం, ధృవీకరించిన ఖాతా, సమయం మరియు పరిశీలనలో ఉన్న అనుమానం. «ఇక్కడ లోపలి మూలం కనిపించదు» అనేదాన్ని «ఎక్కడా ఆరోపణ సాధ్యం కాదు» అని అనువదించవద్దు. నెలల తర్వాత విచారణలో భాగం కాని ఎవరైనా రికార్డును చదివినప్పుడు లేబుల్ ముఖ్యం.

పరిశీలన తేదీ మరియు దాన్ని ఉత్పత్తి చేసిన వ్యవస్థను నమోదు చేయండి. ఆరోపణ లేని లాగ్ భాగాన్ని తర్వాత సమర్థించడం కష్టం.