Docker కంటైనర్ VPN వెనుక ఉన్న హోస్ట్‌లను ఎందుకు చేరుకోలేదు

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

టన్నెల్ ఎవరి నేమ్‌స్పేస్‌లో ఉందో కనుగొనండి

macOS లేదా Windows కోసం Docker Desktop‌లో కంటైనర్లు Linux వర్చువల్ మెషీన్ లోపల నడుస్తాయి. డెస్క్‌టాప్‌లో ఇన్‌స్టాల్ చేసిన VPN క్లయింట్ డెస్క్‌టాప్ ఆపరేటింగ్ సిస్టమ్‌లో టన్నెల్ సృష్టిస్తుంది, వర్చువల్ మెషీన్ దాన్ని ఎప్పటికీ చూడదు. ఏ కంటైనర్ కాన్ఫిగరేషన్ దాన్ని సరిచేయదు, ఎందుకంటే కంటైనర్‌కు అవసరమైన ఇంటర్‌ఫేస్ దాని నెట్‌వర్క్ నేమ్‌స్పేస్‌లో అసలే లేదు.

Linux హోస్ట్‌లో టన్నెల్ హోస్ట్ నేమ్‌స్పేస్‌లో నివసిస్తుంది, బ్రిడ్జ్ కంటైనర్లు సాధారణంగా బయటకు వెళ్లేటప్పుడు మూల NAT వర్తింపజేసిన హోస్ట్ రూటింగ్ పట్టిక ద్వారా దాన్ని చేరుకుంటాయి. ఆ మార్గం విఫలమైనప్పుడు, కారణం సాధారణంగా తప్పిపోయిన మార్గం కాదు, ఫార్వార్డింగ్ విధానం, రివర్స్-పాత్ ఫిల్టరింగ్ లేదా అతిపాతం చెందే సబ్‌నెట్ అవుతుంది. మరింత చదవడానికి ముందు మీరు రెండు ప్రపంచాలలో ఏది అని నిర్ధారించుకోండి:

docker info --format '{{.OperatingSystem}}'
docker run --rm --net=host alpine ip route | head -5
docker run --rm alpine ip route | head -5

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

హోస్ట్ నెట్‌వర్కింగ్ పరీక్ష, డిజైన్ కాదు

కంటైనర్‌ను హోస్ట్ నెట్‌వర్కింగ్‌తో నడపడం, దాన్ని Docker హోస్ట్ నెట్‌వర్క్ నేమ్‌స్పేస్ పంచుకోవడంగా డాక్యుమెంట్ చేస్తుంది, టన్నెల్ ఇంటర్‌ఫేస్ మరియు దాని మార్గాలను నేరుగా వారసత్వంగా పొందేలా చేస్తుంది. అదే అభ్యర్థన తర్వాత విజయవంతమైతే, మార్గ సిద్ధాంతం నిర్ధారించబడుతుంది, వైఫల్యం నేమ్‌స్పేస్ ఐసోలేషన్, ఆధారాలు, DNS లేదా యాక్సెస్ నియమం కాదు.

docker run --rm --net=host curl -sS -o /dev/null -w '%{http_code}\n' https://api.internal/health

దీన్ని నిర్ధారణగా ఉంచండి. హోస్ట్ నెట్‌వర్కింగ్ పోర్ట్ ప్రచురణ మరియు కంటైనర్ నుండి మీరు కోరిన ఐసోలేషన్‌లో ఎక్కువ భాగాన్ని వదిలివేస్తుంది, Docker Desktop‌లో «host» అంటే వర్చువల్ మెషీన్, డెస్క్‌టాప్ కాదు, కాబట్టి ఏ హోస్ట్‌ను సంబోధిస్తున్నారో మరచిపోతే అక్కడి విజయం లేదా వైఫల్యం మిమ్మల్ని తప్పుదారి పట్టించవచ్చు.

tun పరికరం మరియు దానితో వచ్చే ప్రత్యేక హక్కులు

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

sudo modprobe tun
docker run --rm -it --device /dev/net/tun --cap-add NET_ADMIN myvpn-client

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

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

బ్రిడ్జ్ NAT VPN చూసే మూలాన్ని మారుస్తుంది

డిఫాల్ట్ బ్రిడ్జ్‌తో కంటైనర్ యొక్క బయటకు వెళ్లే ట్రాఫిక్ హోస్ట్ చిరునామాకు అనువదించబడుతుంది. అందువల్ల VPN వెనుక కార్పొరేట్ వైపు కంటైనర్ చిరునామా కాకుండా హోస్ట్ టన్నెల్ చిరునామాను చూస్తుంది, మూల ఆధారిత యాక్సెస్ నియమాలు అభ్యర్థనను హోస్ట్ పంపినట్టు ప్రవర్తిస్తాయి, రెండు కంటైనర్లు VPN సర్వర్‌కు వేరు చేయలేనివి అవుతాయి.

macvlan లేదా ipvlan దానికి బదులుగా కంటైనర్‌కు LAN చిరునామా ఇస్తుంది, ఇది LAN ఆవిష్కరణకు సహాయపడుతుంది మరియు కంటైనర్ సెగ్మెంట్‌లో సమానంగా కనిపించేలా చేస్తుంది. ఇది హోస్ట్ టన్నెల్‌ను పూర్తిగా దాటవేస్తుంది, కాబట్టి అలాంటి కంటైనర్ VPN-మాత్రమే ప్రిఫిక్స్‌లను చేరుకోదు, ఆ LAN నుండి కూడా VPN అందుబాటులో లేకపోతే.

రెండు రూపాలూ చెల్లుబాటు అయ్యేవి; అవి వేర్వేరు అవసరాలకు సమాధానం ఇస్తాయి. అవసరం «ఈ కంటైనర్ VPN-మాత్రమే సేవను చేరుకోవాలి» అయితే, మీరు హోస్ట్ ద్వారా రూటింగ్ మరియు కంటైనర్ లోపల టన్నెల్‌ను ముగించడం మధ్య ఎంచుకుంటారు. ఆ ఎంపికను మోహరించే ముందు రాయండి, మొదటి విఫల అభ్యర్థన తర్వాత కాదు. మీరు ఏది ఎంచుకున్నా, దూరపు చివర చూసే మూల చిరునామాను నమోదు చేయండి, ఎందుకంటే దాని యాక్సెస్ నియమాలు మరియు దాని లాగ్‌లు అదే చూపుతాయి. ఆ చిరునామాను చెప్పలేని డిజైన్ పూర్తి కాలేదు.

DNS డీమన్‌ను అనుసరిస్తుంది, టన్నెల్‌ను కాదు

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

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

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

టికెట్ మూసివేసే ముందు చెక్‌లిస్ట్: టన్నెల్ కలిగిన నేమ్‌స్పేస్‌ను గుర్తించండి, హోస్ట్ నెట్‌వర్కింగ్‌తో మార్గాన్ని నిరూపించండి, అవసరమైన tun పరికరాన్ని మాత్రమే మ్యాప్ చేయండి, NAT తర్వాత మూల చిరునామాను గుర్తుంచుకోండి, రిజాల్వర్‌ను స్పష్టంగా సెట్ చేయండి మరియు ప్రతి కంటైనర్ నిష్క్రమణ చిరునామాలను జెండా కాదు, ఆర్కిటెక్చర్ నిర్ణయంగా పరిగణించండి.