NET_ADMIN అనేది ఒక ప్రక్రియకు నెట్వర్క్ నిర్వహణ చేయడానికి అనుమతించే లినక్స్ సామర్థ్యం, కంటైనర్లో అది ప్రక్రియ నడిచే నెట్వర్క్ పేరు స్థలం లోపలే సరిగ్గా అదే చేస్తుంది. ఇది సాకెట్ తెరవడానికి లైసెన్స్ కాదు, పరికరం లేదా మార్గానికి ప్రత్యామ్నాయం కాదు. ఆసక్తికరమైన ప్రశ్న ఎప్పుడూ సామర్థ్యం ఇవ్వబడిందా అనేది కాదు, ఏ పేరు స్థలం మార్పును పొందుతుంది అనేది.

సామర్థ్యం ఏమి కవర్ చేస్తుంది

తన పేరు స్థలం లోపల NET_ADMIN ఉన్న ప్రక్రియ ఇంటర్ఫేస్లను పైకి క్రిందకు చేయగలదు, చిరునామాలు కేటాయించగలదు, మార్గాలను జోడించగలదు తీసివేయగలదు మరియు ఫైర్వాల్ నియమాలు రాయగలదు, ఇది capabilities(7) ఈ సామర్థ్యం కింద సేకరించే కార్యకలాపాల సమూహం. కెర్నల్ ట్రాఫిక్ను ఎలా క్యూలో ఉంచి ఫిల్టర్ చేస్తుందో నియంత్రించే ఇంటర్ఫేస్ స్థాయి సెట్టింగులను కూడా ఇది సర్దుబాటు చేయగలదు. VPN క్లయింట్కు సాధారణంగా ప్రారంభంలో వీటిలో కొన్ని అవసరం, ఆ తర్వాత మరేమీ అవసరం లేదు. అందుకే చాలా ఇమేజ్లు ఉపయోగించే దానికంటే ఎక్కువ పరిధిని అడుగుతాయి.

ఆ పేరు స్థలం బయటి కార్యకలాపాలు కవర్ కావు, పక్కనున్న ప్రత్యేక హక్కులు వేర్వేరు. ముడి ప్యాకెట్లను చదవడం రాయడం NET_RAW కి చెందుతాయి, tun పరికరాన్ని సృష్టించడానికి సామర్థ్యం మరియు పరికర నోడ్కు ప్రవేశం రెండూ అవసరం. పరికరం లేని ప్రక్రియకు నెట్వర్క్ సమస్యలా కనిపించే కానీ కాని అనుమతి లోపం వస్తుంది.

పేరు స్థలం నష్టం వ్యాసార్థాన్ని నిర్ణయిస్తుంది

తన సొంత బ్రిడ్జ్ నెట్వర్క్లో ఉన్న కంటైనర్ తన loopback, తన ఇంటర్ఫేస్లు మరియు తన రూటింగ్ పట్టికను చేరుకుంటుంది. అక్కడ NET_ADMIN ఇవ్వడం VPN క్లయింట్కు హోస్ట్ రూటింగ్ నిర్ణయాలను తాకకుండా సొరంగం నిర్మించడానికి అనుమతిస్తుంది, ఇది చాలా కంటైనర్ ఇమేజ్లు ఊహించే ఏర్పాటు.

ఆ కంటైనర్ను హోస్ట్ నెట్వర్కింగ్కు మార్చండి, అదే అనుమతి ఇప్పుడు హోస్ట్ మార్గాలు మరియు హోస్ట్ ఫైర్వాల్ను సవరిస్తుంది, ఎందుకంటే వేరే పేరు స్థలం మిగలలేదు. ఒక సొరంగాన్ని నిర్వహించాల్సిన క్లయింట్ ఇప్పుడు మొత్తం యంత్రం ట్రాఫిక్ను మళ్లించగలదు, దాని తొలగింపు స్క్రిప్ట్లోని పొరపాటు హోస్ట్పై ఎవరూ రాయని నియమాలను వదిలివేస్తుంది. సామర్థ్యంలో ఏమీ మారలేదు; సందర్భం మారింది. అందుకే అదే compose ఫైల్ రెండు హోస్ట్లపై భిన్నంగా ప్రవర్తిస్తుంది.

ఒకటిగా కలిసే మూడు ముందస్తు షరతులు

VPN కంటైనర్లలో ప్రారంభ వైఫల్యాలు సాధారణంగా మూడు వేర్వేరు విషయాలలో ఒకదానికి సంబంధించినవి: సామర్థ్యం, సొరంగ పరికరం మరియు ప్రోటోకాల్కు కెర్నల్ మద్దతు. మూడింటినీ ఒకేసారి ఇవ్వడం పనిచేస్తుంది, తదుపరి వైఫల్యాన్ని ఆపాదించలేనిదిగా కూడా చేస్తుంది. కనీస compose భాగం సామర్థ్యాన్ని ఇచ్చి పరికర నోడ్ను స్పష్టంగా పంపుతుంది:

services:
  vpn:
    image: example/vpn-client:latest
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1

ఏ sysctl అవసరమో ఇమేజ్ సొంత పత్రాలలో చదవండి, ఎందుకంటే కంటైనర్లోని sysctl అదనపు ప్రత్యేక హక్కు లేదా హోస్ట్ స్థాయి సెట్టింగ్ను కోరవచ్చు. ఇమేజ్ వినియోగదారు స్థల మోడ్ను మాత్రమే మద్దతిచ్చే చోట పరికరం అసలు అవసరం లేదు, సామర్థ్యాల జాబితా దానికి అనుగుణంగా తగ్గుతుంది.

మోడ్ కాదు, సన్నని కార్యకలాపాన్ని ఇవ్వండి

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

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

రహస్యాలు వేరే నిర్ణయానికి చెందుతాయి. NET_ADMIN కలిగి ఉండటం క్లయింట్ ఏ పీర్ గుర్తింపును ప్రదర్శిస్తుంది, ఏ ఆధారాలను లోడ్ చేస్తుంది లేదా అవి ఎలా తిప్పబడతాయి అనే దానిపై ఏమీ చెప్పదు. నెట్వర్క్ నిర్వహణ విశ్వాసాన్ని అందించదు.

మార్పును ధృవీకరించి అనుమతి ఎందుకు ఉందో నమోదు చేయండి

సొరంగాన్ని డీబగ్ చేసే ముందు కంటైనర్ నిజంగా ఏమి పొందిందో నిర్ధారించండి. క్రింది తనిఖీ జోడించిన సామర్థ్యాలు మరియు నెట్వర్క్ మోడ్ను నివేదించి, తర్వాత లోపలి నుండి ఇంటర్ఫేస్ జాబితా ఎలా కనిపిస్తుందో చూపుతుంది:

docker inspect --format '{{.HostConfig.CapAdd}} {{.HostConfig.NetworkMode}} {{.HostConfig.Privileged}}' vpn
docker exec vpn sh -c 'grep CapEff /proc/self/status'
docker exec vpn ip -br addr
docker exec vpn ip route

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

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

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

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