اپنے VPN پر SOCKS پراکسی کے طور پر SSH کی متحرک فارورڈنگ
صرف SOCKS بولنے والی ایپ کے پاس عام VPN پر کوئی پراکسی اینڈ پوائنٹ نہیں ہوتا۔ دو چھلانگیں، ایک لوپ بیک سننے والا اور ایک نام کی تلاش جو SSH سرور کو خود کرنی ہوتی ہے۔
صرف SOCKS بولنے والی ایپ کے پاس عام VPN پر بات کرنے کو کچھ نہیں ہوتا، کیونکہ ٹنل پیکٹ لے جاتی ہے اور ایپ کو پراکسی اینڈ پوائنٹ چاہیے۔ OpenSSH وہ اینڈ پوائنٹ اس وقت دے سکتا ہے جب رسائی کا مالک اجازت دے، کیونکہ متحرک فارورڈنگ ایک SSH سیشن کو مقامی پراکسی بنا دیتی ہے۔ پھر دو چھلانگیں الگ رکھنی ہوتی ہیں: وہ ٹنل جو SSH ہوسٹ تک پہنچتی ہے، اور وہ کنکشن جو یہ ہوسٹ آگے کھولتا ہے۔ انہیں الگ کرنا دونوں باتیں واضح کرتا ہے کہ یہ انتظام کیوں کام کرتا ہے اور یہ کبھی کیا نہیں کرے گا۔
SSH سننے والا کیا بنتا ہے اور کیا نہیں
متحرک فارورڈنگ SSH کلائنٹ کو مقامی طور پر سننے اور جو بھی جڑتا ہے اس سے SOCKS4 یا SOCKS5 بولنے پر مجبور کرتی ہے۔ ہر درخواست ایک منزل کا نام لیتی ہے اور SSH سرور اگلا کنکشن کھولتا ہے، اسی لیے منزل کی تلاش دوسری طرف ہو سکتی ہے۔ یہ ایپلیکیشن سطح کی TCP فارورڈنگ ہے، پورے ڈیوائس کے لیے VPN نہیں۔ یہ کوئی UDP انجمن، کوئی ICMP، اور پراکسی سیٹنگز کو مکمل نظرانداز کرنے والی ایپس کے لیے کچھ نہیں لے جاتی۔ SSH سرور سے ایپ تک چھلانگ بھی آپ کی ٹنل کے اندر نہیں ہے، جو اس وقت اہم ہے جب منزل صرف جانے پہچانے نیٹ ورکس سے ٹریفک قبول کرتی ہے۔
پیشگی شرائط حقیقی ہیں: SSH ہوسٹ تک راستہ، مجاز اکاؤنٹ، تصدیق شدہ سرور ہوسٹ کلید اور فارورڈ کرنے کی اجازت۔ ان میں سے کوئی بھی پراکسی نہیں بناتی، اور آخری عموماً سب سے پہلے غائب ہوتی ہے۔ باقی کچھ بھی ڈیبگ کرنے سے پہلے چاروں کی تصدیق کریں، کیونکہ کلائنٹ کی طرف سے ناکامی یکساں دکھائی دیتی ہے، کوئی بھی غائب ہو۔
اسے واضح پورٹ کے ساتھ لوپ بیک پر شروع کریں
غیر استعمال شدہ مقامی پورٹ چنیں اور پتہ چھوڑنے کے بجائے اسے واضح طور پر لوپ بیک سے باندھیں۔ نیچے دیے گئے تین آپشن ہر ایک ایک وجہ سے موجود ہیں۔
ssh -D 127.0.0.1:1080 -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
[email protected]-N دور کے کمانڈ کو چھوڑ دیتا ہے اور -T سیوڈو ٹرمینل چھوڑ دیتا ہے، اس لیے سیشن صرف فارورڈ کرنے کے لیے ہے۔ ExitOnForwardFailure سننے والا نہ بن سکنے پر کلائنٹ کو باہر نکلنے دیتا ہے، آپ کی مانگی ہوئی فارورڈنگ کے بغیر چلنے کے بجائے۔ ControlPath=none سیشن کو کسی موجودہ ملٹی پلیکس کنکشن سے باہر رکھتا ہے جو اپنی فارورڈنگز شامل کر سکتا ہے۔ لوپ بیک سننے والے کو LAN سے باہر رکھتا ہے، لیکن مشترکہ مشین پر یہ اجازت کی حد نہیں ہے، کیونکہ دیگر مقامی عمل بھی اس تک پہنچ سکتے ہیں۔ OpenSSH کلائنٹ کا حوالہ ان تمام جھنڈیوں کو دستاویز کرتا ہے، اور لوپ بیک کی وارننگ اس بات سے نکلتی ہے کہ سننے والا ساکٹ کیا ہوتا ہے۔
نام پراکسی کے اندر سے بھیجیں، اس کے ارد گرد سے نہیں
SOCKS5 کلائنٹ منزل خود حل کر سکتا ہے یا پراکسی سے ایسا کرنے کو کہہ سکتا ہے، اور یہی انتخاب طے کرتا ہے کہ کون سا حل کنندہ جواب دے گا۔ socks5h کے ساتھ curl ہوسٹ نام پراکسی کے اندر سے بھیجتا ہے، اس لیے تلاش SSH سرور پر ہوتی ہے۔ سادہ socks5 کے ساتھ لیپ ٹاپ پہلے حل کرتا ہے اور صرف کنکشن جاتا ہے، جو نام اندرونی ہونے پر مقصد کو خاموشی سے بے کار کر دیتا ہے۔ نیچے کی درخواست بغیر پراکسی فہرست بھی صاف کرتی ہے، اس لیے ورثے میں ملی NO_PROXY قدر اسے پراکسی کے ارد گرد نہیں لے جا سکتی۔
curl -sS --noproxy '' --proxy socks5h://127.0.0.1:1080 https://app.corp.example/healthسرٹیفکیٹ کی تصدیق اور ایپ کا اپنا لاگ ان اب بھی لاگو ہیں، کیونکہ پراکسی دونوں میں سے کسی کو تبدیل نہیں کرتی۔ دو تلاشیں باقی رہتی ہیں: لیپ ٹاپ کو اجازت یافتہ VPN اور DNS راستے سے SSH ہوسٹ تک پہنچنا ہے، اور SSH سرور کو ایپ کا نام خود حل کرنا ہے۔ دوسری کو کسی بھی ٹریفک کے پراکسی سے گزرنے سے پہلے الگ سے جانچا جا سکتا ہے۔
ssh [email protected] getent hosts app.corp.exampleایک اجازت یافتہ منزل ثابت کریں، پھر سیشن بند کریں
وہ منزل جانچیں جس کی پالیسی اجازت دیتی ہے اور وہ بھی جسے اسے رد کرنا چاہیے، کیونکہ کام کرنے والی فارورڈنگ صرف یہ ثابت کرتی ہے کہ سننے والا کام کرتا ہے، اس سے زیادہ کچھ نہیں۔ ایپ وہ ماخذ پتہ دیکھتی ہے جو SSH سرور چنتا ہے، اور وہ آپ کے لیپ ٹاپ کا ٹنل پتہ نہیں ہے۔ جہاں دور کا سرا کنکشنز کو ماخذ کے مطابق لاگ کرتا ہے، وہاں درخواست رد ہونے پر پہلے وہی فرق دیکھنا چاہیے۔
سیشن کو اس کے مالک عمل کے ذریعے روکیں، کسی غیر متعلق شیل کو مار کر نہیں۔ پھر تصدیق کریں کہ سننے والا چلا گیا، کیونکہ اب بھی جواب دینے والا پورٹ وہ سیشن ہے جو آپ نے واقعی بند نہیں کیا۔ صرف وہی پراکسی سیٹنگ ہٹائیں جو اس مشق نے شامل کی، اور ایپ کنفیگریشن کا باقی حصہ جوں کا توں رہنے دیں۔ فارورڈنگ قاعدہ رکھنے والا بے نگرانی ٹرمینل سروس نہیں ہے، اور مستقل پراکسی کو منظور شدہ زندگی کا دورانیہ درکار ہے، بھولی ہوئی ونڈو نہیں۔
ss -ltn | grep 1080وہ ناکامیاں جنہیں یہ انتظام ٹھیک نہیں کر سکتا
کچھ علامات سیدھا اوپر کی حدود کی طرف اشارہ کرتی ہیں، اور انہیں جلدی پہچاننا پراکسی ڈیبگنگ کی ایک دوپہر بچاتا ہے۔ جدول آپ جو دیکھتے ہیں اسے اس سے جوڑتا ہے جس کا یہ عام طور پر مطلب ہوتا ہے۔ آخری کالم میں جو بھی ہے وہ کنفیگریشن کی غلطی نہیں، ڈیزائن کا سوال ہے۔
| What you see | What it usually means | Where to look |
|---|---|---|
| The app connects and nothing follows | It ignores proxy settings entirely | Its own network settings, not the SSH session |
| A name resolution error for the destination | The SSH server cannot resolve it | Server resolver and search domains |
| A UDP-only application fails | Dynamic forwarding carries TCP only | This arrangement cannot serve it |
| curl works, the browser does not | The browser is not using the socks5h endpoint | Browser proxy configuration |
| The listener answers after the session ended | Another process owns port 1080 | The ss output, then the owning process |
پہلی تین سطریں وہی ہیں جن کی لوگ غلط تشخیص کرتے ہیں، کیونکہ ہر ایک پراکسی کے بارے میں غلطی کے بجائے کنکشن کی کوشش پیدا کرتی ہے۔ لیپ ٹاپ پر حل ہونے والا نام سرور کے حل کنندہ کے بارے میں کچھ نہیں کہتا، اور ناکامی کو اس کے بجائے سرٹیفکیٹ یا وقت کی حد کا مسئلہ پڑھا جاتا ہے۔ صرف UDP والی ایپس ڈیزائن کے اندر ٹوٹی ہوئی نہیں، اس کے باہر کھڑی ہیں، اور کوئی اضافی ssh آپشن اسے نہیں بدلتا۔ براؤزر کی سطر یہ عام یاد دہانی ہے کہ پراکسی سیٹنگز ہر ایپ کے لیے الگ ہوتی ہیں۔ آخری سطر یہ بتاتی ہے کہ بند کرنے کی جانچ کیوں ہے: اب بھی سننے والا پورٹ یعنی اب کوئی اور اس کا مالک ہے۔