د OpenVPN تر شا د Docker او VM ټرافیک: لاره که بیا شمېرنه؟

د OpenVPN کلاینټ چلولو کوربه کې کانټینرونه او مېلمانه یا د بېرته راستنېدو لاره له لاسه ورکوي یا د تونل مخکښ سره ټکر کېږي. درې پوښتنې حل غوره کوي.

کوربه د تونل له لارې براوز کوي او څنګ ته کانټینر هېڅ ته نه رسېږي. له کانټینر څخه پورټ خپرول چې خپل VPN کلاینټ چلوي لا خراب دي: غوښتنه رسېږي او ځواب هېڅکله نه وځي. دواړه په کوربه باندې د لارښوونې پرېکړې دي، او Docker یوازې قاصد دی.

درې پوښتنې معلوموي چې له دې دوو کوم حالت ته ګورئ، او شاوخوا یوه دقیقه وخت نیسي.

دوه خرابۍ چې یو شان ښکاري

لومړی د بېرته راستنېدو لارې ستونزه ده. خپرېدونکی پورټ کانټینر ته ژباړل کېږي، غوښتنه رسېږي، او ځواب د کوربه د ډیفالټ لارې له مخې لېږل کېږي، کومه چې OpenVPN کلاینټ tun0 ته اړولې ده. ځواب له داسې پتې وځي چې لرې ملګری یې تمه نه لري، او وغورځول شي. دویم د مخکښ ټکر دی: د Docker ډیفالټ پل 172.17.0.0/16 لري او شرکت تونل هماغه ساحه ټېل وهي.

یو د لارښوونې جدول سره سمېږي، بل د پل بیا شمېرلو سره. له دې مخکې سمون چې پوه شئ کوم کوم دی، هماغه د کار کوونکي کانټینر د ماتولو لار ده.

په درې پوښتنو پرېکړه وکړئ

لومړې پوښتنه: ایا VPN بندولو سره خرابي ورکه کېږي؟ که د تونل بندېدو پر مهال هر څه کار کوي، د بېرته راستنېدو لارې ته شک وکړئ. دویمه پوښتنه: ایا ip route show table all هماغه مخکښ دوه ځله لیست کوي، یو ځل پر پل او یو ځل پر tun0؟ هماغه ټکر دی. درېیمه پوښتنه: اغېزمنه پته کانټینر ده، NAT مېلمه ده که پل شوې مېلمه؟

درېیمه پوښتنه مهمه ده ځکه هر یو لپاره بېله سمه حل لاره شته، او د کانټینر حل پر libvirt مېلمه پلي کول یوه ماښام ضایع کوي.

ip route
ip route show table all | grep -E '172\.1[7-9]|10\.8'
docker network inspect bridge --format '{{.IPAM.Config}}'

بېرته راستنېدو لاره: د یوې سرچینې پتې لپاره جدول

کله چې د کانټینر ټرافیک باید د فزیکي انټرفېس له لارې ووځي، پداسې حال کې چې کوربه پخپله تونل کاروي، پر سرچینې ولاړه لارښوونه تر ټولو کوچنی بدلون دی. یوه قاعده چې د کانټینر پتې سره سمون لري اضافه کړئ او هغه ځانګړي جدول ته ولېږئ. پر کوربه بل څه نه خوځېږي.

ip rule add from 172.22.0.3 lookup 10
ip route add default via 172.22.0.1 table 10

هر هغه بستې چې سرچینه یې هماغه پته ده، لومړی جدول 10 ګوري، او جدول 10 هغه د تونل پرځای د پل ګېټوې ته لېږي.

په دې سره تایید کړئ: ip route get 1.1.1.1 from 172.22.0.3. ځواب باید د پل انټرفېس ونوموي، نه tun0. په دې توګه اضافه شوې قاعدې په بیا پیل کې ورکېږي، نو هغه په هغه unit یا شبکې کنډک کې کېږدئ چې کانټینر لري.

هماغه بڼه د WireGuard کانټینر لپاره هم کار کوي، چېرې چې د ځواب لارې ته هم روښانه قاعده پکار ده.

د مخکښ ټکر: پل بیا شمېر کړئ

د لارښوونې جدول یو مخکښ یوې ځای ته لېږي. که VPN 172.17.0.0/16 ټېل وهي او د Docker پل لا دمخه هلته وي، لږ مېټریک ګټي: Docker خپله نښلول شوې لاره په مېټریک 0 کې ږدي، او ټېل وهل شوې لاره په 50 کې رارسي. بیا Docker د کار کولو پر مهال تونل مات ښکاري، یا برعکس، د نصب کولو ترتیب له مخې. د مېټریک سره جګړې پرځای پل بیا شمېر کړئ.

{
  "bip": "10.200.0.1/24",
  "default-address-pools": [{"base": "10.201.0.0/16", "size": 24}]
}

له بدلون وروسته Docker بیا پیل کړئ او هغه شبکې بیا جوړې کړئ چې زوړ حوض سره جوړې شوې وې. د مېټریک بدلول یوازې شخړه بل بوت ته ښکاره کوي.

VMونه بیا بل ځواب ته اړ دي

د ډیفالټ NAT شبکې libvirt مېلمه د کوربه لارښوونه په میراث اخلي او د کوربه تونل د ډیفالټ لارې مالک کېدو سره سم بهر ته رسېدل بندوي. مېلمه پل یا macvtap وسیلې ته اړول هغه ته په فزیکي شبکه کې خپله لار ورکوي. په virt-manager کې هارډویر اضافه کړئ، Network غوره کړئ، سرچینه macvtap کوربه وسیلې ته وټاکئ، virtio د ماډل په توګه وساتئ، بیا زوړ NAT انټرفېس غیر فعال کړئ.

macvtap مېلمه معمولاً خپل کوربه ته نه شي رسېدلی. دا د خطا نه، متوقع چلند دی، او باید په هغه یادښت کې وي چې تاسو یې پرېږدئ.

د هغې مېلمې لپاره چې یوازې د کوربه LAN ته اړتیا لري، د پلورونکي کلاینټ کې کېدای شي ورکه سویچ وي: له Mullvad سره mullvad lan set allow پرته له libvirt ته لاس وهلو محلي لاسرسی بېرته راولي. او کله چې کانټینر باید یوازې د تونل له لارې لاسرسی ولري، خپرېدونکی پورټ د تونل پتې سره وتړئ، -p 10.8.0.5:8080:8080، هرې پتې ته د خپرولو پرځای.

اړوندې مقالې