VPN کے بغیر Git رکتا ہے؟ OpenSSH IPQoS سے پیکٹ پر نشان لگاتا ہے

OpenSSH بطور طے شدہ اپنے پیکٹوں پر QoS قدر کا نشان لگاتا ہے۔ جہاں راستہ وہ نشان پھینک دیتا ہے، وہاں push اس وقت تک رکتا ہے جب تک کوئی سرنگ پیکٹوں کا راستہ نہ بدلے۔

دفتر سے بنایا گیا کلون کام کرتا ہے، فون کے ہاٹ اسپاٹ سے وہی کلون کام کرتا ہے، اور ہوٹل کے نیٹ ورک سے وہی کلون VPN آن ہونے تک لٹکتا ہے۔ SSH ہاتھ ملانا مکمل ہوتا ہے اور پہلی حقیقی منتقلی پر سیشن خاموش ہو جاتا ہے۔ کلائنٹ کنفیگریشن میں شامل ایک سطر git اور ssh دونوں کو ساتھ ٹھیک کرتی ہے۔ جب ایک کلائنٹ سیٹنگ بیک وقت کئی اوزار درست کرتی ہے، تو خرابی اسی میں ہے جو کلائنٹ بھیجتا ہے، اُس لنک میں نہیں جس سے بھیجتا ہے۔

علامت کو راستے کے فرق کے طور پر پڑھیں

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

جہاں سیشن مرتا ہے وہ نقطہ اِسے مزید تنگ کرتا ہے۔ نام کی تلاش یا کلید کے تبادلے میں ناکام ہونے والی کوئی چیز ایسی نہیں دکھتی۔ جو سیشن تصدیق کرتا ہے، بینر چھاپتا ہے اور پھر پہلی بڑی تحریر پر جم جاتا ہے، وہ پہلے ہی ثابت کر چکا ہے کہ راستہ، نام اور اسناد سب کام کر رہے ہیں۔

کلائنٹ ہر SSH ساکٹ پر QoS بائٹ لگاتا ہے

7.8 سے ہر OpenSSH کنکشن IP ہیڈر میں وہ قدر رکھتا ہے جو راؤٹر ٹریفک کو ترجیح دینے کے لیے استعمال کر سکتے ہیں۔ ٹرمینل سیشنوں کو ایک قدر ملتی ہے اور بڑی نقولوں کو دوسری، اِس نظریے پر کہ ٹائپ کرنے والا انسان فائل کی منتقلی سے بہتر سلوک کا حقدار ہے۔ زیادہ تر نیٹ ورکس اِس اشارے کو مکمل نظر انداز کرتے ہیں، اسی لیے یہ برسوں تک نظر نہیں آتا۔ بہت کم Wi-Fi ڈرائیور، موبائل آپریٹر اور VPN مرکز اِس پر عمل کرتے ہیں، اور اُن میں سے کچھ برا سلوک کرتے ہیں۔

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

پہلے ssh -V سے کلائنٹ ورژن کی تصدیق کریں۔ 7.8 یا اس سے اوپر کا کوئی بھی ورژن یہ رویہ بطور طے شدہ رکھتا ہے۔

تین کمانڈیں جو اِسے MTU اور DNS سے الگ کرتی ہیں

کوئی بھی کنفیگریشن فائل ترمیم کرنے سے پہلے دو ملتی جلتی وجوہات خارج کرنی چاہئیں۔ MTU کی خرابی چھوٹے تبادلے گزرنے دیتی ہے اور پہلے بڑے پیکٹ پر جم جاتی ہے، جبکہ نام کی خرابی کبھی سیشن نہیں بناتی۔

ssh -o IPQoS=none -v [email protected]
ssh -G [email protected] | grep -i ipqos
sudo tcpdump -ni any -vv "tcp port 22"

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

قبضہ سرور پر نہیں بلکہ لیپ ٹاپ پر کریں، کیونکہ قدر رکھنے والا بھیجنے والا ہے اور دونوں سمتیں اُسے بدل سکتی ہیں۔ چلنے والے اور ناکام راستے کا ایک ہی قبضے سے موازنہ کریں، اندازے کے بغیر فرق ظاہر ہو جائے گا۔

استثنا کو ایک فائل میں رکھیں، ایک وقت میں ایک میزبان

استثنا اُس میزبان کے پاس ہونا چاہیے جس پر لاگو ہوتا ہے، ساتھ ایسی تبصرہ جو بتائے کہ یہ کیوں موجود ہے۔

Host gitlab.example.internal
    IPQoS none
    # direct route rewrites the marking; the tunnel route passes it

قدر سے زیادہ دائرہ اہم ہے۔ وائلڈ کارڈ اندراج رویے کو ہر جگہ بند کر دیتا ہے، اچھے سلوک والے نیٹ ورکس میں مددگار اشارہ پھینک دیتا ہے، اور کسی کو یہ بتانے نہیں دیتا کہ یہ کب آیا۔ فی میزبان اندراج پڑھنے کے قابل، واپس پلٹنے کے قابل اور نیٹ ورک درست ہونے پر مٹانے میں بہت آسان ہے۔ ذاتی حل کے لیے صارف کی فائل اور جب پورے بیڑے کو وہی استثنا درکار ہو تو زیرِ انتظام فائل استعمال کریں۔

واضح کہیں کہ استثنا کیا نہیں ڈھکتا۔ یہ SSH پر لاگو ہوتا ہے، اس لیے HTTPS ریموٹ، پیکیج آئینہ اور براؤزر سب اِس سے باہر ہیں، اور اِن میں سے کسی کی ناکامی کو اپنا ثبوت چاہیے۔ باسٹین سے گزرنے والی زنجیر میں ہر چھلانگ کلائنٹ کنفیگریشن استعمال کرتی ہے، اور جو چھلانگ رکتی ہے وہی محدود کرنے کے قابل ہے۔

نیٹ ورک کے مالک کے ساتھ دائرہ بند کریں

دریافت کو چار حقائق کے طور پر سونپیں: کلائنٹ ورژن، آزمایا گیا راستہ، زیرِ استعمال VPN کلائنٹ، اور کون سی سمت نے نشان اٹھایا۔ یہ چار نیٹ ورک کے مالک کے لیے سلوک دوبارہ پیدا کرنے اور یہ فیصلہ کرنے کے لیے کافی ہیں کہ یہ جان بوجھ کر ہے یا نہیں۔

اگر استثنا رکاوٹ درست نہ کرے تو اُسے ہٹا دیں۔ ناکام تجربے سے بچ نکلا حل افسانہ بن جاتا ہے، اور اگلا شخص ایک گھنٹہ یہ ثابت کرنے میں لگاتا ہے کہ وہ کچھ نہیں کرتا۔ اگر وہ رکاوٹ درست کر دے، تو راستہ اب بھی اُس سے گزرنے والے ہر دوسرے اوزار کے لیے غلط ہے، اور مرمت درمیانی آلہ چلانے والے کی ذمہ داری ہے۔

کلائنٹ میں تبدیلی میعاد والا عارضی حل ہے۔ وہ تاریخ تبصرے میں لکھیں۔

متعلقہ مضامین