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

వంతెనను తాకే ముందు ఘర్షణ సాక్ష్యాలను చదవండి

Windows ఇతర దావాదారు యొక్క హార్డ్‌వేర్ చిరునామాతో పాటు చిరునామా ఘర్షణను నివేదిస్తుంది. ఆ హార్డ్‌వేర్ చిరునామాయే ఉపయోగకరమైన వాస్తవం, ఎందుకంటే అది ఒక హోస్ట్‌పై ఒక ఇంటర్‌ఫేస్‌కు సరిపోతుంది, అయితే ఈవెంట్ చూపించే పేరు నకిలీ ఎక్కడ ఉందో గురించి ఏమీ చెప్పదు. ఏదైనా మార్చే ముందు హార్డ్‌వేర్ చిరునామాను రాసుకోండి.

ARP ఆధారిత నకిలీ గుర్తింపు చిరునామా ఉపయోగించే ముందు పోటీ యజమానులను పరిశీలించి తర్వాత కూడా గమనిస్తూనే ఉంటుంది. అందుకే నెట్‌వర్క్‌ను కాన్ఫిగర్ చేస్తున్నప్పుడు లేని హోస్ట్ ఒక గంట తర్వాత కూడా ఘర్షణ కలిగించగలదు. పరిశీలన బూట్‌లో ఒకసారి చేసే తనిఖీ కాదు. తర్వాత కనిపించే యంత్రం రోజంతా ప్రశాంతంగా వాడుకలో ఉన్న చిరునామాను తీసుకోగలదు, అందుకే ఈ వైఫల్యం కాన్ఫిగరేషన్ లోపంగా కాకుండా పరుగుగా చదవబడుతుంది.

ఘర్షణ సంఘటన ఒంటరిగా ఏ కాన్ఫిగరేషన్ మరో దావాను సృష్టించిందో చెప్పదు, చిరునామాలను ప్రయోగాత్మకంగా తొలగించడం చెప్పే మ్యాపింగ్‌ను నాశనం చేస్తుంది. సాక్ష్యం ఉద్దేశం హార్డ్‌వేర్ చిరునామాను మీరు పరిశీలించగల ఇంటర్‌ఫేస్‌గా మార్చడం. యంత్రం పేరుతో ఇన్వెంటరీ వెతకడం సాధారణంగా తప్పు హోస్ట్‌కు పంపుతుంది.

విభాగంలోని ప్రతి దావాను జాబితా చేయండి

వంతెన చేసిన TAP సెటప్ గతంలో వేరుగా ఉన్న Ethernet విభాగాలను కలుపుతుంది, కాబట్టి తమ నెట్‌వర్క్‌లలో ప్రత్యేకంగా ఉన్న చిరునామాలు ఫ్రేమ్‌లు ఒక లింక్‌ను పంచుకున్నప్పుడు ఢీకొట్టగలవు. అందుకే ఈ లోప వర్గం VPN లో ఉంది, అది భర్తీ చేసిన రూటెడ్ నెట్‌వర్క్‌లలో లేదు. మీరు అనుమానించే మొదటి దానికి బదులు ప్రతి సాధ్యమైన యజమానిని జాబితా చేయండి.

జాబితాను ఈ క్రమంలో చూడండి: ప్రతి వంతెన పరికరం మరియు దాని సభ్య పోర్టులపై చిరునామాలు, OpenVPN పూల్ మరియు ప్రతి క్లయింట్‌కు ఏదైనా స్థిర కేటాయింపు, మరియు వంతెన విభాగాన్ని కవర్ చేసే ఏదైనా DHCP సర్వర్. తర్వాత ఘర్షణ నివేదికలోని హార్డ్‌వేర్ చిరునామాను మీరు కనుగొన్న ఇంటర్‌ఫేస్‌లతో సరిపోల్చండి.

ip -4 addr show | grep -E 'inet |^[0-9]+: '
bridge link show
ip neigh show dev br0

పూల్ మరియు DHCP పరిధి ప్రజలు మరచిపోయే రెండు యజమానులు. రెండు పరిధులను కలిపి ముద్రించి, మరేదైనా చేసే ముందు అతివ్యాప్తి కోసం చూడండి. చేతితో కేటాయించిన వంతెన చిరునామా మరియు అదే విలువను ఇచ్చే పూల్ త్వరలో లేదా ఆలస్యంగా ఢీకొంటాయి, రెండు పరిధులు పక్కపక్కన ముద్రించబడే వరకు ఢీకొనడం యాదృచ్ఛికంగా కనిపిస్తుంది.

వంతెనలకు గుర్తింపు అవసరమైన చోట మాత్రమే సంఖ్య ఇవ్వండి

