NGINX اسٹریم ریلے کے ذریعے SSH — بغیر توڑے

ریلے کے ذریعے عوامی SSH دو غیر متعلقہ حدود پر ناکام ہوتا ہے، اور ایک کو درست کرنے سے عام طور پر دوسری ظاہر ہوتی ہے۔ یا تو کنارہ اسٹریم لے جانے کے بجائے HTTP جواب واپس کرتا ہے، یا ریلہ آگے وہ ہیڈر لگاتا ہے جسے بیک اینڈ نے کبھی پڑھنے کی رضامندی نہیں دی۔ آپ کون سا دیکھ رہے ہیں یہ تین شرطیں طے کرتی ہیں: عوامی ریکارڈ واقعی کس طرف اشارہ کرتا ہے، اسٹریم بلاک بالائی حصے کو کیا بھیجتا ہے، اور SSH کلائنٹ کون سا نام تصدیق کرتا ہے۔ اسی ترتیب سے انہیں نمٹائیں۔

دو حدیں، دو علامات

کنارے کی ناکامی ایسے دکھتی ہے جیسے جہاں SSH بینر ہونا چاہیے وہاں HTTP اسٹیٹس صفحہ آ رہا ہو۔ کنکشن TCP سطح پر مکمل ہوتا ہے اور پہلے بائٹ ویب سرور کا متن ہیں۔ یہ پروٹوکول کی عدم مطابقت ہے، گم شدہ پیکٹ نہیں۔ یہ آپ کو یہ بھی بتاتا ہے کہ کنارہ اُس نام کے لیے جان بوجھ کر کچھ اور پیش کر رہا ہے۔

بالائی حصے کی ناکامی مختلف دکھتی ہے۔ کنکشن sshd تک پہنچتا ہے، sshd وہ بائٹ پڑھتا ہے جو اس کی متوقع شناخت کی تبدیلی نہیں ہیں، اور سیشن کبھی چابی پیش کیے بغیر مر جاتا ہے یا لٹک جاتا ہے۔

ان دونوں کو گڈمڈ کرنا آسان ہے کیونکہ دونوں ایسا کلائنٹ بناتے ہیں جو جڑتا ہے اور پھر ناکام ہوتا ہے۔ آپ کو ملنے والا پہلا پروٹوکول جواب ہی انہیں الگ کرتا ہے، اسی لیے اُسے ٹکٹ میں ہونا چاہیے۔

PROXY ہیڈر ایک پیغام ہے، سوئچ نہیں

اسٹریم ماڈیول میں، proxy_protocol on NGINX کو پے لوڈ سے پہلے بالائی سمت میں PROXY پروٹوکول ہیڈر لکھنے کا حکم دیتا ہے۔ یہ TCP پراکسی فعال نہیں کرتا، اور SSH انکرپشن سے اس کا کوئی تعلق نہیں۔ یہ وصول کنندہ سے مخاطب نوٹ ہے۔ اگر وصول کنندہ اسے پڑھ نہ سکے تو یہ اسٹریم کے آغاز میں کوڑا بن جاتا ہے۔

وصول کرنے والی سروس کو وہ ہیڈر جان بوجھ کر استعمال کرنا چاہیے۔ عام sshd کنکشن کے پہلے بائٹ کے طور پر SSH شناخت کی تبدیلی کی توقع کرتا ہے، اس لیے غیر متوقع پیش لفظ ہاتھ ملانے کو اس طرح توڑتا ہے جو خراب سرور جیسا لگتا ہے۔

stream {
    server {
        listen 2222;
        proxy_pass 10.77.0.20:22;
    }
}

وہ ٹکڑا VPN کے ذریعے قابل رسائی بیک اینڈ کے لیے مکمل کام کرنے والا ریلہ ہے۔ کوئی PROXY ہدایت نظر نہیں آتی کیونکہ وصول کنندہ وہ پروٹوکول نہیں بولتا، اور یہ عدم موجودگی کوتاہی نہیں، فیصلہ ہے۔

دونوں سمتوں کو بھی الگ کریں۔ listen سطر پر proxy_protocol مقرر کرنے کا مطلب ہے کہ NGINX توقع کرتا ہے کہ اس کا اپنا کلائنٹ پہلے ہیڈر بھیجے؛ عام SSH کلائنٹ کے لیے اسے فعال کرنا اُس مسئلے کا بالکل اُلٹ پیدا کرتا ہے جسے لوگ عام طور پر حل کرنے کی کوشش کرتے ہیں۔

عوامی ہوسٹ نام واقعی کہاں پہنچتا ہے

