VPN پر BGP آپ کے انڈرلے راستے کو کیوں کنٹرول نہیں کرتا
VPN پر BGP رسائی کی صلاحیت کا تبادلہ کرتا ہے اور راستہ پالیسی لاگو کرتا ہے، لیکن انڈرلے اب بھی بیرونی راستہ منتخب کرتا ہے۔ سیشن واقعی کیا کنٹرول کرتا ہے۔
دو سائٹس IPsec سرنگ پر BGP پیئر کرتی ہیں، ایک دوسرے کے سابقے سیکھتی ہیں، اور ڈایاگرام کو راستہ کنٹرول کا نام دے دیا جاتا ہے۔ یہی لیبل الجھن کا آغاز ہے۔ سیشن رسائی کی صلاحیت کا تبادلہ کرتا ہے اور پالیسی بھی لاگو کرتا ہے، لیکن کون سا فراہم کنندہ، کیبل یا راؤٹر خفیہ شدہ پیکٹ لے کر جاتا ہے، اس پر اس کی کوئی رائے نہیں۔ میں نے ایک ٹیم کو کام کرتی سرنگ دوبارہ تعمیر کرتے دیکھا ہے، کیونکہ انہیں توقع تھی کہ BGP راستے کی تبدیلی ٹریفک کو کسی دوسرے فائبر راستے پر منتقل کرے گی جس پر سیشن کبھی اثر نہیں ڈال سکتا تھا۔
لوگ کیا سمجھتے ہیں کہ سیشن کیا خریدتا ہے
زیادہ تر توقع اس سے آتی ہے کہ لیبارٹری میں راستے کی تبدیلی کیسی دکھتی ہے۔ آپ سرنگ پر سابقہ اعلان کرتے ہیں، دور والا فریق اسے نصب کرتا ہے، اور ٹریفک حرکت کرتی ہے۔ یہی ترتیب ایسے راؤٹر پر بھی ہوتی ہے جس میں واقعی ٹریفک انجینئرنگ کے کنٹرول ہوں، اس لیے دونوں گڈمڈ ہو جاتے ہیں۔ لیبارٹری میں دونوں سائٹس عام طور پر ایک ہی رسائی لنک بانٹتی ہیں، اور اسی لیے فرق وہاں کبھی ظاہر نہیں ہوتا۔
BGP رسائی کی صلاحیت کا پروٹوکول ہے۔ یہ پیئر کو بتاتا ہے کہ آپ سابقے کے لیے پیکٹ پہنچا سکتے ہیں اور ہر فریق کو موصول پیشکشوں کی ترتیب دینے دیتا ہے۔ سرنگ کے ذریعے یہ واقعی مفید ہے: سائٹس آتے جاتے وقت سابقے ظاہر اور غائب ہوتے ہیں، اور آپ ہر کنارے کے آلے پر جامد راستہ لکھے بغیر کوئی حد مسترد کر سکتے ہیں۔ جو یہ نہیں کرتا وہ فراہم کنندہ کے راؤٹروں کو آپ کے کنٹرول میں لانا ہے۔
انڈرلے بیرونی ہیڈر اٹھاتا ہے۔ آپ کا سرنگ اینڈ پوائنٹ خفیہ شدہ پیکٹ پیئر کے پتے پر بھیجتا ہے، اور ان دو پتوں کے درمیان نیٹ ورک انہیں ان راستوں سے آگے بھیجتا ہے جو اس کے آپریٹرز نے نصب کیے ہیں۔ BGP سیشن میں کچھ بھی اس فیصلے کو نہیں بدلتا، جب تک وہی فراہم کنندہ ایسی معاون سروس پیش نہ کرے جو یہ کرتی ہو۔
سیشن واقعی کیا اٹھاتا ہے
BGP بولنے والا اپنے پیئر کے 179 پورٹ پر TCP رابطہ کھولتا ہے، RFC 4271 میں بیان کردہ پیغام کی شکلیں اور راستے کی خصوصیات استعمال کرتے ہوئے۔ جب پیئر کا پتہ سرنگ کے اندر ہو، تو سیشن شروع ہونے سے پہلے سرنگ اوپر اور وہ پتہ قابل رسائی ہونا چاہیے۔ مکمل شدہ IKE تبادلہ BGP ہمسایہ نہیں ہے۔ راستے پر مبنی IPsec نفاذ صرف اس وقت ٹریفک گزرنے دیتے ہیں جب مماثل سرنگ راستہ موجود ہو، اور پالیسی پر مبنی کو محفوظ منتخب کنندہ کے اندر پیئر کا پتہ درکار ہوتا ہے۔ اسے الٹا کرنے سے وہ کلاسک حالت بنتی ہے جس میں سرنگ سبز ہے اور سیشن بیکار بیٹھا ہے۔
سیشن اوپر آنے کے بعد پالیسی طے کرتی ہے کہ اسے کیا عبور کرتا ہے۔ سابقہ فہرستیں، AS-راستہ فلٹر، زیادہ سے زیادہ سابقوں کی حد اور ڈیفالٹ راستوں کے بارے میں واضح فیصلہ کم از کم ہیں، اور وہ دونوں سمتوں پر لاگو ہوتے ہیں۔ جو ملے وہ سب قبول کرنے والا پیئر آپ کو ایسا ڈیفالٹ راستہ دے سکتا ہے جو مقامی انٹرنیٹ رسائی کو خاموشی سے بدل دے۔ دونوں سمتوں کے لیے الگ فہرستیں چاہئیں، کیونکہ پیئر سے آپ جو قبول کرتے ہیں اور اسے جو اعلان کرتے ہیں وہ دو مختلف فیصلے ہیں۔
router bgp 65010
neighbor 10.255.0.2 remote-as 65020
address-family ipv4 unicast
neighbor 10.255.0.2 prefix-list SITE-B-IN in
neighbor 10.255.0.2 prefix-list SITE-B-OUT out
neighbor 10.255.0.2 maximum-prefix 50
پھر MTU کاٹتا ہے۔ انکیپسولیشن مفید پے لوڈ کم کرتا ہے، اس لیے بڑی اپ ڈیٹ مکمل طور پر قائم دکھائی دینے والا سیشن روک سکتی ہے: پیئر اوپر رہتا ہے، سابقے کبھی نہیں آتے، اور لاگ میں کوئی واضح چیز نہیں گرتی۔ فلٹروں کو الزام دینے سے پہلے سرنگ انٹرفیس پر TCP MSS محدود کریں، یا اوور ہیڈ کے لیے جگہ رکھ کر سرنگ MTU مقرر کریں۔
بیرونی پیکٹ اب بھی کہاں جاتے ہیں
ایک سائٹ سے دوسری تک خفیہ شدہ پیکٹ اس راستے سے نکلتے ہیں جو مقامی راؤٹر پیئر کے عوامی پتے کے لیے منتخب کرتا ہے۔ اگر دونوں سائٹس ایک ہی فراہم کنندہ سے ٹرانزٹ خریدتی ہیں، ایک ہی میٹرو سہولت سے گزرتی ہیں، یا ایک فریق کیریئر گریڈ NAT کے پیچھے ہے، تو سرنگ فراہم کنندہ کی ناکامی سے صرف اتفاقاً بچتی ہے۔ نگرانی کے آلے میں سرنگ کے آئیکن گننا اس بارے میں آپ کو کچھ نہیں بتاتا۔
راستے کا انتخاب اور فارورڈنگ کی تنصیب بھی الگ واقعات ہیں۔ سابقہ BGP جدول میں بہترین کے طور پر بیٹھ سکتا ہے اور پھر بھی فارورڈنگ جدول سے غائب ہو سکتا ہے، کیونکہ اگلا ہاپ حل نہیں ہوتا یا زیادہ مخصوص راستہ جیت جاتا ہے۔ جب کوئی بتائے کہ BGP نے سابقہ سیکھا لیکن ٹریفک نہیں بہتی، تو مفید سوال یہ ہے کہ آیا یہ نصب ہے اور کس اگلے ہاپ کی طرف اشارہ کرتا ہے۔
ڈیزائن کے جائزے کے لیے دیانت دار جواب مشترکہ انحصار کی فہرست ہے: رسائی سرکٹ، اوپری فراہم کنندہ، سہولت اور واپسی راستے پر کوئی بھی حالت رکھنے والا آلہ۔ سرنگ کے ذریعے سیشن اس انحصار کو نہیں ہٹا سکتا جس پر وہ خود نہیں بیٹھا۔
الگ کرنے کے قابل تین فیصلے
جب ڈیزائن انہیں ملا دیتا ہے، تو ہر خرابی کی گفتگو دائرے میں گھومتی ہے۔ پہلے انہیں کاغذ پر الگ کریں، پھر ہر ایک کو اس آلے سے جوڑیں جو واقعی اسے نافذ کرتا ہے۔
| Decision | Who controls it | Typical failure |
|---|---|---|
| Which prefixes may cross the relationship? | Both sides, through prefix and AS-path policy you configure deliberately | A default route accepted by mistake, or a vague aggregate |
| Which overlay next hop wins? | Local BGP selection plus next-hop resolution on your own routers | Prefix learned, never installed in the forwarding table |
| Where do the encrypted packets travel? | The underlay operators, unless a supported service adds real control | Path diversity that was never there |
ہر قطار کا مالک مختلف ہے۔ پہلی گفت و شنید ہے، دوسری آپ کے آلات پر ترتیب ہے، تیسری زیادہ تر کسی اور کا نیٹ ورک ہے۔ جو تبدیلی کی درخواست اپنی چھونے والی قطار کا نام لے، اس کی منظوری BGP مسئلہ کہنے والی درخواست سے کہیں آسان ہے۔
منصوبہ بندی کے قابل ناکامی کی صورتیں
پیئر کے خلاصہ راستے کو قبول کرنا سب سے عام خود کو لگایا گیا زخم ہے۔ کوئی تبادلے کو آسان بنانے کے لیے مختصر مجموعہ اعلان کرتا ہے، دور والا فریق اسے قبول کرتا ہے، اور سرنگ کے پیچھے نہ ہونے والی حدود کی ٹریفک سرنگ کی پیروی کر کے مر جاتی ہے۔ بالکل متوقع سابقوں پر فلٹر کریں، یا درست حدود والی سابقہ فہرست استعمال کریں، اور کبھی ننگا مجموعہ قبول نہ کریں کیونکہ یہ سیشن کو صاف دکھاتا ہے۔
واپس لینے کا وقت دوسرا ہے۔ شناخت ہولڈ ٹائمر، آپ نے فعال کیا ہو تو BFD، سرنگ کی مردہ پیئر شناخت اور دور والا فریق کتنی تیزی سے اعلان بند کرتا ہے، پر منحصر ہے۔ موجودہ سیشن الگ مسئلہ ہیں: نیا راستہ نئے روابط بحال کر سکتا ہے، لیکن قائم شدہ TCP سیشن پرانے پتے استعمال کرتے رہتے ہیں، اور راستے میں حالت رکھنے والے فائر وال یا NAT اب نہ ملنے والی اندراجات رکھ سکتے ہیں۔ راستے کی تبدیلی سب کچھ حل کر دے گی سمجھنے کے بجائے ایپلیکیشن کی بحالی کو قبولیت کے معیار میں رکھیں۔
تیسری ہے واپسی راستے کی عدم مساوات۔ ٹریفک سرنگ سے آ سکتی ہے اور اسے اٹھانے کے لیے کبھی نہ بنائے گئے فراہم کنندہ لنک سے واپس جا سکتی ہے، جو یک طرفہ آڈیو، ناکام مصافحہ یا جوابات پھینکنے والے فائر وال کے طور پر ظاہر ہوتی ہے۔ دونوں سمتوں کو الگ الگ جانچیں۔
معاہدے میں کیا لکھنا ہے، اور اسے کیسے جانچنا ہے
اجازت شدہ سابقے تحریری طور پر مانگیں: ہر حد بنانے کا اختیار کس کو ہے، ڈیفالٹ راستہ اجازت ہے یا نہیں، اور سرنگ سروس کون سے پتہ خاندانوں کی معاونت کرتی ہے۔ RFC 8212 نے اس کی پیروی کرنے والے نفاذ میں eBGP کے لیے واضح درآمد اور برآمد پالیسی کو توقع بنا دیا، اس لیے اب بھی پوشیدہ سب قبول کرنے والے رویے پر انحصار کرنے والا پیئر پوچھنے کے قابل ہے۔
پھر ڈایاگرام کی بجائے آلے سے جانچیں۔ FRR طرز کے راؤٹروں پر مفید کمانڈیں:
show bgp summary
show bgp ipv4 unicast 10.10.0.0/16
show bgp ipv4 unicast neighbors 10.255.0.2 advertised-routes
show ip route 10.10.0.0/16
دو مشاہدے شامل کریں جو راستہ جدول آپ کو نہیں دے سکتا۔ یہ تصدیق کرنے کے لیے کہ انکیپسول شدہ پیکٹ واقعی کس پتے کو نشانہ بناتے ہیں، بیرونی انٹرفیس پر گرفت کریں، مثلاً tcpdump -ni eth0 udp port 51820 WireGuard سرنگ کے لیے، یا IPsec کے لیے ESP فلٹر۔ پھر پیئر کے عوامی پتے کی طرف سراغ لگائیں اور ہاپس کا سرنگ کے اندر کے سراغ سے موازنہ کریں؛ اگر دونوں ایک ہی فراہم کنندہ زنجیر کی پیروی کریں، تو آپ کی فالتو صلاحیت نیٹ ورک میں نہیں، راستہ پالیسی میں رہتی ہے۔
آخر میں، جان بوجھ کر واپس لینے کی جانچ کریں۔ دیکھ بھال کی ونڈو میں سرنگ نیچے کریں، ریکارڈ کریں کہ سابقہ کتنی دیر نصب رہتا ہے، موجودہ سیشنوں کو کیا ہوتا ہے اور دور والا فریق کیا واقعی ایسے راستے پر واپس آتا ہے جسے آپ قبول کریں گے۔ وہ مشق کسی بھی ڈایاگرام سے زیادہ ڈیزائن کے بارے میں بتاتی ہے۔
راستہ اجازت نہیں ہے۔ جن سابقوں کا تبادلہ آپ طے کرتے ہیں وہ اس بارے میں کچھ نہیں بتاتے کہ کون سے صارفین سرنگ کے پیچھے کون سی سروس تک پہنچ سکتے ہیں، اس لیے تصدیق، اجازت شدہ سروسز اور میزبان فائر وال وہیں رکھیں جہاں تھے۔ قابل رسائی پیئر بھی لامحدود ٹرانزٹ یا من مانی پتے بنانے کی اجازت نہیں ہے، اور ایسا اختیار BGP پالیسی سطر میں نہیں، معاہدے میں تجارتی سوال کے طور پر ہونا چاہیے۔
- ہر فریق کون سے سابقے بنا سکتا ہے اور کون سے کبھی قبول نہیں کرنے چاہئیں، ان کے نام لیں۔
- سرنگ پر MSS محدود کریں اور تصدیق کریں کہ بڑی اپ ڈیٹ واقعی پہنچتی ہیں۔
- مشترکہ انڈرلے انحصار کی فہرست دیں، سرنگوں کی تعداد نہیں۔
- حقیقی واپس لینے کا وقت ناپیں اور ریکارڈ کریں کہ ایپلیکیشن کیا کرتی ہے۔