VPN తోటి ఇతర ఇంటర్ఫేస్‌లకు పింగ్ చేస్తుంది ఎందుకంటే అవి స్థానికం

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

ఒక మార్గం మరొకరి కోసం ప్యాకెట్‌లను ఫార్వర్డ్ చేస్తుంది; మరొకటి వాటిని హోస్ట్‌కే అందిస్తుంది.

హోస్ట్‌కు చిరునామా చేసిన ప్యాకెట్ హోస్ట్‌లోనే ఉంటుంది

రిమోట్ క్లయింట్ హోస్ట్ కలిగి ఉన్న చిరునామాకు IP ప్యాకెట్ పంపుతుంది. రౌటింగ్ ఆ ప్యాకెట్ గురించి ఒక ప్రశ్న అడుగుతుంది: ఈ గమ్యం స్థానికమా? హోస్ట్ కలిగి ఉన్న ప్రతి చిరునామా స్థానిక రౌటింగ్ పట్టికలో కనిపిస్తుంది, మరియు ఆ పట్టిక ప్రధాన పట్టికకు ముందు చూడబడుతుంది, కాబట్టి ప్యాకెట్ మరో ఇంటర్ఫేస్ ద్వారా బయటకు వెళ్లకుండా హోస్ట్ స్వంత స్టాక్‌కు వెళ్తుంది. సమాధానం స్థానికంగా ఉత్పత్తి అవుతుంది, మరియు ప్రశ్న అక్కడి నుండే వచ్చినందున అది టన్నెల్ ద్వారా తిరిగి వస్తుంది.

ఇది మొత్తం యంత్రాంగం. ఎలాంటి ఫార్వర్డింగ్ జరగదు, ఇంటర్ఫేస్ స్థితి మార్పు పాల్గొనదు, మరియు ప్రశ్నలోని చిరునామా మరెక్కడి నుండైనా చేరుకోగలిగి ఉండాల్సిన అవసరం లేదు.

ip_forward ఎందుకు వర్తించదు

వచ్చిన ఇంటర్ఫేస్ కంటే వేరే ఇంటర్ఫేస్ ద్వారా బయటకు వెళ్లాల్సిన ప్యాకెట్‌లను ఫార్వర్డింగ్ నియంత్రిస్తుంది. హోస్ట్‌కే చేసే పింగ్ ఆ మార్గాన్ని ఎప్పటికీ తీసుకోదు: ప్యాకెట్ స్థానికంగా వినియోగించబడుతుంది మరియు సమాధానం స్థానికంగా ఉత్పత్తి అవుతుంది. కాబట్టి net.ipv4.ip_forward=0 సెట్ చేయడం ఇక్కడ ఏమీ మార్చదు, మరియు ఫార్వర్డ్ చైన్‌లోని నియమం ఆ ట్రాఫిక్‌ను ఎప్పటికీ చూడదు. సరైన నియంత్రణ ఇన్‌పుట్ మార్గంలో ఉంది, వచ్చే ఇంటర్ఫేస్ లేదా మూలం ద్వారా పరిమితం చేయబడింది.

అందుకే ఫార్వర్డింగ్ నిలిపివేసి హోస్ట్ వేరుచేయబడిందని భావించడం భద్రత యొక్క తప్పుడు భావనను కలిగిస్తుంది.

నిర్ణయించిన స్థానిక పట్టికను చదవండి

ip rule show సాధారణంగా సున్నా ప్రాధాన్యత నియమాన్ని నివేదిస్తుంది, అది అన్ని శోధనలను మొదట స్థానిక పట్టికకు పంపుతుంది, మరియు ip route show table local హోస్ట్ స్వంత చిరునామాలను స్థానిక పరిధితో జాబితా చేస్తుంది. ఆ పట్టికలో పరిపాలనాపరంగా ఆఫ్ చేసినా ఇంకా కాన్ఫిగర్ చేయబడిన ఇంటర్ఫేస్‌ల చిరునామాలు కూడా ఉంటాయి. స్థిరంగా కేటాయించిన IPv4 చిరునామాలు సాధారణంగా లింక్ తెగినా నిలిచి ఉంటాయి, అందుకే ఆఫ్ చేసిన వంతెనకు పింగ్ ఇంకా విజయవంతమై ఆపరేటర్‌ను ఆశ్చర్యపరచవచ్చు.

IPv6 సరిగ్గా ఈ అంశంలో భిన్నమైనది. లింక్ పడిపోయినప్పుడు దాని చిరునామాలు సాధారణంగా ఉపసంహరించబడతాయి, keep_addr_on_down సెట్ చేయకపోతే. ఒక నియమం రెండింటినీ కవర్ చేస్తుందని భావించకుండా కుటుంబాలను పోల్చండి.

ఒక తోటి నిజంగా ఎంతవరకు చేరుతుంది

ఒక విభాగంలో రౌటర్ స్వంత చిరునామా నుండి వచ్చిన సమాధానం ఆ విభాగం వెనుక ఉన్న యంత్రాల గురించి ఏమీ చెప్పదు. తోటి ఈ మార్గం ద్వారా మరో ఇంటర్ఫేస్ వెనుక ఉన్న హోస్ట్‌ను చేరుకోలేదు; రౌటర్ స్వయంగా కలిగి ఉన్న చిరునామాలను మాత్రమే చేరుకుంటుంది. రౌటర్ చిరునామాకు పింగ్ చేయడం బదులు ప్రత్యేక LAN హోస్ట్‌లో సేవను పరీక్షించడమే ఫార్వర్డింగ్ అసలు అనుమతించబడిందా అని నిర్ణయిస్తుంది.

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

మీరు విరమింపజేయాలనుకున్న చిరునామాలను కూడా తనిఖీ చేయండి. ఇంటర్ఫేస్ నుండి చిరునామాను తొలగించడం పాత చిరునామాపై ఫైర్‌వాల్ నియమాలను పోగు చేయడం కంటే నమ్మదగినది.