د Docker کانټینرونو ترافیک د کوربه VPN له لارې تېږي: څنګه یې وګورو
د کوربه VPN یوازې د کوربه شبکې نوم ځای پوښي. دا ګوتې وهل ښیي چې د پل کانټینرونو ترافیک تونل ته ننوځي که مستقیم وځي.
ستاسو براوزر په کوربه کې د VPN د وتلو پته ښیي، کانټینر ستاسو کورنی اړیکه راپور کوي، او یو څوک هغه ته تلون وایي. هېڅ نه دی تللی. د کوربه تونل د انټرفېسونو، لارو او قاعدو یوه ټولګه ده چې د کوربه شبکې نوم ځای پورې اړه لري، او پر پل کانټینر بل نوم ځای دی چې خپله اصلي لاره لري. زه پر یوه Compose سټک کې ناست وم چې VPN کلاینټ هلته اونۍ تړلی و او یو هم کانټینر پاکټ هېڅکله نه و ننوتلی.
د ټرې آیکون دمخه نوم ځای وګورئ
نوم ځایونه ټوله دلیل دی. کله چې Docker پر پل شبکه کانټینر پیل کړي، شبکه نوم ځای جوړوي، د veth جوړې یوه پای د هغې دننه نښلوي، او هغه نوم ځای ته پته او اصلي لاره ورکوي. د تونل انټرفېس، هر څه چې نومېږي، د کوربه نوم ځای کې اوسیږي. د کانټینر دننه ترافیک هغه نه شي لیدلی، او له باندې هېڅ کلاینټ تنظیم هغه نه بدلوي.
له جلا کېدو بهر تلو دوې ملاتړ شوې لارې شته. --network host کانټینر د کوربه نوم ځای دننه ځای پرځای کوي، نو هغه د کوربه لارې او په دې توګه تونل میراث اخلي. --network container:vpn د بل کانټینر نوم ځای شریکوي، او ډېری sidecar ډیزاینونه کاري بار په همدې توګه د VPN کانټینر له لارې لېږي. دواړه څرګندې چوپړې دي؛ معمولاً یوازې یوه یې هغه څه ده چې ځای پرځای کوونکي ته په زړه کې وه.
د کوربه حالت وړیا لوړوالی نه دی. کانټینر خپله پته لرل بندوي، د پورټ خپرول نه پلي کېږي، او هلته NET_ADMIN لرونکی بهیر کولای شي د کوربه لارښوونه بیا ولیکي. د هغې منل سمه پرېکړه کېدای شي. دا چې لا دمخه فعال دی یې فرض کول هغه لاره ده چې خلک ماښام د هغه تونل په سمولو تېروي چې هېڅکله په لار کې نه و.
پاکټ له پله بهر تعقیب کړئ
د پل کانټینر خپل پاکټ خپل اصلي ګېټوې ته لېږي، چې په کوربه کې د پل انټرفېس دی. بیا کوربه پاکټ لېږدوي او په اصلي ترتیب کې د پاکټ له وتلو دمخه سرچینه پته خپلې پتې ته ژباړي. همدا د ژباړې ګام دی چې تګلاره په خاموشۍ ماتوي.
کله چې پاکټ د تونل پای ټکي ته ورسیږي، د کوربه پته لېږدوي. هر هغه قاعده، تګلاره لار یا د وېشل شوي تونل پرېکړه چې د کانټینر پر اصلي پته ولاړه وي، سمون بندوي، او هغه دوه کانټینرونه چې باید له جلا جلا وتلو څخه ووځي یوازې د سرچینې له مخې نه شي جلا کېدای. که تاسو ته د هر کانټینر لپاره لارښوونه غواړئ، پرېکړه باید د ژباړې دمخه یا د هغه نوم ځای دننه وشي چې تاسو یې کنټرولوئ.
Docker دا قاعدې پخپله ساتي، د کوم فایر وال بیکنډ له مخې چې ډیمون تنظیم شوی و. د لېږدول شوي ترافیک لپاره د ملاتړ شوي هنګله بهر په لاس لیکل شوې قاعدې، DOCKER-USER، کولای شي بیا ترتیب یا لرې شي کله چې ډیمون بیا پیل شي یا کوربه لوړ شي. د Docker د پاکټ فلټر کولو اسناد د زنځیرونو ترتیب ښیي؛ عملي ټکی دا دی چې هره قاعده یو مالک او یوه د بیا پورته کولو لاره غواړي چې تاسو ریښتیا ازمویلې وي.
دواړه سیستمونه جلا جلا وآزمویئ
له یوه نوم ځای څخه شاهدۍ د بل په اړه هېڅ نه وایي. په VPN کانټینر کې چلول شوې غوښتنه ثابتوي چې تونل د هغه کانټینر لپاره کار کوي. دا د کوربه په اړه شاهدۍ نه ده، او هماغه حکم چې له --network host کانټینر څخه چلول شوی وي د پل په اړه شاهدۍ نه ده.
# host namespace
ip route get 1.1.1.1
ip -brief addr show
# a fresh container on the same bridge network
docker run --rm --network appnet alpine sh -c 'ip route; cat /etc/resolv.conf; ip -6 route'بیا ازموینه د ورته عکس پر ځای د اصلي اپلیکیشن کانټینر دننه تکرار کړئ. اپلیکیشن کېدای شي اضافه لاره، د پروکسي چاپېریال بدلون یا بل حل کوونکی ولري، او هر یو له دې څخه ځواب بدلوي. هر ځل د نومونو حل او دوهمه پته کورنۍ وګورئ: د کاروونکي ټاکل شوو پلونو کانټینرونه د Docker د داخلي حل کوونکي له لارې په 127.0.0.11 کې حل کېږي، او پر پل IPv6 اصلي لاره کولای شي ترافیک بهر بوځي پداسې حال کې چې تاسو یوازې IPv4 تونل ازموئ.
د اعتبار اسنادو له لمس کولو دمخه نمونه ولولئ
کله چې کوربه کار وکړ او کانټینر ونه کړ، لامل نژدې تل جوړښتي وي، او د کیلیو څرخول یا کلاینټ بیا نصبول یوه ماسپښین ضایع کوي. لومړی نښه ترتیب کړئ او سمون معمولاً خپل نوم پخپله اخلي.
| What you see | Usual cause | First check |
|---|---|---|
| Host exits through the VPN, container shows the ISP address | The container never entered the tunnel | Default route inside the container |
| Container works until the daemon restarts, then stops | Rules outside the supported hook, or a changed backend | Daemon's reported firewall backend and DOCKER-USER |
| Container loses internal hosts after the tunnel comes up | VPN prefix overlaps the Docker bridge subnet | ip route on the host, then docker network inspect |
| Small replies arrive, large ones hang | Tunnel MTU or missing MSS clamping | Link MTU on both ends of the tunnel |
| Container falls back to the ISP address when the tunnel drops | Nothing enforces the kill switch for forwarded traffic | Stop the tunnel with a request in flight |
د یو بل پوښلو کرښه خپله جمله مستحق ده. هغه VPN پروفایل چې د 172.17.0.0/16 لپاره، یا د هغه 10.0.0.0/8 لپاره چې ستاسو د پل مخکښه برخه پکې په ناڅاپي ډول وي، لاره ټېله کوي، تونل اړباسي چې د کانټینر فرعي شبکه ادعا کړي، او ژباړل شوو پتو ته تلونکي ځوابونه به غلط لوري ته لاړ شي یا ورک شي. د Docker شبکه بیا شمېرل معمولاً له استثناوو راټولولو څخه پاک وي.
پوښښ څرګند کړئ، بیا یې په قصد مات کړئ
دوه ډیزاینونه په بیاکتنه کې ټینګ پاتې کېږي. د VPN کانټینر نوم ځای شریک کړئ او هر پوښل شوی کاري بار یو تونل د یوې بیا پیل پولې سره کاروي، کوم چې ساده دی تر هغه چې یوه خدمت بل وتل یا خپله DNS لاره غواړي. یا د کانټینرونو شبکه د کوربه پر VPN ګېټوې ته واړوئ: لېږدول فعال، د پل مخکښه برخه تونل ته، د بېرته راتلونکي ترافیک څرګند سمبالښت. دا د هرې شبکې لپاره کنټرول اخلي او تاسو ته د قاعدو یوه ټولګه ستاسو په غاړه ورټیټوي چې د ډیمون او کلاینټ لوړولو په اوږدو کې یې ساتئ.
هر څنګه وي، هغه ازموینه چې ارزښت لري د ناکامۍ حالت دی. تونل ودروئ پداسې حال کې چې د کانټینر غوښتنه په الوتنه کې ده او وګورئ پاکټ چېرته ځي. که بیرته مستقیمې لارې ته ورلوېږي، پوښښ هېڅکله نه و پلي شوی، ځکه د کلاینټ kill switch د کلاینټ خپل ترافیک اداره کوي نه له پله لېږدول شوي پاکټونه. بیا ډیمون او کوربه بیا پیل کړئ او پایله دوهم ځل تایید کړئ؛ هغه شیبه چې په لاس لیکل شوې قاعدې ورکېږي هماغه ده.
د دې د بشپړېدو له ویلو دمخه څلور شیان تایید کړئ: د تونل انټرفېس د ترافیک سره په یوه نوم ځای کې دی، د کانټینر ازموینه په اصلي کانټینر کې وشوه، د نومونو حل او دواړه پته کورنۍ وګورل شوې، او د تونل د ناکامۍ ازموینه لا هم بند ډول ناکامېږي. بیا د فایر وال بیکنډ، کلاینټ نسخه او د هرې قاعدې مالک ولیکئ. هماغه ریکارډ د راتلونکي لوړولو مخه نیسي چې د زړو انګېرنو نااسناد شوې ګډه پاتې نه کړي.