کانټینر د VPN-یوازې API ته نه رسیږي؟ پر کوربه یې پراکسي کړئ

ستاسو د Compose خدمت د هغه API پر وړاندې وخت تیروي چې په همدې ماشین کې براوزر پرته له کوم شکایت خلاصوي. همدا توپیر نښه ده: هغه غوښتنه چې کار کوي له کوربه څخه چې VPN تونل لري وځي، او هغه چې ځوړند پاتې کیږي له کانټینر څخه چې خپل شبکه یی سټک لري وځي. د کانټینر په داخل کې هیڅ شی د تونل لارې نه پېژني، نو خصوصي منزل هر ډول چې نوم ولیکل شي نه رسېدونکی پاتې کیږي. حل د کوربه له لارې یو قصدي ټوپ دی، نه ډېره هوښیاره د لارې جدول.

له دې سره پیل وکړئ چې دوه لارې ولې توپیر لري، بیا پرېکړه وکړئ چې تونل باید چېرته اوسي.

ولې کوربه کار کوي او کانټینر نه

تونل پورته کول کوربه ته یو انټرفیس، یوه ټولګه لارې او معمولاً د VPN لخوا ورکړل شوې د حل کوونکي ننوتنه ورکوي. کانټینر له دې څخه هیڅ نه میراث اخلي: دا د انجن په پول کې په یو انټرفیس او هغه پل ته اشاره کوونکې اصلي لارې سره پیل کیږي. پر کوربه نصب شوې لارې د هغې نوم تشې دننه چلېدونکي هر شي لپاره ناښکاره دي.

له همدې کبله نښې یوازې خرابې نه، بلکې ناسمې ښکاري. کوربه خصوصي نوم حل کوي او نښلوي، ځکه چې هلته هم نوم او هم لاره شته. کانټینر خپله بسته داسې خصوصي پتې ته لیږي چې د پل په لاره هیڅ شی نه شي رسېدلی، او غوښتنه وخت تیروي. د کانټینر hosts فایل ته نوم ورزیاتول هیڅ نه بدلوي، ځکه چې پته پخپله له هغه ځایه چې کانټینر ناست دی نه رسېدونکې ده.

له کانټینر دننه کوربه ته ورسیږئ

د کانټینر دننه پروسه چې localhost ډایل کوي، کانټینر ډایل کوي. Docker Desktop host.docker.internal د داسې نوم په توګه خپروي چې بېرته هغه ماشین ته اشاره کوي چې انجن چلوي؛ Linux انجنونه یې تر هغه پورې ناټاکلی پرېږدي چې خدمت یې وغواړي، او لاندې نقشه همدا کوي. په دې سره اپلیکیشن د خصوصي پتې پرځای نوم او پورټ هدف ګرځوي.

services:
  app:
    extra_hosts:
      - "host.docker.internal:host-gateway"
    environment:
      INTERNAL_API_HOST: "host.docker.internal:8666"

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

وټاکئ چې تونل چېرته اوسیږي

د خصوصي API اړتیا لرونکي Compose خدمت لپاره درې بڼې ممکنې دي، او د دې له مخې توپیر لري چې کومه پروسه تونل لري. VPN کلاینټ کولای شي د کانټینر انځور دننه چل شي، چې د تونل وسیلې څرګندول او د هغې سره راتلونکې د شبکې اداره کولو وړتیا ورکول غواړي. اپلیکیشن کولای شي د جلا تونل کانټینر شبکه یی نوم تشه شریکه کړي، نو دواړه پروسې یو سټک او یو د لارې جدول ویني. یا تونل کولای شي پر کوربه پاتې شي، له کوربه څخه کانټینر ته په یو تنګ لېږدوونکي سره.

لومړنۍ دواړه د پروفایل فایلونه، د بیا نښلولو چلند او د حل کوونکي تګلاره پروژې ته راکاږي، او په فایل کې هر خدمت د تونل د روغتیا پورې تړلی کوي. دا د یوې API غوښتنې لپاره ډېر ګډوالی دی. د یوې داخلي پای ټکي لوستونکي پراختیایي سټک لپاره، د کوربه خوا لېږدوونکی تر ټولو کوچنی بدلون دی چې لا هم اعتبارنامې هغه ځای کې ساتي چې د پلیټفارم ټیم یې اداره کوي.

