dnsmasq పోర్ట్ 53ని బైండ్ చేయలేకపోతోంది: దాన్ని పట్టి ఉన్న సాకెట్ను కనుగొనండి

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

ఈ క్రమంలో ఐదు దశలు: లోపాన్ని పునరుత్పత్తి చేయండి, వినేవారిని జాబితా చేయండి, wildcardను అర్థం చేసుకోండి, పనిని అప్పగించండి, ఆపై ధృవీకరించండి.

దశ 1: లోపాన్ని పునరుత్పత్తి చేసి చదవండి

సేవ ఉపయోగించే అదే కాన్ఫిగరేషన్తో dnsmasqను ముందు భాగంలో ప్రారంభించండి, దీనితో లోపం ఊహించాల్సిన లాగ్లో కాకుండా మీ టెర్మినల్లో కనిపిస్తుంది. సందేశంలో చిరునామా కుటుంబం మరియు స్థానిక చిరునామాను గమనించండి. నిర్దిష్ట చిరునామాకు బైండ్ మరియు wildcardకు బైండ్ వేర్వేరు యజమానులతో వేర్వేరు వైఫల్యాలు.

ఖచ్చితమైన పాఠ్యాన్ని ఉంచండి. చిరునామా వాడుకలో ఉంది, అనుమతి వైఫల్యం మరియు లేని ఇంటర్ఫేస్ అన్నీ ప్రారంభ వైఫల్యంగా వస్తాయి, మరియు అవి మూడు వేర్వేరు మరమ్మతులను సూచిస్తాయి.

దశ 2: యజమానులను జాబితా చేయండి

మొదట సాకెట్లను జాబితా చేయండి. మూల పోర్ట్ 53పై ఫిల్టర్ చూడగల అధికారం ఉన్నప్పుడు రెండు రవాణాలను మరియు యాజమాన్య ప్రక్రియను చూపిస్తుంది:

ss -lntup 'sport = :53'

అవుట్పుట్ను నిలువు వరుసలలో చదవండి: రవాణా, స్థానిక చిరునామా, పోర్ట్, ప్రక్రియ. TCP వినేది మరియు UDP వినేది వేర్వేరు సాకెట్లు, కాబట్టి ఒకటి ఆపడం మరొకటి విడుదల చేయదు. wildcard చిరునామా ప్రతి ఇంటర్ఫేస్ను కవర్ చేస్తుంది, అంటే ఏ వరుస పేరుతో పేర్కొనకపోయినా VPN చిరునామా ఇప్పటికే తీసుకోబడింది. మరియు ప్రక్రియ పేరు ఇది పంపిణీ నిర్వహించే రిజాల్వర్, కంటైనర్, లేదా మునుపటి ప్రయోగం నడుపుతూ వదిలినది అని చెబుతుంది.

దశ 3: wildcard ఉచ్చు

bind-interfaces ఎంపిక dnsmasq wildcard సాకెట్ను బైండ్ చేస్తుందా లేదా కాన్ఫిగర్ చేసిన ప్రతి ఇంటర్ఫేస్కు ఒక సాకెట్ను బైండ్ చేస్తుందా అనేది మారుస్తుంది, dnsmasq సూచన వివరించినట్లు. అది లేకుండా dnsmasq wildcardను బైండ్ చేసి బదులుగా అభ్యర్థనలను ఇంటర్ఫేస్ ప్రకారం ఫిల్టర్ చేయవచ్చు, ఇది మరో డీమన్ wildcardను పట్టి ఉన్నప్పుడు వెంటనే విఫలమవుతుంది. Linux bind-dynamicను జోడిస్తుంది, అది ప్రారంభం తర్వాత సృష్టించిన ఇంటర్ఫేస్లను నిర్వహిస్తుంది, VPN ఇంటర్ఫేస్ కనెక్ట్ అయినప్పుడు మాత్రమే కనిపిస్తే ఇది నిజమైన ఆందోళన.

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

దశ 4: పనిని అప్పగించండి

ఏ డీమన్ VPN క్లయింట్లకు మరియు ఏది హోస్ట్కు సమాధానమిస్తుందో నిర్ణయించండి. సొరంగ చిరునామాపై విని పైకి పంపే ఒక రిజాల్వర్ సాధారణ ఏర్పాటు; ప్రతిదీ తానే పోర్ట్ 53ని కలిగి ఉందని భావించే రెండు రిజాల్వర్లు ఏర్పాటే కాదు.

తర్వాత ఆ నిర్ణయాన్ని ప్రతి సేవ యొక్క స్వంత కాన్ఫిగరేషన్లో వ్యక్తపరచండి: వినే చిరునామాలు, ఇంటర్ఫేస్ ఫిల్టర్లు మరియు పంపడం. సేవ యజమాని ద్వారా వాటిని మార్చండి, అది పంపిణీ యూనిట్, నెట్వర్క్ మేనేజర్ లేదా కంటైనర్ రన్టైమ్ అయినా, మార్పు పునఃప్రారంభం తర్వాత కూడా నిలిచి ఉండేలా.

దశ 5: సాకెట్ను ధృవీకరించండి, తర్వాత మార్గం

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

వేరుగా ఉంచాల్సిన మూడు ఫలితాలు: సాకెట్ ఉంది, క్లయింట్ దాన్ని చేరుకుంటుంది, సమాధానం సరైనది.

ఏమి చేయకూడదు

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

మెషీన్ నిర్వహించబడుతుంటే, యాజమాన్య నిర్ణయాన్ని తదుపరి నిర్వాహకుడు కనుగొనే చోట నమోదు చేయండి. ఇమేజ్ మళ్లీ నిర్మించబడిన ప్రతిసారీ పోర్ట్ ఘర్షణలు తిరిగి వస్తాయి.