د VPN له لارې MySQL localhost: دا لا هم محلي پروسې ته اشاره کوي

د دفتر په سرور کې اپلیکیشن له MySQL سره په localhost باندې نښلول کوي، تاسو هغه هوسټ نوم ډیسکټاپ کلاینټ ته کاپي کوئ، او اړیکه یا ناکامه کېږي یا بل ډیټابیس پرانیزي۔ VPN د کلمې په مانا کې هېڅ نه دی بدل کړی: localhost لا هم هغه ماشین ته اشاره کوي چې کلاینټ پرې چلېږي۔ VPN پاکټونه وخوځول، نه انټرفیسونه۔ له کومې لارې د لاس وهلو دمخه پریکړه وکړئ چې لپ ټاپ باید کوم پای ټکي ته ورسیږي۔

ګام 1: پریکړه وکړئ چې لپ ټاپ باید کوم پای ټکي ته ورسیږي

دواړه ډیزاینونه قانوني دي او بېلو پوښتنو ته ځواب ورکوي۔ مستقیم لاسرسی مانا دا ده چې ډیټابیس په شخصي پته اورېدل کوي چې تونل ورته رسیږي، او لپ ټاپ له هغې پتې سره نښلي۔ لېږدول شوی لاسرسی مانا دا ده چې ډیټابیس پر loopback پاتې کېږي او یوه SSH ناسته پورټ ستاسو ماشین ته وړي۔ یو په قصد وټاکئ، ځکه د دواړو ګډول داسې اړیکه جوړوي چې په غلط دلیل کار کوي۔

د مستقیم لاسرسي لپاره، د ډیټابیس هوسټ خپل شخصي نوم یا پته او د هغې پورټ له هغه چا واخلئ چې اداره یې کوي۔ د VPN دروازې پته د ډیټابیس پته نه ده، پرته له دې چې هغه هماغه ماشین وي۔ بیا ډاډ ترلاسه کړئ چې اورېدونکی واقعاً له هغه انټرفیس سره تړلی دی، ځکه انټرفیس ته لاره پرې اورېدونکی نه جوړوي۔

ګام 2: پورټ یوازې هغه وخت ولېږدئ چې اورېدونکی محلي پاتې شي

که ډیټابیس باید یوازې پر loopback پاتې شي، له SSH لارې یې ولېږدئ او محلي سر هم له loopback سره وتړئ۔ په کیڼ اړخ کې د تړلو پته ستاسو د لپ ټاپ ده؛ په ښي اړخ کې هدف د SSH سرور له خوا تفسیر کېږي، لکه چې د OpenSSH حواله بیانوي۔ دې دوو رولونو بدلول هغه عام دلیل دی چې لېږد کار کوونکی ښکاري خو له هېڅ شي سره نه نښلي۔

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:13306:127.0.0.1:3306 [email protected]
ss -ltn 'sport = :13306'

که SSH د ډیټابیس هوسټ پرځای پر یوه ټوپ هوسټ کېنې، په ښي اړخ کې loopback هغه ټوپ هوسټ ته اشاره کوي، او هدف باید هغې پتې ته بدل شي چې هغه هوسټ ورته رسیږي۔ ExitOnForwardFailure د لېږد جوړېدو ناکامي نیسي، خو دا نه ثابتوي چې وروسته اړیکې هدف ته بریالۍ کېږي۔ د هوسټ کیلي کتنه فعاله وساتئ، او د لېږد پورټ مه خپل ټول LAN ته وړاندې کوئ په دې توګه چې له ټولو انټرفیسونو سره یې وتړئ۔

ودرېږئ که ډیټابیس باید یوازې پر loopback پاتې شي او تاسو SSH نه شئ کارولی۔ نو مستقیم لاسرسی غلط ډیزاین دی، نه هغه تنظیم چې زور پرې وشي۔

ګام 3: کلاینټ TCP ته اړ کړئ

په Unix کې، هغه MySQL کلاینټ چې localhost ورته ورکړل شي په ډیفالټ توګه یو Unix ساکټ ټاکي، نو یوازې پورټ بدلول کېدای شي هغه داسې ساکټ په لټه کې پرېږدي چې ستاسو له لېږد سره هېڅ تړاو نه لري۔ روښانه TCP پروتوکول او loopback پته وکاروئ تر څو کلاینټ ستاسو د لېږد پورټ ته اړیکه پرانیزي۔

mysql --protocol=TCP --host=127.0.0.1 --port=13306 --user=DB_USER --password

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

ودرېږئ که وسایل TCP ته اړ نه شي کېدای۔ نو بل کلاینټ وکاروئ، یا شخصي اورېدونکي ته مستقیم لاسرسی وکاروئ۔

ګام 4: ثابت کړئ چې تاسو واقعاً کوم پای ټکي ته رسېدلي یاست

له سرور څخه وپوښتئ چې اړیکه څه ګڼي۔ د هوسټ نوم، پورټ او ساکټ متغیرونه درته وایي چې آیا د TCP له لارې راغلې یاست او کوم اورېدونکی ځواب ورکړ، او د اړیکو لړلیک هغه سرچینه پته ښیي چې سرور ثبت کړې۔ هغه شاهد له بلې لارې بدلون څخه ګټورتر دی۔

mysql --protocol=TCP -h 127.0.0.1 -P 13306 -u DB_USER -p -e "SELECT @@hostname, @@port, @@socket"

ثبت کړئ چې کوم پای ټکي ته مو هڅه وکړه: محلي Unix ساکټ، ستاسو د لېږد پورټ یا شخصي اورېدونکی۔ دې درې ناکامیو بېلې حل لارې لري، او د VPN لارې بدلول په داسې حال کې چې کلاینټ لا هم له غلط localhost سره خبرې کوي، ضایع کوښښ دی۔ په یادښتونو کې SSH تصدیق او د ډیټابیس تصدیق هم جلا وساتئ، ځکه له ډیسکټاپ کلاینټ څخه په یوه کې ناکامي د بلې په ناکامي څیر ښکاري۔ بیا کله چې پای ته ورسېدل، لېږد لرې کړئ۔

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