1,500 بائٹ کا مقررہ اندرونی پیکٹ VPN کے ذریعے منتقل کرنا

آپ کے پاس ایک نہ جھکنے والی ضرورت ہے: دوسری طرف کو وہی 1,500 بائٹ کا IP پیکٹ ملنا چاہیے جو بھیجنے والا خارج کرتا ہے، ہیڈرز سمیت۔ ٹنل اُس پیکٹ کو اپنی فریمنگ کے ساتھ دوسرے 1,500 بائٹ IP پیکٹ میں نہیں لپیٹ سکتا، اس لیے ڈیزائن میں کچھ نہ کچھ دینا پڑے گا۔ نیچے دیا گیا ترتیب وہی ہے جو میں تبدیلی کی ونڈو میں استعمال کرتا ہوں: بائٹ بجٹ لکھیں، ثابت کریں کہ underlay واقعی کیا لے جا سکتا ہے، پھر بالکل ایک نقل و حمل کا طریقہ منتخب کریں اور دوسری طرف اندرونی پیکٹ کی تصدیق کریں۔

پروفائل میں ترمیم سے پہلے بائٹ بجٹ لکھیں

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

دو عدد ڈیزائن کا فیصلہ کرتے ہیں: سب سے بڑا بیرونی پیکٹ جو راستہ بغیر فریگمنٹیشن کے لے جاتا ہے، اور وہ اضافی بائٹس جن کی آپ کی انکیپسولیشن کو ضرورت ہے۔ جب پہلا دوسرے میں 1,500 شامل کرنے سے کم ہو، تو ان میں سے ایک کو بدلنا ہوگا۔ تب انتخاب تخلیقی نہیں بلکہ تنگ ہو جاتا ہے، اس لیے میں اختیارات پر بحث سے پہلے دونوں عدد لکھ لیتا ہوں۔ ٹنل کی تہہ میں کوئی چیز اُن بائٹس کو دبا کر غائب نہیں کرتی، اور کوئی ایک MTU مکمل عدد آپ کو دی گئی ضرورت کو ختم نہیں کرتا۔

do-not-fragment ping سے underlay کی جانچ کریں

انٹرفیس MTU پر بھروسا نہ کریں بلکہ راستہ ناپیں، کیونکہ بیرونی راستے میں سب سے چھوٹا ربط اہم ہے۔ Linux پر, -M do do-not-fragment بٹ مقرر کرتا ہے اور -s ICMP پے لوڈ لیتا ہے، اس لیے 20 بائٹ IP ہیڈر اور 8 بائٹ ICMP ہیڈر نکالنے پر 1,500 بائٹ کا فریم 1,472 بائٹ پے لوڈ پر جواب دیتا ہے۔ پے لوڈ بڑھاتے جائیں جب تک جانچ ناکام نہ ہو، پھر jumbo حجم کی طرف چھلانگ لگائیں اور دیکھیں کہ راستہ اُسے بالکل لے جاتا ہے یا نہیں۔

ping -M do -s 1472 -c 2 198.51.100.10
ping -M do -s 8972 -c 2 198.51.100.10
tracepath -n 198.51.100.10

وہ راستہ جو 1,472 پار کرے اور 8,972 پر ناکام ہو، 1,500 بائٹ کے اندرونی پیکٹ کو اوور ہیڈ کے ساتھ ایک ہی بیرونی پیکٹ میں نہیں لے جا سکتا۔ یہی وہ جواب ہے جو VPN ترتیب کھولنے سے پہلے آپ کو درکار تھا۔ یہ بھی طے کرتا ہے کہ اگلے دو حصوں میں سے کون سا آپ پر لاگو ہوتا ہے، اس لیے دونوں جانچ کے نتائج ٹکٹ کے پاس رکھیں۔ یہاں اندازہ لگانا ایک مینٹیننس ونڈو ضائع کرتا ہے، کیونکہ خود کو up بتانے والا ٹنل راستے کے قبول کردہ سب سے بڑے پیکٹ کے بارے میں کچھ نہیں بتاتا۔

راستے کا MTU صرف وہاں بڑھائیں جہاں ہر hop متفق ہو

