په VPN کې Docker کانټینر نه رسیږي؟ سبنیټونه پرتله کړئ
Docker یو سبنیټ ورکوي چې VPN هم پرې دعوه کوي. دواړه د پتې پلانونه پرتله کړئ، بیا داسې سمون غوره کړئ چې له بیا نښلېدو وروسته هم پاتې شي.
کانټینرونه د دفتر په LAN کې ځواب ورکوي، خو کله چې د شرکت VPN ونښلي، په هماغه شېبه کې ځواب ورکول بندوي. په کانټینر کې هېڅ نه دی بدل شوی: نه بیا پیلېدل، نه د انځور تازه کول، نه د ترتیباتو سمون. هغه څه چې بدل شوي، د کوربه د لارښوونې جدول دی، چېرې چې د ټانل اضافه کړې لار اوس هغه پته پوښي چې Docker ورکړې وه. مخکې له دې چې سبنیټ سم کړئ یا د VPN استثنا وغواړئ، دواړه د پتې پلانونه څنګ په څنګ کېږدئ، ځکه چې هر سمون ډېر بېل وخت نیسي.
د ترتیباتو له بدلولو مخکې لاره ولولئ
له هغه شبکه پیل کړئ چې Docker واقعاً جوړه کړې. IPAM بلاک د پتې پلان دی، او سبنیټ هغه کرښه ده چې مهمه ده:
docker network inspect project_default --format '{{json .IPAM.Config}}'
# [{"Subnet":"172.18.0.0/16","Gateway":"172.18.0.1"}]Compose په ډیفالټ ډول هر نوي پروژې ته /16 ځانګړی کوي، نو دوه خدمتونه کولای شي د 65,536 پتو په حد کې ځای شي. همدا سوروالی لامل دی چې پوښل مکرر دي: په ناڅاپي ډول ټاکل شوی /16 دومره لوی دی چې هغه سایټ وچړي چې د ټانل له لارې ورته رسېږئ، او تر هغې چې ټانل پورته نه شي، هیچا ته نه ښکاري.
بیا د یوې کانټینر پتې لپاره د لارې ټاکنه پرتله کړئ، یو ځل د ټانل د وتلو پر مهال او یو ځل د رڼا پر مهال:
ip route get 172.18.0.7
# 172.18.0.7 dev br-3f2a9c src 172.18.0.1د ځواب دوه بڼې بېلو ځایونو ته وړي. که پایله tun0، wg0 یا بل د ټانل وسیله ونوموي، VPN مختګ لږ تر لږه د پولې لارې په اندازه ځانګړی دی او بسته هېڅکله کانټینر ته نه رسیږي. که لا هم پوله ونوموي، کوربه کولای شي کانټینر ته ورسيږي، او ستاسو ستونزه فلټرول، DNS یا د بېرته راتلو لاره ده چې یوازې په یوه لوري کې ناکامېږي.
ولې د /16 ټکر اسانه پېښېږي
Docker د پولې شبکې له شخصي حوضونو څخه اخلي، او ډیفالټ حوض د 172.16.0.0/12 بلاک څخه په /16 ټوټو راځي. شرکتونه ډېری هماغه شخصي فضا کاروي، او د لرې لاسرسي VPN هغه مختګونه هر هغه کلاینټ ته ورټېل وهي چې نښلي. کله چې دواړه خواوې باور ولري چې 172.18.0.0/16 د دوی دی، په یوه لارښوونې جدول کې دوه متضادې دعوې وي.
ګټونکی د مختګ اوږدوالی ټاکي، نه د لارو ترتیب. هغه ټانل چې 10.0.0.0/8 ټېل وهی، د 172.18.0.0/16 پولې لار نه شي ماتولای، ځکه /8 لږ ځانګړی دی. هغه ټانل چې 172.18.0.0/16، یا د هغې دننه 172.18.5.0/24 ټېل وهی، ماتولای شي. له همدې کبله یو لپ ټاپ د دفتر په شبکه کار کوي او په هوټل Wi-Fi کې هماغه VPN سره ناکامېږي: کلاینټ بېل مختګونه ترلاسه کوي.
هماغه جدول بل لوري ته هم لارښوونه کوي. کانټینر چې 10.8.4.20 کې داخلي کوربه ته اړتیا لري، بسته خپلې پولې ګېټوې ته لېږي، بیا کوربه هغه ټانل ته لارښوونه کوي. هغه لار معمولاً کار کوي ځکه کوربه NAT ترسره کوي، خو ناکامېږي کله چې شرکت خوا یوازې د لپ ټاپ VPN پته ومني، یا کله چې د بېرته لارې فلټرول نیمګړی ځواب وغورځوي.
درې سمونونه پرتله کړئ
یوازې درې لارې شته، او هغوی په دې کې بېل دي چې څوک یې تصویب کړي او د یوه پلي کولو پر مهال څه ماتېږي.
| Repair | Who owns it | What it costs |
|---|---|---|
| Renumber the container network | You | Recreates the network, restarts services, invalidates literal addresses in configs and scripts |
| Exclude your range from the tunnel | Network team | Changes what every laptop sees, needs a change request and a client profile update |
| Reach the service through a published port | You and the client | One port only, no direct container-to-container routing across the tunnel |
بیا نومېنه یوازینی سمون دی چې پرته له ټکټ بشپړېدای شي، له همدې کبله ډېری لیکنې همالته درېږي. په نوي پروژه کې ارزانه ده او کله چې د لېږد وسیله یا ساتل شوې نښلېدو کرښه مستقیمې پتې ته اشاره وکړي، ګرانه کېږي. هغه حوالې مخکې له YAML سمولو وشمېرئ، نه وروسته.
کله چې پوښل په هغه حد کې وي چې ستاسو شرکت واقعاً یې خاوند دی، له ټانل څخه استثنا تر ټولو پاک ځواب دی. هغه تر ټولو ورو هم دی، او د هغه قراردادي لپاره بېګټې دی چې د کلاینټ پروفایل نه شي بدلولای. خپور شوی پورټ یا کوچنی معکوس پروکسي دا بحث ته مخه نیسي: کلاینټ له هغې پتې سره خبرې کوي چې ټانل لا دمخه سمه لارښوونه کوي، او یوازې هماغه پورټ باید د لاسرسي وړ وي.
په قصد سره یو حد وټاکئ
د یوې پروژې لپاره، په compose فایل کې سبنیټ اعلان کړئ تر څو پروژه له شریک حوض څخه اخیستل بند کړي:
networks:
default:
ipam:
config:
- subnet: 10.201.7.0/24هغه حد له هغه ثبت څخه واخلئ چې ستاسو ټیم یې ساتي، نه له هغه بېلګې چې د لټون پر مهال مو وموندله. هغه د VPN له ټېل وهل شوو مختګونو، هغه کورنیو LAN چې خلک ترې کار کوي، او په هماغه کوربه نورو کانټینر شبکو سره وګورئ. بیا بیا جوړول پلان کړئ، ځکه موجوده شبکه خپل پخوانی سبنیټ ساتي: docker compose down، بیا up -d. docker network rm تر هغې انکار کوي چې پای ټکي نښتي وي، او په فایل کې هر ipv4_address ننوتل باید په نوي حد کې وي.
د هغو شبکو لپاره چې Docker یې پخپله جوړوي، په /etc/docker/daemon.json کې ډیمون حوض وټاکئ:
{
"default-address-pools": [
{ "base": "10.201.0.0/16", "size": 24 },
{ "base": "10.202.0.0/16", "size": 24 }
]
}دا حوض هغو شبکو ته تطبیقېږي چې د ډیمون له بیا پیلېدو وروسته جوړې شي، او هغه پولې چې لا موجودې دي خپلې پتې ساتي. دا اسانه او هېرول یې اسانه دي، نو زاړه پروژه تر هغې لا پوښل شوې وګڼئ چې څوک یې شبکه بیا جوړه کړي. د Docker د انجن شبکې لاسوند د وېش مقررات بیانوي که په بیاکتنه کې حوض ته دفاع ته اړتیا ولرئ.
Linux پوله او Docker Desktop په بېل ډول ناکامېږي
په Linux کوربه کې، کانټینرونه د کوربه د نوم فضا په پولو باندې ناست دي. یو جدول هر څه ټاکي، نو پورتنی پرتله ټوله کیسه ده: د پولې لاره ولولئ، د ټانل لاره ولولئ، او وګورئ چې د یوې ریښتینې کانټینر پتې لپاره کومه ګټي.
Docker Desktop کانټینرونه د یوې VM شاته ږدي چې خپل NAT لري. کوربه کانټینر پتې ته هېڅ لار نه لري؛ خدمت ته د خپور شوي پورټ له لارې رسیږي، معمولاً 127.0.0.1 ته تړلی. نو VPN کلاینټ کولای شي خدمت پرته له کوم سبنیټ پوښل مات کړي: یا د VM داخلي حد لپاره لار کېږدي، یا د ټانل د نښلېدو پر مهال loopback ترافیک بند کړي. که په کوربه ip route get د کانټینر پتې لپاره لار نه وي، دا تمه کېدونکی دی نه بګ.
عملي پایله دا ده چې لومړی چېرته ګورئ. په Linux کې، له لارښوونې جدول پیل کړئ. په Desktop کې، له خپور شوي پورټ او د VPN کلاینټ د فایر وال مقرراتو پیل کړئ، بیا وګورئ چې د VM داخلي سبنیټ له هغه څه سره ټکر کوي چې ټانل یې ټېل وهی.
د ټانل د رڼا پر مهال تایید کړئ
مخکې له دې چې سم شو ووایاست، دوه ځله VPN بیا ونښلوئ، ځکه هغه پروفایل چې د نښلېدو پر مهال لارې ټېل وهي او د پرېکېدو پر مهال یې بېرته اخلي، د لومړي هڅې وروسته سم ښکاري. بیا هغه کتنې ترسره کړئ چې کلاینټ واقعاً یې کوي:
ip route getله کوربه څخه، د کانټینر ریښتینې پتې په کارولو سره.- له بل کانټینر څخه غوښتنه، تر څو ثابته شي چې خدمت پخپله روغ دی.
curl -sv http://127.0.0.1:8080/له کلاینټ څخه د ټانل د رڼا پر مهال، بیاtraceroute -nد LAN په ماشین څخه کانټینر پتې ته.sysctl net.ipv4.conf.all.rp_filterکه غوښتنه کوربه ته ورسیږي خو ځواب ورک شي.
په پای کې، ټاکل شوی حد په هماغه ثبت کې ولیکئ چې ترې مو ټاکلی و، له نېټې او هغه پروژې سره چې خاوند یې دی. بل پوښل به له هغې پروژې راشي چې چا نه ده لیکلې، او یوازینی دفاع دا ده چې حد په قصد سره ځانګړی شوی و، نه په ناڅاپي ډول ټاکل شوی.