కంటైనర్ ఇమేజ్లు అవసరమైన ప్రతి OpenVPN బైనరీ మరియు కాన్ఫిగరేషన్ ఫైల్ను కలిగి ఉన్నప్పటికీ మొదటి నెట్వర్క్ కాల్లో విఫలమవుతాయి. లోపం /dev/net/tun పేరు చెబుతుంది ఎందుకంటే అప్లికేషన్ కర్నెల్ను TUN ఇంటర్ఫేస్ అడిగింది మరియు కంటైనర్కు డివైస్ నోడ్ లేదా దాన్ని సృష్టించే సామర్థ్యం లేదు. ఇవి రెండు వేర్వేరు అనుమతులు, ఒకటి సరిచేస్తే మరొకటి ఉన్న చోటే ఉంటుంది.

వాటిని వేరు చేయడానికి ప్రతి దానికి ఒక ఆదేశం కావాలి. ఆ తర్వాతి లోపం సందేశం మీరు నిజంగా ఏ సరిహద్దులో నిలబడ్డారో చెబుతుంది.

డివైస్ నోడ్ మరియు సామర్థ్యం రెండు తలుపులు

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

Docker యొక్క devices సెట్టింగ్ హోస్ట్ డివైస్ను కంటైనర్లోకి మ్యాప్ చేస్తుంది, అయితే cap_add సామర్థ్యాల సెట్ను సర్దుబాటు చేస్తుంది. అదే మార్గం యొక్క bind mount డివైస్ యాక్సెస్ అర్థాన్ని వర్తింపజేయకుండా ఫైల్ను దృశ్యంలో ఉంచుతుంది.

దీన్ని Compose ఫైల్ వెలుపల పునరుత్పత్తి చేయండి

సేవను సవరించే ముందు హోస్ట్కు డివైస్ ఉందో మరియు బేర్ కంటైనర్ ఇంటర్ఫేస్ సృష్టించగలదో తనిఖీ చేయండి. క్రింది ఆదేశం ఉద్దేశపూర్వకంగా కనిష్ఠం, దాని ఏకైక లక్ష్యం హోస్ట్ సమస్యను compose సమస్య నుండి వేరు చేయడం. అది విఫలమైతే ఏ compose మార్పు సహాయపడదు.

ls -l /dev/net/tun
docker run --rm --cap-add NET_ADMIN --device /dev/net/tun:/dev/net/tun alpine sh -c 'apk add -q iproute2 && ip tuntap add dev tun9 mode tun && ip link show tun9'

హోస్ట్లో నోడ్ లేకపోవడం అంటే tun మాడ్యూల్ అందుబాటులో లేదు, ఇది కంటైనర్ కాదు హోస్ట్ వైపు సరిచేయడం. నోడ్ ఉన్నా కంటైనర్ లోపల తెరవలేకపోతే అది డివైస్ యాక్సెస్ను సూచిస్తుంది, సందేశం no such file కాకుండా permission denied అని చెబుతుంది. ఈ రెండు వైఫల్యాల క్రమమే మొత్తం నిర్ధారణ. ఏదైనా ఫ్లాగ్ మార్చే ముందు ఏది చూశారో రాయండి.

TUN తర్వాతి లోపాలు వేర్వేరు సమస్యలు

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

పని చేస్తున్న ఉదాహరణ నుండి ప్రతి సెట్టింగ్ను కాపీ చేయడమే కనిష్ఠ పరిష్కారం చదవలేని సేవా నిర్వచనంగా మారే మార్గం. ఈ డిప్లాయ్మెంట్కు అవసరమైనవి మాత్రమే తీసుకురండి మరియు ప్రతి ఒక్కటి ఎందుకు ఉందో రాయండి.

కంటైనర్ లోపల ఇంటర్ఫేస్ను ధృవీకరించండి

ఇంటర్ఫేస్ మరియు సామర్థ్యాల సెట్ను తనిఖీ చేయండి హోస్ట్ నుండి కాదు, నడుస్తున్న కంటైనర్ లోపలి నుండి. క్రింది ఆదేశాలు డివైస్ నోడ్, సామర్థ్యాల జాబితా మరియు ఇంటర్ఫేస్ అసలు సృష్టించగలమా అని చూపిస్తాయి. క్లయింట్ నడిపే అదే కంటైనర్లో వాటిని నడపండి, ఇమేజ్ కనిష్ఠమైతే సాధనాలను ఇన్స్టాల్ చేయండి.

ls -l /dev/net/tun
capsh --print | grep -i net_admin
ip link add dev tun9 type tun && ip link show tun9

bounding set లో ఉన్నా effective set లో లేని సామర్థ్యం ఎప్పుడూ ఇవ్వని సామర్థ్యం కంటే భిన్నంగా ప్రవర్తిస్తుంది, capsh రెండింటినీ చూపిస్తుంది. నోడ్ ఉన్నా సామర్థ్యం ఉన్నా సృష్టి ఇంకా విఫలమైతే, రన్టైమ్ ఆపరేషన్ను పరిమితం చేసే seccomp ప్రొఫైల్ లేదా AppArmor విధానం వంటి మరొకదాన్ని అమలు చేస్తోంది. అది అప్లికేషన్ కాదు, రన్టైమ్ డాక్యుమెంట్ చేసే మూడవ సరిహద్దు.

కంటైనర్ ఫ్లాగ్లు, ఇమేజ్ మరియు ప్రతి ప్రయత్నం యొక్క ఖచ్చితమైన లోపాన్ని రాయండి. ఆ గమనికను తర్వాత చదివే వ్యక్తి మొత్తం దర్యాప్తును పునరావృతం చేయకుండా ఏ తలుపు మూసి ఉందో చెప్పగలడు.

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