لینکس IPsec گیٹ وے پر TCP MSS کی تنظیم: یہ کیا درست کرتی ہے

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

وہ علامت جو MSS کی طرف اشارہ کرتی ہے

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

ICMP کی رائے راستے کے MTU کی دریافت کے ذریعے کنکشن بچا سکتی ہے، اور ان پیغامات کو گرا دینے والا فائر وال رکنے کو خاموش سیاہ سوراخ میں بدل دیتا ہے۔ اسی لیے وہی ٹنل ایک ایپلیکیشن کے لیے کام کرتی ہے اور دوسری کے لیے ترتیب میں کسی واضح فرق کے بغیر ناکام ہو جاتی ہے۔

TCPMSS قاعدہ کیا کرتا ہے اور کیا نہیں

قاعدہ گزرتے TCP ہینڈ شیک پیکٹوں میں MSS اختیار کو دوبارہ لکھتا ہے۔ یہ ٹنل انٹرفیس کا MTU مقرر نہیں کرتا، IPsec پالیسی نہیں بدلتا، اور موجودہ کرنل پر صرف اعلان کردہ قدر کم کرتا ہے، پہلے سے چھوٹی قدر نہیں بڑھاتا۔ یہ صرف TCP کو چھوتا ہے؛ UDP پے لوڈ، DNS کا رویہ اور طے شدہ ٹریفک منتخب کرنے والے اس کی پہنچ سے باہر ہیں۔

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

قاعدہ کو اندرونی TCP راستے پر رکھیں

پالیسی پر مبنی لینکس گیٹ وے پر، فائر وال جب آگے بھیجا گیا پیکٹ دیکھتا ہے تو بھی وہ عام TCP جیسا ہی لگتا ہے۔ IPsec پالیسی طے کرتی ہے کہ پیکٹ محفوظ ہوگا؛ فائر وال اندرونی بہاؤ کے لیے ESP ہیڈر نہیں دیکھتا، اس لیے یہاں ESP سے مطابقت پوری طرح مختلف پیکٹ بیان کرتی ہے۔ یہی عدم مطابقت سبب ہے کہ کچھ قواعد درست لگتے ہیں اور کبھی مطابقت نہیں رکھتے۔

iptables کی اصطلاح میں قاعدہ آگے بھیجنے والے راستے کی mangle جدول میں آتا ہے، ہینڈ شیک پیکٹوں تک محدود: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1270۔ عدد ایک مثال ہے، عالمگیر مستقل نہیں؛ اسے انکپسولیشن اوور ہیڈ اور راستے کے اصل MTU سے حاصل کریں۔ nftables کا متبادل forward یا postrouting زنجیر میں زیادہ سے زیادہ حصے کا سائز مقرر کرتا ہے۔

IKE اور ESP کے لیے بیرونی سننے والے قواعد کو اندرونی آگے بھیجنے والے قواعد سے الگ رکھیں۔ ایک ہی قاعدہ جو ایپلیکیشن کے بہاؤ اور بیرونی پروٹوکول دونوں کو اجازت دینے کی کوشش کرتا ہے، آخر میں دونوں میں سے کسی سے بھی قابل اعتماد مطابقت نہیں رکھتا۔

فائر وال کے مالک اور NAT کی ترتیب کا احترام کریں

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

ماخذ کی ترجمہ ایک الگ فیصلہ ہے جو اکثر اس کے ساتھ تعامل کرتا ہے۔ عام masquerade قاعدے سے پہلے رکھی گئی رعایت محفوظ ٹریفک کو اس ماخذ سے محروم ہونے سے روکتی ہے جس کا اس کی پالیسی تقاضا کرتی ہے؛ یہ سائز کا مسئلہ درست نہیں کرتی، اور سائز کا قاعدہ ترجمے کا مسئلہ درست نہیں کرتا۔

تنگی سے تصدیق کریں، پھر رکیں

ناکام سروس کے لیے نیا کنکشن کھولیں اور ایپلیکیشن اور قاعدے کے کاؤنٹر دونوں دیکھیں۔ اگر رکنا دور ہو جائے، تو آپ کے پاس اس انکپسولیشن کے ساتھ اس TCP راستے کے بارے میں ثبوت ہے۔ آپ کے پاس یہ ثبوت نہیں کہ ہر VPN پروٹوکول فٹ ہوتا ہے، ہر UDP ایپلیکیشن درست ہو گئی ہے، یا کوئی مخصوص اپ اسٹریم سروس اصل وجہ تھی۔

جہاں پالیسی اجازت دے وہاں ICMP سائز کی رائے کام کرنے دیں، اور جب بیرونی IPsec راستہ اندرونی روٹ سے ظاہر نہ ہو تو روٹ-MTU کی بنیاد پر خودکار تنظیم کو احتیاط سے سنبھالیں۔ نتیجہ جتنا تنگ ہوگا، اگلے واقعے کی تشخیص اتنی ہی آسان ہوگی۔