ప్రైవేట్ API మీ డెస్క్టాప్ బ్రౌజర్లో తెరుచుకుంటుంది మరియు డెవలప్మెంట్ కంటైనర్లో విఫలమవుతుంది. ఇది వైరుధ్యం కాదు, మరియు ఇది అరుదుగా VPNయే. బ్రౌజర్ అభ్యర్థన మరియు విఫలమైన అభ్యర్థన వేర్వేరు ప్రక్రియల ద్వారా, వేర్వేరు రిజాల్వర్లు, ప్రాక్సీలు మరియు రూట్లతో, తరచుగా పూర్తిగా వేర్వేరు నెట్వర్క్ పేరు స్థలాల నుండి జరిగాయి. "నా ల్యాప్టాప్లో" అనేది Windows హోస్ట్, WSL పంపిణీ, Docker Desktop వర్చువల్ మెషీన్ మరియు ఆ VM లోపల ఒక కంటైనర్ అనే నాలుగు సందర్భాలను సూచించవచ్చు; ఇవి ఒకే హోస్ట్నామ్కు వేర్వేరుగా సమాధానం ఇవ్వగలవు. ఒక సెట్టింగ్ను కూడా తాకే ముందు విఫలమవుతున్న ప్రక్రియ ఏది ఉపయోగిస్తుందో కనుగొనండి.

సెట్టింగ్ మార్చే ముందు ప్రక్రియను గుర్తించండి

VPN క్లయింట్ కాకుండా కంటైనర్ ఇంజిన్తో ప్రారంభించండి. కమాండ్ లైన్ ఏ సందర్భంతో మాట్లాడుతోంది, ఆ ఇంజిన్ ఏ ఆపరేటింగ్ సిస్టమ్పై నడుస్తుంది అని అడగండి, ఎందుకంటే డెస్క్టాప్ VM నిర్వహించే Linux కంటైనర్ స్థానిక డెమన్ నిర్వహించే దాని నుండి వేరే మార్గం:

docker context ls
docker info --format '{{.OperatingSystem}} / {{.Name}}'
docker run --rm alpine ip route

Windowsలో, wsl -l -v పంపిణీ WSL 2 కింద నడుస్తుందో లేదో చెబుతుంది, ఇది దానిని దాని స్వంత వర్చువల్ స్విచ్ వెనుక ఉంచుతుంది. కంటైనర్ హోస్ట్ యొక్క రూటింగ్ పట్టికను పంచుకుంటుందో లేదా హోస్ట్ను చేరుకోవడానికి ఫార్వార్డ్ చేసిన పోర్ట్ లేదా హోస్ట్ పేరు అవసరమయ్యే NAT వెనుక ఉందో ఆ వివరం నిర్ణయిస్తుంది.

ఒక అభ్యర్థనను స్థిరంగా ఉంచి పోల్చండి

ప్రైవేట్ హోస్ట్లో ఒక హానిచేయని ఎండ్పాయింట్ను ఎంచుకోండి మరియు ప్రతి పోలికకు దానిని ఉపయోగించండి: బ్రౌజర్ నుండి, హోస్ట్ టెర్మినల్ నుండి, WSL పంపిణీ నుండి మరియు కంటైనర్ లోపల నుండి. ప్రతి ప్రయత్నానికి నాలుగు విషయాలు నమోదు చేయండి: పరిష్కరించబడిన చిరునామా, ప్రాక్సీ ఉపయోగించబడిందో లేదో, వైఫల్య తరగతి మరియు గడిచిన సమయం. పేరు శోధన, కనెక్షన్ ఏర్పాటు, TLS ధృవీకరణ మరియు HTTP స్థితి నాలుగు వేర్వేరు సమస్యలు, వాటిని "ఇది పనిచేయదు" అని కలపడం ఒక ఉదయాన్ని వృథా చేస్తుంది.

విఫలమవుతున్న కంటైనర్ లోపలే పోలికను నడపండి, ఒక సమయ పరిమితితో, నిశ్శబ్ద ఫైర్వాల్ టెర్మినల్ను నిమిషాలు పట్టుకోకుండా. కొత్త కంటైనర్ ఇంజిన్ నెట్వర్క్ సందర్భాన్ని పునరుత్పత్తి చేస్తుంది కానీ అప్లికేషన్ కంటైనర్ పేరు స్థలం, ప్రాక్సీ వేరియబుల్స్ లేదా రిజాల్వర్ను కాదు, కాబట్టి నిజమైన దానిలోకి docker exec చేయడమే అధికారిక పరీక్ష మరియు పక్క కంటైనర్ అనేది తేడా ఇంజిన్లోనా కంటైనర్లోనా అని వేరుచేయడానికి ఒక మార్గం మాత్రమే:

