ip netns exec మరియు DNS: నేమ్‌స్పేస్ లోపల పేర్లు ఎందుకు విఫలమవుతాయి

ఒక ఆదేశం VPN నేమ్‌స్పేస్ లోపల 10.8.0.5 కు ఎటువంటి ఫిర్యాదు లేకుండా చేరుతుంది, అదే ఆదేశం హోస్ట్‌నేమ్‌ను ఉపయోగించిన క్షణంలోనే విఫలమవుతుంది. నేమ్‌స్పేస్‌కు దాని స్వంత ఇంటర్‌ఫేస్‌లు, మార్గాలు మరియు సాకెట్లు ఉన్నాయి; దాని స్వంత రిజాల్వర్ ఫైల్ లేదు. ఏదైనా అక్కడ ఒకటి పెట్టకపోతే, లోపలి ప్రాసెస్ హోస్ట్ యొక్క /etc/resolv.conf చదివి, ఆ నెట్‌వర్క్ స్టాక్ నుండి చేరుకోలేని సర్వర్‌ను అడుగుతుంది.

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

ప్రాసెస్ నిజంగా పొందే రిజాల్వర్ వీక్షణను తనిఖీ చేయండి

మీరు ఉపయోగించిన షెల్ మీరు డీబగ్ చేస్తున్న ప్రాసెస్‌కు సమానం అని భావించకండి. గ్రాఫికల్ అప్లికేషన్, systemd యూనిట్ మరియు కంటైనర్ ప్రతి ఒక్కటి వేరే మౌంట్ లేదా నెట్‌వర్క్ సందర్భంలోకి ప్రవేశించగలవు. అదే లాంచ్ మార్గం ద్వారా లుకప్ నడపండి, మరియు లోపలి నుండి రిజాల్వర్ ఫైల్‌ను ముద్రించండి.

ip netns add తో సృష్టించిన నేమ్‌స్పేస్ కోసం చదవడం-మాత్రమే తనిఖీ చిన్నది:

ip netns exec vpn cat /etc/resolv.conf

ఫలితం చేరుకోగల చిరునామా, loopback స్టబ్, లేదా భిన్న చేరుకోగల సామర్థ్యం ఉన్న ప్రదేశాన్ని సూచించే సింబాలిక్ లింక్‌ను పేర్కొంటుందో లేదో గమనించండి.

exec సహాయకుడు నిజంగా ఏమి మౌంట్ చేస్తాడు

ip-netns సాధనం ప్రతి నేమ్‌స్పేస్ కాన్ఫిగరేషన్‌ను /etc/netns/NAME/ కింద డాక్యుమెంట్ చేస్తుంది. అది ప్రాసెస్‌ను ప్రారంభించినప్పుడు, సహాయకుడు మౌంట్ నేమ్‌స్పేస్‌ను సృష్టించి ఆ ఫైళ్లను వాటి సాధారణ మార్గాలపై bind-mount చేస్తాడు, కాబట్టి ప్రాసెస్ నేమ్‌స్పేస్-నిర్దిష్ట కాపీని చూస్తుంది. ఇది ఈ నిర్దిష్ట లాంచర్ సౌలభ్యం. unshare లేదా కంటైనర్ రన్‌టైమ్ వంటి మరో మార్గం ద్వారా నెట్‌వర్క్ నేమ్‌స్పేస్‌లోకి ప్రవేశించడం దీన్ని స్వయంచాలకంగా పునరుత్పత్తి చేయదు.

ఇక్కడ ఉచ్చు loopback రిజాల్వర్: 127.0.0.53 అంటే నేమ్‌స్పేస్ స్వంత loopback, హోస్ట్ స్టబ్ కాదు. హోస్ట్ నేమ్‌స్పేస్‌లో మాత్రమే వినే స్టబ్ కొత్తదానిలో సేవగా మారదు.

నేమ్‌స్పేస్ చేరుకోగల రిజాల్వర్‌ను ఎంచుకోండి

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

స్వంత రిజాల్వర్ ఉన్న అప్లికేషన్లు, ఉదాహరణకు DNS over HTTPS ఉపయోగించేది, ఫైల్‌ను పూర్తిగా పట్టించుకోకపోవచ్చు. సాధనానికి స్వంత DNS సెట్టింగ్ ఉంటే, resolv.conf మార్చడం దాన్ని ప్రభావితం చేయదు, మరియు నేమ్‌స్పేస్ ఎప్పుడూ సమస్య కాదు.

ఫైల్‌ను సరైన స్థలంలో రాయండి

/etc/netns/NAME/resolv.conf కింద నేమ్‌స్పేస్-నిర్దిష్ట ఫైల్‌ను సృష్టించి, లాంచర్ దాన్ని ప్రదర్శించనివ్వండి. దాన్ని కనీసంగా ఉంచండి: చేరుకోగల ఒకటి లేదా రెండు సర్వర్లు మరియు పనికి అవసరమైన శోధన డొమైన్లు. ప్రాసెస్‌ల సమూహం కోసం ఉద్దేశించిన వీక్షణను సరిచేయడానికి హోస్ట్ యొక్క ఉత్పత్తి చేసిన రిజాల్వర్ ఫైల్‌ను సవరించవద్దు, ఎందుకంటే అది యంత్రంలోని ప్రతి అప్లికేషన్‌ను మారుస్తుంది. హోస్ట్ రిజాల్వర్ మేనేజర్‌ను ఉపయోగిస్తే, దానితో పోరాడే బదులు ఆ మేనేజర్ ద్వారా నేమ్‌స్పేస్ మార్గాన్ని కాన్ఫిగర్ చేయండి.

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

మొత్తం మార్గాన్ని మళ్లీ పరీక్షించండి

నేమ్‌స్పేస్ లోపల సంఖ్యాత్మక చిరునామా, అంతర్గత పేరు మరియు పబ్లిక్ పేరుతో పరీక్షించండి. ఆ క్రమం చేరుకోగల సామర్థ్యాన్ని పరిష్కారం నుండి వేరు చేస్తుంది, అంతర్గత జోన్లను పబ్లిక్ జోన్ల నుండి వేరు చేస్తుంది. తర్వాత నేమ్‌స్పేస్‌ను మళ్లీ సృష్టించి పునరావృతం చేయండి, ఎందుకంటే నడుస్తున్న ఇన్‌స్టాన్స్‌లో మాత్రమే ఉన్న ఫైల్ దానితో పాటే మాయమవుతుంది.

ఫైల్‌ను షెల్ కాదు, ప్రాసెస్ స్వీకరిస్తోందని నిర్ధారించండి. ఇంటరాక్టివ్ షెల్ నుండి పని చేసి సేవ నుండి విఫలమయ్యే లుకప్, మౌంట్-సందర్భానికి సంబంధించిన పరిశోధన, తదుపరి సంఘటనకు ముందు సున్నా నుండి మళ్లీ కనుగొనే బదులు దాన్ని రాసి ఉంచడం విలువైనది.