సాధారణ హోస్ట్ వంతెనలో వంతెన పరికరం హోస్ట్ యొక్క మూడో పొర కాన్ఫిగరేషన్‌ను కలిగి ఉంటుంది, Ethernet మరియు TAP సభ్యులు పోర్టులుగా పనిచేస్తాయి. ప్రతి సభ్యుడికి తన సొంత చిరునామా ఇవ్వడం, లేదా చిరునామాను మార్చకుండా ఒక సెటప్ స్క్రిప్ట్‌ను అనేక యంత్రాలకు కాపీ చేయడం—ఒకే విభాగం ఒకే విలువ యొక్క ముగ్గురు యజమానులను పొందే మార్గం అదే. ఫ్రేమ్‌లను పంపడానికి సభ్యులకు సొంత గుర్తింపులు అవసరం లేదు. ఆ విభాగంలో చేరుకోగలిగి ఉండాల్సిన ప్రతి హోస్ట్‌కు సరిగ్గా ఒక గుర్తింపు అవసరం.

ఫ్రేమ్‌లను మాత్రమే స్విచ్ చేసే వంతెనకు ఆ విభాగంలో చిరునామా అసలు అవసరం లేదు. దాన్ని సంఖ్య లేకుండా వదిలేయడం ఢీకొనడాల యొక్క మొత్తం వర్గాన్ని తొలగిస్తుంది, మీరు ధృవీకరించిన నిర్వహణ మార్గం హోస్ట్‌కు ఇంకా ఉంటే. మొదట యాక్సెస్‌ను నిర్ధారించండి, రెండవదిగా చిరునామాను తొలగించండి, మూడవదిగా చేరుకునే సామర్థ్యాన్ని తనిఖీ చేయండి.

మీరు తొలగించబోయే చిరునామా యంత్రంలోకి ప్రవేశించే ఏకైక మార్గం అయితే, దాన్ని ప్రయోగంగా తొలగించడం నిర్ధారణ కాదు, మీరే సృష్టించుకున్న అంతరాయం. ఏదైనా పరీక్షించే ముందు బయటి మార్గాన్ని ధృవీకరించండి.

సవరణ రీబూట్‌ను తట్టుకునేలా చేయండి

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

ఆ కాన్ఫిగరేషన్ యజమానిని కనుగొనండి: నెట్‌వర్క్ మేనేజర్ ప్రొఫైల్, ప్రతి ఇంటర్‌ఫేస్ ఫైల్, కంటైనర్ లేదా VM నిర్వచనం, లేదా cloud-init శకలం. అక్కడే మార్చండి, తర్వాత కొత్త విలువే తిరిగి వస్తుందని నిర్ధారించడానికి ఉద్దేశపూర్వకంగా ఒక ప్రభావిత హోస్ట్‌ను రీబూట్ చేయండి. రీబూట్ మాత్రమే శాశ్వతత్వాన్ని నిరూపించే పరీక్ష.

DHCP పరిధిలోని వంతెన చిరునామాలను మినహాయింపులుగా రిజర్వ్ చేయండి, లేదా వాటిని బయటకు తరలించండి. స్ప్రెడ్‌షీట్‌లో మాత్రమే ఉన్న రిజర్వేషన్ మినహాయింపు కాదు, కేటాయింపుదారు దాన్ని చదవడు.

ప్రతి క్లయింట్ ఆన్‌లైన్‌లో ఉన్నప్పుడు దీన్ని నిరూపించండి

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

నేరుగా నిర్ధారణ కోసం, చిరునామా కేటాయించే ముందు నకిలీ యజమాని ఉన్నారా అని పరిశీలించి తర్వాత పొరుగు పట్టికను గమనించండి. ఏదీ పరిశీలనకు సమాధానం ఇవ్వకపోతే మరియు పూర్తి రీస్టార్ట్ చక్రంలో చిరునామా ప్రత్యేకంగా ఉంటే, ఘర్షణ దాచబడలేదు, పరిష్కరించబడింది. క్రింది ఆదేశాలు రెండు తనిఖీలను వంతెన పరికరంలో నిర్వహిస్తాయి. RFC 5227 ఈ సాధనాలు చేసే పరిశీలన మరియు ప్రకటన ప్రవర్తనను వివరిస్తుంది, ఎవరైనా గుర్తింపును నిలిపివేయాలని సూచించినప్పుడు ఉదహరించాల్సిన మూలం అదే.

arping -D -I br0 10.8.0.2
ip neigh show dev br0 | grep 10.8.0.2

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

సంబంధిత వ్యాసాలు