پر کوربه یوه تنګه لاره خپره کړئ

له هغه څخه پیل وکړئ چې لېږدوونکی یې میراث اخلي: د هغه حساب لاندې یې چل کړئ چې تونل لري، نو د هغې وتلې ساکټونه به د کوربه لارې او د کوربه حل کوونکی واخلي. د nginx یوه location بلاک یوه لاره پوښي.

server {
    listen 8666;
    location /search/ {
        proxy_pass http://10.20.30.40:8090/;
        proxy_set_header Host internal-api.example;
        proxy_read_timeout 60s;
    }
}

پته او پورټ د بدلونکو په توګه وګڼئ او هغه جوړه کېږدئ چې API واقعاً پرې اورېدل کوي. هر اضافي upstream خپل location بلاک مستحق دی، او هر بلاک باید یوازې هغه لارې ومني چې دا خدمت یې بولي، ترڅو پراکسي خصوصي شبکې ته عمومي دروازه نه شي. اورېدونکی د host-gateway له لارې راتلونکو کلاینټونو لپاره د پل پتې سره، یوازې هغه وخت چې کلاینټ د کوربه شبکه یی نوم تشه شریکه کړي د loopback سره، او هېڅکله د 0.0.0.0 سره مه نښلوئ. هغه پورټ هم وټاکئ چې لا ازاد دی: مخکې نیول شوی شمېر پراکسي بې اورېدلې پرېږدي او کانټینر وخت تیرولو ته دوام ورکوي، چې د هغې شبکې خرابۍ څخه چې تاسو پیل کړې وه نه شي توپیر کېدلی.

پورټونه، نومونه او د TLS پرېکړه

د نومونو حل د لارښوونې په څېر ویشل کیږي. د کانټینر عامه پلټنې د انجن د حل کوونکي له لارې ځي، نو هغه خصوصي نوم چې پر کوربه حل شي د کانټینر په داخل کې به نه حل شي. پراکسي هغه برخه ده چې خصوصي نوم حل کوي، ځکه چې د کوربه حل کوونکی میراث اخلي.

TLS هغه پرېکړه ده چې وروسته غورځول کیږي او بیا بل ناکامي تشریح کوي. که پراکسي بایټونه نه لاس وهل شوي ولېږي، کانټینر د API خپل سند ویني او په خپل باور زېرمه کې داخلي CA ته اړتیا لري. که پراکسي TLS پای ته ورسوي، هغه باور کوربه ته ځي او اپلیکیشن له ترلاسه شوي host سرلیک څخه تړنې جوړول پیل کوي. یو ترتیب وټاکئ او پر هرې سرچینې یې پلي کړئ، ځکه چې د بل لخوا صادر شوی لېږد داسې کوربه نوم ته اشاره کوي چې کانټینر یې حل نه شي کولی.

له خدمت دننه تایید کړئ

غوښتنه له کوربه نه، له کانټینر څخه ولېږئ: د پراکسي لارې ته یو ساده curl، بیا د اپلیکیشن خپله روغتیایي کتنه. کله چې پراکسي ځواب ورکوي خو اپلیکیشن لا هم ناکام کیږي، درې شیان پرتله کړئ: هغه بنسټیز URL چې جوړوي، په چاپېریال کې هر پراکسي بدل، او هغه CA چې باور پرې لري. ټول د کانټینر په چاپېریال او لاګونو کې دي، او له دوی څخه هر یو سمول VPN ته لاس نه ورکوي.

ټاکل شوی ترتیب په پروژې README کې ولیکئ څو چې لا تازه دی. که نه، بل څوک چې له دې وخت تیرېدو سره مخ شي هماغه ماسپښین به د دې په بیا کشفولو کې تیر کړي چې تونل پر کوربه اوسیږي.