د Android د یو VPN قاعده د SSH هوسټ شوی سرور نه بندوي

دا باور دومره عام دی چې د حقیقت په توګه وګڼل شي: Android یوازې یو VPN ته اجازه ورکوي، نو په تلیفون کې چلېدونکی SSH سرور نشي کولی د هغې تونل له لارې کار وکړي. لومړۍ نیمایي سمه ده او پایله ترې نه راځي. د پلیټ فارم محدودیت د دې په اړه دی چې څو اپلیکیشنونه کولی شي د VPN خدمت ځای ونیسي، نه د دې په اړه چې څو socketونه شتون ولري یا څوک تلیفون ته وصل کېدای شي. د اورېدونکي socket سره SSH ډیمون یو عادي اپلیکیشن دی چې عادي پورټ لري، او تونل هغه لارو څخه یوه ده چې د هغې ترافیک یې نیولی شي.

د یو VPN قاعده واقعاً څه محدودوي

VpnService د یوې ځای سرچینه ده. کله چې یو اپلیکیشن تونل جوړوي هغه د وسیلې VPN ګرځي، او دویم اپلیکیشن چې تونل جوړول غواړي تر هغه رد کېږي چې لومړی لاړ نه شي. دا د تونل د مالکیت قاعده ده او تشریح کوي چې ولې دوه VPN کلاینټونه نشي کولی یوځای کار وکړي.

دا د اورېدونکو socketونو په اړه هیڅ نه وایي. SSH سرور VpnService ته زنګ نه وهي، پاکټونه نه نیسي او د هغه ځای لپاره سیالي نه کوي. دا یو پورټ تړي او اړیکې مني، هغه څه چې پرته له VPN هم به یې کول. نو افسانه د تونل عرضه کوونکو محدودیت د شبکې اړیکو محدودیت سره ګډوي، او دواړو ترمنځ هیڅ اړیکه نشته.

اورېدونکی یو هدف دی، د تونل برخه نه ده

کله چې تونل شتون ولري، تلیفون پرې یو پته لري او سیال وسیله هغې پتې ته لاره لري. چې څه ځواب ورکوي، اورېدونکی یې فیصله کوي. loopback ته تړلی ډیمون یوازې له تلیفون څخه د لاسرسي وړ دی؛ زاړه تونل پتې ته تړلی ډیمون له بیا نښلېدلو وروسته خپل تړاو ساتلی شي، که څه هم هغه پته چې تړلی و پرې بدله شوې ده.

د تړلو قواعد عادي SSH ترتیبات دي: د اورېدلو پته او پورټ، او چې څوک تصدیق کولی شي. په Android کې هغه تنظیمات د اپلیکیشن په خپل ترتیب کې دي، او د اپلیکیشن د پروسې مالک ته ممکن اجازه نه وي چې ځانګړي پورټونه وکاروي، نو د root په توګه د 22 پورټ تړلو ډیسکټاپ عادت پرته له بدلون نه انتقالېږي.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

بیا د لارې په خپله اجازه ده. مصرف کوونکی VPN چې وتونکی ویب ترافیک په خوښۍ وړي، اړتیا نه لري چې خپلو کلاینټونو ته د ننوتلو اړیکو ته اجازه ورکړي؛ ډیر یې نه ورکوي، ځکه چې یو ګډونوال به بل ته ښکاره کړي. که سیال له کوم ځایه د تلیفون تونل پتې ته ونه رسېږي، ستونزه د خدمت په تګلاره کې ده، په تلیفون کې نه.

د ځواب لاره هغه ځای دی چې معمولاً ماتېږي

فرض کړو سیال د تلیفون تونل پتې ته رسېږي او SYN راځي. اوس ځواب باید همدې لارې ووځي، او دا د تلیفون دننه د لارښوونې پریکړه ده. که ځواب د Wi-Fi له لارې ووځي ځکه چې هغه اصلي شبکه ده، سیال هغه اړیکه ویني چې هیڅکله بشپړه نه شي، چې بالکل د اور وژنې ډول ښکاري.

Android دا د ډیسکټاپ په پرتله نور هم پېچلی کوي ځکه چې اصلي شبکه د هرې پروسې لپاره غوره کېږي او د VPN اپلیکیشن تګلاره یې بدلولی شي. VPN کلاینټ یوازې د اجازه ورکړل شوو اپلیکیشنونو لیست لارښوونه کولی شي، نو هغه سرور اپلیکیشن چې له دې لیست بهر دی خپلو ځوابونو لپاره فزیکي شبکه کاروي، پداسې حال کې چې سیال هغه د تونل له لارې تمه لري.

یو اپلیکیشن کولی شي خپل socketونه یوې ځانګړې شبکې ته وتړي، چې اصلي تنظیم لره غورځوي. کله چې تاسو راپور ولولئ چې یو خدمت له یوې پتې څخه د لاسرسي وړ دی او له بلې نه، نو معمولاً همدا هغه میکانیزم دی چې شاته دی.

د VPN څخه تېرېدل ننوتونکی خدمت نه جوړوي

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

همدا د روټر پر عامه پورټ د خلاصولو په اړه هم صدق کوي. که غوښتنه دا وي چې یوه مجازه وسیله د VPN له لارې تلیفون ته ورسیږي، SSH انټرنیټ ته ښکاره کول بېل ګواښ ماډل دی، نه ترمیم.

لومړی د خدمت پته وټاکئ: د تلیفون LAN پته، د هغې تونل پته، یا په قصد لاسوند شوی پای ټکی. هر یو خپل د لاسرسي او ښکارېدلو تړون لري، او د هغوی ګډول همدا لاره ده چې یوه کوچنۍ د لاسرسي ستونزه تلپاتې سوری شي.

په یو وخت کې یوه لوری تشخیص کړئ

د ترتیب بدلولو دمخه څلور حقایق ولیکئ: هغه پته چې سیال ورسره نښلېږي، په تلیفون کې د اورېدونکي حالت، هغه اپلیکیشن او کارونکي زمینه چې دا لري، او په هر لوري کې لیدل شوې لاره. هغه راپور چې وایي VPN SSH قطع کوي هیڅ یو له دې نه لري او نشي کولی د کلاینټ د انتقال ستونزه له نه رسېدونکي سرور څخه بېل کړي.

adb shell ip -br addr
adb shell ip route get 10.90.0.9
nc -vz 10.90.0.4 2222

د پورټ کتنه له سیال څخه چل کړئ، نه له تلیفون څخه، او د SSH کلاینټ مفصل تولید ولولئ چې وګورئ مخکې یا وروسته د TCP لاس نیول ناکامېږي. هغه socket چې هیڅکله نه نښلېږي او رد شوې ننوتل بېل پړاوونه دي چې بېل مسؤلین لري.

د ډیبګ پر مهال د کوربه کیلي تصدیق او د حساب محدودیتونه مات نه کړئ. د اورېدونکي او اجازه ورکړل شوو کارونکي محدودول همدا هغه څه دي چې د لاسرسي وړ سرور د منلو وړ جوړوي؛ د اړیکې د چلولو لپاره یې نرموول یوه ستونزه په بدتره بدله کوي. د OpenSSH سرور حواله د اورېدلو او لاسرسي کنټرولونه رانغاړي که ستاسو Android پلي کول همدغه د ترتیب نومونه تعقیب کړي.