SSH سیشن میں HTTP 400 صفحہ کنارے کے بارے میں ثبوت ہے۔ راستے میں کچھ HTTP بول رہا ہے، اور بیک اینڈ پر چابی یا اکاؤنٹ کا کوئی بھی کام اسے نہیں بدلے گا۔ کنارہ طے ہونے تک بیک اینڈ بدلنا بند کریں۔

Cloudflare کا عام پراکسی شدہ ریکارڈ اپنی معاون HTTP اور HTTPS ٹریفک مقررہ پورٹس پر لے جاتا ہے۔ ہوسٹ نام کے لیے پراکسی چالو کرنا عام TCP ریلہ نہیں بناتا، اور SSH کو پورٹ 443 پر منتقل کرنا اسے HTTPS نہیں بناتا۔

دو قابل عمل سمتیں موجود ہیں۔ صرف DNS ریکارڈ آپ کے اپنے TCP ریلے کی طرف اشارہ کر سکتا ہے، جو افشا کا فیصلہ آپ کے ہاتھ میں چھوڑتا ہے۔ بصورت دیگر، ایسی مصنوعات استعمال کریں جو SSH کی ترسیل کو واضح طور پر دستاویز کرے، اپنی ماخذ، کلائنٹ اور رسائی ترتیب کے ساتھ۔

آپ جو بھی منتخب کریں، ریلے کو پھر بھی بیک اینڈ تک VPN راستہ، اجازت شدہ کنکشن اور واپسی راستہ درکار ہے۔ راستہ اختیاری نہیں کیونکہ عوامی حصہ کام کرتا ہے۔

عرف کے ذریعے SSH شناخت مستحکم رکھیں

صارفین عام طور پر اپنا موجودہ ہوسٹ نام ٹائپ کرتے رہنا چاہتے ہیں۔ SSH ترتیب میں عرف ریلے کے بارے میں کچھ بدلے بغیر یہ کر سکتا ہے، اور تبدیلی کو کلائنٹ کی جانب رکھتا ہے جہاں اس کی جگہ ہے۔

Host git.example.com
    HostName ssh-entry.example.net
    Port 2222
    User git
    HostKeyAlias git.example.com

HostKeyAlias کے بغیر، OpenSSH ہوسٹ چابی کو اُس نام کے تحت ڈھونڈتا ہے جس سے جڑتا ہے، اس لیے اندراج سرک جاتا ہے اور ہر صارف پہلے استعمال پر چابی بدلنے کی وارننگ دیکھتا ہے۔ عرف مقرر کرنے سے known-hosts اندراجات مستحکم رہتی ہیں جبکہ کنکشن اب بھی ریلے کی طرف جاتا ہے۔

یہ عرف صرف SSH پر مبنی بعید ذخائر پر لاگو ہوتا ہے۔ HTTPS Git URL اس سے رجوع نہیں کرتا، اور عام بعید URL کو اُس ترسیل سے مطابقت رکھنی چاہیے جو آپ نے واقعی تیار کی۔

جو آپ کو نہیں کرنا چاہیے وہ یہ ہے کہ وارننگ ختم کرنے کے لیے ہوسٹ چابی کی تصدیق بند کر دیں۔ یہ اُس تحفظ کو ہٹاتا ہے جسے فارورڈنگ کی مرمت نے کبھی چھونے کو نہیں کہا، اور ظاہری تکلیف کو حقیقی افشا میں بدل دیتا ہے۔

ہر چھلانگ کو الگ الگ تصدیق کریں

عوامی سامع کو تنہا جانچیں، پھر ریلے ہوسٹ سے ریلے تا بیک اینڈ کنکشن، اور اُس کے بعد ہی کلائنٹ کو شروع سے آخر تک۔ اُن تین جانچوں میں سے ہر ایک مختلف پرت کو خارج کرتی ہے۔ ایک چھوڑنے کا مطلب ہے کہ باقی دو نتائج کی تشریح نہیں ہو سکتی۔ تین مشاہدات، ناکامی کے رہ سکنے کی تین جگہیں۔

ہر نتیجے کے ساتھ منزل کا پتہ، پورٹ اور پہلے پروٹوکول بائٹ رکھیں۔ یہ تینوں کنارے کی خرابی کو VPN روٹنگ مسئلے اور SSH تصدیق کی ناکامی سے الگ کرتی ہیں، اور یہی مرمت اور اندازے کے درمیان فرق ہے۔

آخر میں، مطلوبہ افشا کی دستاویز کریں۔ نجی بیک اینڈ تک SSH لے جانے والا TCP ریلہ عوامی دائرے میں جان بوجھ کر کھلا دروازہ ہے، اور یہ کسی بھی دوسری آمد سروس کی طرح جائزے کا حق دار ہے۔