jumbo فریم end-to-end خصوصیت ہیں, وہ ترتیب نہیں جو آپ اتفاقاً کنٹرول کرنے والے دو endpoints پر چالو کرتے ہیں۔ بیرونی راستے کے ہر سوئچ، راؤٹر اور فراہم کنندہ کی حوالگی کو بڑے حجم پر متفق ہونا چاہیے، اور ایک ہی 1,500 بائٹ hop اُس پیکٹ کو خاموشی سے گرا دے گا جو آپ نے ابھی بڑا کیا۔ صرف مقامی انٹرفیس بڑھانا وہ کلاسک آدھی تبدیلی ہے جس سے ٹنل ٹوٹا ہوا دکھتا ہے جبکہ underlay خاموشی سے گراتا ہے۔

ip link set dev eth1 mtu 9000
ip link show dev eth1
ping -M do -s 8972 -c 2 198.51.100.10

انٹرفیس بدلیں، پھر کچھ اور بدلنے سے پہلے وہی راستہ دوبارہ جانچیں۔ اگر جانچ پھر بھی ناکام ہو، واپس کریں ip link set dev eth1 mtu 1500 اور اُس لنک کے بارے میں فراہم کنندہ سے بحث کرنے کی بجائے جو آپ کا نہیں، فریگمنٹیشن کی طرف جائیں۔

جب underlay بڑھ نہ سکے تو ٹنل فریگمنٹیشن استعمال کریں

اندرونی پیکٹ کے نیچے معاون فریگمنٹیشن طریقہ کار کئی بیرونی پیکٹوں کو ایک اندرونی پیکٹ لے جانے دیتا ہے، اور سامنے والا ٹنل endpoint اصل کو stack کو دینے سے پہلے اُنہیں دوبارہ جوڑ دیتا ہے۔ Community OpenVPN کا UDP fragment اختیار اُس خیال کی ایک تنفیذ ہے اور بیرونی پیکٹ کی عام IP فریگمنٹیشن جیسی چیز نہیں۔ دونوں peer کو اُس فارمیٹ کی معاونت کرنے والا ورژن چلانا ہوگا، اور ڈیٹا راستہ وہی ہونا چاہیے جو آپ سوچتے ہیں: OpenVPN 3 کلائنٹس اور kernel سے تیز کیے گئے ڈیٹا چینل کی حدیں مختلف ہیں، اس لیے ایک کلائنٹ پر چلنے والا پروفائل دوسرے پر ناکام ہو سکتا ہے۔

openvpn --config client.ovpn --tun-mtu 1500 --fragment 1400 --verb 4

عام بیرونی فریگمنٹیشن دوسرا اختیار ہے، اور وہ کمزور ہے۔ IPv6 راؤٹر آگے بھیجے گئے پیکٹ کو بالکل فریگمنٹ نہیں کرتے، اس لیے ضرورت سے بڑا بیرونی پیکٹ بس مر جاتا ہے اور بھیجنے والے کو صرف اُس وقت پتہ چلتا ہے جب متعلقہ ICMPv6 پیغام راستے پر بچ جائے۔ فریگمنٹ فلٹرنگ اور نقصان کی افزائش کو بھی دعوت دیتے ہیں، اس لیے میں اِسے منصوبہ نہیں بلکہ متبادل راستہ سمجھتا ہوں۔

بہاؤ پر مبنی بیرونی حامل اپنی بائٹ بہاؤ کو تقسیم کر کے حجم کا سوال چکا دیتا ہے، اور دوبارہ بنایا گیا اندرونی پیکٹ پھر بھی 1,500 بائٹ ہو سکتا ہے۔ یہ اپنی لاگت والا نقل و حمل کا فیصلہ ہے، بشمول TCP کے اندر TCP کے معروف رویے، اس لیے MTU بحث کے ضمنی اثر کے طور پر نہیں بلکہ جان بوجھ کر لیں۔

تصدیق کریں کہ اندرونی پیکٹ بغیر تبدیلی کے پہنچتا ہے

تصدیق کامیاب handshake نہیں ہے۔ دونوں سروں پر ٹنل انٹرفیس پر کیپچر کریں اور ایپلیکیشن نے جو پیکٹ واقعی بھیجا اُس کا حجم اور مواد دوسری طرف موصول ہونے والے سے موازنہ کریں۔

ip link show dev tun0
ping -M do -s 1472 -c 2 10.8.0.1
tcpdump -ni tun0 -c 5 'icmp and greater 1000'

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

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