docker exec -it app /bin/sh -c "getent hosts api.internal; curl -v --max-time 8 https://api.internal/ 2>&1 | tail -20"
docker run --rm --network container:app curlimages/curl:latest -sv --max-time 8 https://api.internal/ 2>&1 | tail -20

alpine బేస్ ఇమేజ్ busybox కలిగి ఉంటుంది మరియు curl లేదు, కాపీ చేసిన డయాగ్నస్టిక్ బ్లాక్ విఫలమవడానికి సరిగ్గా ఇలాంటి వివరమే కారణం: క్లయింట్ ఉన్న ఇమేజ్ను ఎంచుకోండి లేదా అదే రన్లో చేర్చండి. సంబంధం లేని పబ్లిక్ సైట్లతో పోలిక ఏదీ వేరుచేయదు. కంటైనర్ నుండి https://example.com పనిచేస్తే, కంటైనర్కు ఇంటర్నెట్ యాక్సెస్ ఉందని మాత్రమే తెలుసుకున్నారు, టన్నెల్ ద్వారా ప్రైవేట్ చిరునామాను చేరుకోగలదా అనే దాని గురించి ఏమీ లేదు. అలాగే, కొత్త టెర్మినల్ తెరవడం కొత్త టెర్మినల్ పనిచేస్తుందని మాత్రమే నిరూపిస్తుంది, విఫలమైన అప్లికేషన్తో అది ఒక రన్టైమ్ను పంచుకుంటుందని కాదు.

Docker Desktop VPNతో పనిచేయగలదు

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

ఇప్పటికీ ముఖ్యమైనది ఉపయోగంలో ఉన్న backend, క్లయింట్ యొక్క విభజిత-టన్నెల్ విధానం మరియు VM పొందిన రిజాల్వర్ కాన్ఫిగరేషన్. రూట్లను ఇన్స్టాల్ చేసి DNS ఇన్స్టాల్ చేయని, లేదా VM చేరుకోలేని DNS సర్వర్ను పంపే VPN క్లయింట్, హోస్ట్ పనిచేస్తుండగా కంటైనర్ లోపల పేరు శోధన వైఫల్యంను ఉత్పత్తి చేస్తుంది, ఎందుకంటే హోస్ట్కు అదనపు రిజాల్వర్ లేదా కాష్ చేసిన సమాధానం ఉంటుంది. ఇది కంటైనర్ వేషధారణలో ఉన్న రిజాల్వర్ సమస్య. మీరు ప్రయత్నించే ప్రతి VPN పునఃకనెక్షన్ను ఇది తట్టుకుంటుంది, ఎందుకంటే టన్నెల్ ఇప్పటికే మీరు అడిగిన ట్రాఫిక్ను మోస్తోంది.

చిరునామా అతివ్యాప్తులు మరియు MTU వేర్వేరు వైఫల్యాలు

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

docker network inspect bridge --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}'
ip route get 10.20.30.40

రెండవది MTU సమస్య. కనెక్షన్ ఏర్పడి TLS పూర్తయినా పెద్ద ప్రతిస్పందనలు నిలిచిపోతే, అది అనుమతి సమస్య కాదు, ప్యాకెట్ పరిమాణ సమస్య, DNS రికార్డులను మార్చడం దానిని ఎప్పటికీ సరిచేయదు. ఏదైనా మార్చే ముందు చిన్న అభ్యర్థన మరియు పెద్ద అభ్యర్థనతో పరీక్షించి రెండు ఫలితాలను నమోదు చేయండి.

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

ప్రాక్సీ కాన్ఫిగరేషన్ మెషీన్కు కాదు, ప్రక్రియకు

కంటైనర్ లోపల, localhost ఆ కంటైనర్ యొక్క స్వంత నెట్వర్క్ సందర్భాన్ని సూచిస్తుంది, కాబట్టి హోస్ట్పై నడుస్తున్న ప్రాక్సీ ఆ పేరుతో అక్కడ చేరుకోలేము. Docker Desktop హోస్ట్ యాక్సెస్ కోసం host.docker.internal అందిస్తుంది, Linuxలో మీరు దానిని --add-host=host.docker.internal:host-gatewayతో స్పష్టంగా జోడిస్తారు. ఏ విధంగా అయినా, ఆ పేరు హోస్ట్కు ఒక మార్గాన్ని ఇస్తుంది; అది ప్రాక్సీ సేవను సృష్టించదు, దానిని ఉపయోగించడానికి మీకు అధికారం ఇవ్వదు.

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

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

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