ఒకే ల్యాప్‌టాప్‌లో, ఒక VPN క్లయింట్ కనెక్ట్ అయినప్పుడు, Linux కంటైనర్లు ఒకదానితో ఒకటి మాట్లాడుతూనే ఉంటాయి, Windows కంటైనర్లు ఆగిపోతాయి. మారే అంశం ఇమేజ్ కాదు; ప్యాకెట్లు హోస్ట్‌లోకి వెళ్లే మార్గం. డిఫాల్ట్ నెట్‌వర్క్‌లోని Windows కంటైనర్లు హోస్ట్ యొక్క రూట్ పట్టిక మరియు అనువాదాన్ని అప్పుగా తీసుకుంటాయి, కాబట్టి హోస్ట్ రూటింగ్‌ను మార్చే విధానం వాటిని కూడా మారుస్తుంది. ఏదైనా మళ్లీ ఇన్‌స్టాల్ చేయడానికి ముందు రూట్ శోధనతో దాన్ని నిర్ధారించండి.

Windows కంటైనర్ ప్యాకెట్లు హోస్ట్‌లోకి ఎక్కడ ప్రవేశిస్తాయి

డిఫాల్ట్ nat నెట్‌వర్క్‌లోని కంటైనర్ Host Networking Service ప్రిఫిక్స్ నుండి చిరునామా పొందుతుంది, సాధారణంగా 172.16.0.0/12 లోపల ఎక్కడో, మరియు వర్చువల్ అడాప్టర్ ద్వారా హోస్ట్‌ను చేరుతుంది. ఆ ప్రిఫిక్స్ రూట్ హోస్ట్ వద్ద ఉంటుంది మరియు ప్రస్తుతం యాక్టివ్‌గా ఉన్న అడాప్టర్ వైపు ట్రాఫిక్‌ను అనువదిస్తుంది. ఆ మార్గం మధ్యలో వేరే వర్చువల్ మెషిన్ లేదు.

ఈ డిజైన్ వైఫల్యాన్ని యాంత్రికంగా చేస్తుంది. కంటైనర్ ప్యాకెట్ పంపినప్పుడు, హోస్ట్ కంటైనర్ ప్రిఫిక్స్ కోసం రూట్ శోధన చేస్తుంది. ఏ రూట్ గెలిచినా ప్యాకెట్ అక్కడికే వెళుతుంది, కంటైనర్‌కు దానిపై అభిప్రాయం లేదు.

VPN క్లయింట్ ఆ మార్గంలో ఏమి మారుస్తుంది

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

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

Container modeOutbound pathTypical result behind the VPN
Windows, default natHost routes and translates container trafficContainer prefix follows the tunnel and fails
Windows, transparentContainer sits on the physical linkDepends on the local subnet being allowed
Linux engine on Docker DesktopVM egress proxied by a host processOften keeps working

Linux కంటైనర్లు ఎందుకు భిన్నంగా ప్రవర్తిస్తాయి

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

ఈ భేదమే Linux వంటకాలు బదిలీ కాకపోవడానికి కారణం కూడా. తన సొంత టన్నెల్ అవసరమైన Linux కంటైనర్‌కు TUN పరికరం మరియు NET_ADMIN సామర్థ్యం ఇవ్వబడతాయి. Windows కంటైనర్లు ఏ ఇంటర్‌ఫేస్‌ను పరికరంగా బయటపెట్టవు, కాబట్టి ఆ నమూనాకు ఆ వైపు సమానం లేదు.

రూట్‌ను నిరూపించి, ఆపై డిజైన్ ఎంచుకోండి

సాక్ష్యాలను కంటైనర్ నుండి కాదు, హోస్ట్ నుండి సేకరించండి, ఎందుకంటే శోధన చేసేది హోస్ట్:

docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"

VPN కనెక్ట్ అవ్వడానికి ముందు ఒకసారి, తర్వాత ఒకసారి రూట్ అవుట్‌పుట్‌ను అమలు చేయండి. రెండో అవుట్‌పుట్‌లో కంటైనర్ ప్రిఫిక్స్ టన్నెల్ అడాప్టర్‌ను సూచిస్తే, నిర్ధారణ పూర్తయింది, కంటైనర్లను పునఃప్రారంభించడం సహాయపడదు.

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

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

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