VPN కంటైనర్ నెట్‌వర్క్‌ను పంచుకోవడం: DNS ఏమవుతుంది

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

దశ 1: హోస్ట్ నుండి కాదు, యాప్ నుండి పరీక్షించండి

సమస్య ఉన్న కంటైనర్ లోపల లుకప్‌ను అమలు చేయండి, హోస్ట్‌లో కాదు, బ్రౌజర్‌లో కాదు. docker exec app-container getent hosts db.internal ముఖ్యమైన ఏకైక ప్రశ్నకు సమాధానం ఇస్తుంది: ఈ ప్రాసెస్ రిజాల్వర్ ఏమి తిరిగి ఇస్తుంది.

హోస్ట్ పేరును పరిష్కరించి కంటైనర్ పరిష్కరించకపోతే, మీరు లోపాన్ని కనుగొన్నారు. దాని తర్వాత ప్రతిదీ దాన్ని సరిచేయడానికి మద్దతు ఉన్న మార్గాన్ని ఎంచుకోవడం.

దశ 2: runtime మద్దతిచ్చే నమూనాను చదవండి

Docker నెట్‌వర్క్ డాక్యుమెంటేషన్ మరో కంటైనర్ నెట్‌వర్క్ మోడ్‌ను పంచుకునే కంటైనర్లకు DNS ఫ్లాగ్‌లపై పరిమితులను నమోదు చేస్తుంది. Composeలో network_mode: service:vpn యాప్‌ను VPN కంటైనర్ పేరుబయలికి కలుపుతుంది, మరియు ప్రతి సేవకు dns సెట్టింగ్‌లు సాధారణ సేవలో లాగా ప్రవర్తించవు. మీకు లభించే పరిష్కారం పంచుకున్న పేరుబయలి కలిగి ఉన్నదే.

వినియోగదారు నిర్వచించిన వంతెన నెట్‌వర్క్‌లు కూడా Docker అంతర్నిర్మిత DNSను డిఫాల్ట్ వంతెన కంటే భిన్నంగా ఉపయోగిస్తాయి. అందుకే dns పనిచేసే వంతెన ఉదాహరణ నుండి కాపీ చేసిన నిబంధన పంచుకున్న స్టాక్‌లో ఏమీ చేయకపోవచ్చు. నిబంధనను కాపీ చేసే ముందు ఏర్పాటును తనిఖీ చేయండి.

లూప్‌బ్యాక్ చిరునామా ఎల్లప్పుడూ సంబంధిత నెట్‌వర్క్ సందర్భాన్ని సూచిస్తుంది. పంచుకున్న పేరుబయలి లోపల, 127.0.0.1 హోస్ట్ రిజాల్వర్ కాదు.

దశ 3: ప్రశ్నను దాని స్వీకర్త వరకు అనుసరించండి

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

బ్రౌజర్ IP-తనిఖీ పేజీ పేరు ప్రశ్నలు ఎక్కడికి వెళ్లాయో చెప్పలేదు. ఒక HTTP కనెక్షన్ ఎక్కడికి వెళిందో చెబుతుంది.

దశ 4: రెండు వైఫల్య తరగతులను వేర్వేరుగా సరిచేయండి

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

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

దశ 5: పునఃసృష్టి తర్వాత మళ్లీ పరీక్షించండి

runtime మద్దతిచ్చే యంత్రాంగం ద్వారా కాన్ఫిగరేషన్‌ను మార్చండి, తర్వాత నడుస్తున్న కంటైనర్ లోపల ఫైళ్లను సవరించడానికి బదులు కంటైనర్‌లను మళ్లీ సృష్టించండి. కొత్త ప్రైవేట్ పేరు, కొత్త పబ్లిక్ పేరు మరియు లుకప్ తర్వాత వచ్చే అప్లికేషన్ అభ్యర్థనను పరీక్షించండి. /etc/resolv.conf కంటైనర్ లోపలి సవరణ పునఃసృష్టిలో మాయమవుతుంది మరియు మరమ్మతు చేయనప్పుడు చేసినట్లు మీకు నమ్మిస్తుంది.

పంచుకున్న నెట్‌వర్క్ నిర్వచనం పక్కన రిజాల్వర్ యజమానిని మరియు ఆశించిన పేరుబయలిని నమోదు చేయండి. తదుపరి వ్యక్తికి రెండూ అవసరం.