ولې د VPN پر سر BGP ستاسو د لاندې طبقې لاره نه کنټرولوي
د VPN پر سر BGP د رسیدو وړتیا تبادله کوي او د لارې پالیسي پلي کوي، خو لاندې طبقه بیا هم بهرنۍ لاره غوره کوي. سیشن واقعاً څه کنټرولوي.
دوه سایټونه د IPsec تونل له لارې BGP peer کوي، د یو بل مخکښې زده کوي، او ډیاګرام د لارې کنټرول په توګه بیا لیبل کیږي۔ همدا لیبل د ګډوډۍ پیل دی۔ سیشن د رسیدو وړتیا تبادله کوي او پالیسي پلي کوي، خو دا چې کوم عرضه کوونکی، کیبل یا روټر کوډ شوي پیکټونه وړي، په دې کې یې ویل نلري۔ ما یوه ټیم لیدلی چې یو فعال تونل یې بیا جوړاوه، ځکه دوی تمه درلوده چې د BGP لارې بدلون به ترافیک هغې بلې فایبر لارې ته انتقال کړي چې سیشن هیڅکله پرې اغیزه نشي کولی۔
خلک څه فکر کوي چې سیشن یې اخلي
د تمې ډیره برخه له دې څخه راځي چې په لابراتوار کې د لارې بدلون څنګه ښکاري۔ تاسو د تونل له لارې یو مخکښ اعلان کوئ، لرې اړخ یې نصبوي، او ترافیک ځي۔ همدا ترتیب په هغه روټر کې هم پیښیږي چې واقعاً د ترافیک انجینرۍ کنټرولونه لري، نو دواړه سره ګډیږي۔ په لابراتوار کې دواړه سایټونه معمولاً یوه لاسرسي لینک شریکوي، او همدا لامل دی چې توپیر هلته هیڅکله نه ښکاري۔
BGP د رسیدو وړتیا پروتوکول دی۔ دا peer ته وایي چې تاسو د یو مخکښ لپاره پیکټونه رسولی شئ او هر اړخ ته اجازه ورکوي چې ترلاسه شوې وړاندیزونه ترتیب کړي۔ دا د تونل له لارې واقعاً ګټور دی: سایټونه چې کله راځي او ځي، مخکښې ښکاري او ورکیږي، او تاسو کولی شئ یوه ساحه رد کړئ پرته له دې چې په هر څنډې وسیله کې سټاتیک لاره ولیکئ۔ کوم شی چې دا نه کوي، هغه دا دی چې د عرضه کوونکي روټرونه ستاسو تر کنټرول لاندې راولي۔
لاندې طبقه بهرنۍ سرلیک وړي۔ ستاسو د تونل پای ټکی کوډ شوي پیکټونه peer آدرس ته لیږي، او د هغو دوو آدرسونو ترمنځ شبکه د هغو لارو له مخې چې د هغې آپریټرانو نصب کړي، هغه مخ ته لیږدوي۔ د BGP سیشن کې هیڅ شی هغه پرېکړه نه بدلوي، پرته له دې چې هماغه عرضه کوونکی داسې ملاتړ شوې خدمت وړاندې کړي چې دا کار کوي۔
سیشن واقعاً څه وړي
د BGP ویناوال د خپل peer په 179 پورټ کې TCP اړیکه پرانیزي، RFC 4271 کې تعریف شوي پیغام بڼې او د لارې ځانګړتیاوې کاروي۔ کله چې peer آدرس د تونل دننه وي، سیشن له پیلیدو مخکې باید تونل پورته وي او هغه آدرس د رسیدو وړ وي۔ بشپړ شوی IKE تبادله BGP ګاونډی نه دی۔ د لارې پر بنسټ IPsec تطبیقونه یوازې هغه وخت ترافیک تیروي چې سمونکې تونل لاره شتون ولري، او د پالیسۍ پر بنسټ یې په خوندي ټاکونکي کې د peer آدرس ته اړتیا لري۔ دا په برعکس کول هغه کلاسیک حالت جوړوي چې تونل شین وي او سیشن بېکاره ناست وي۔
کله چې سیشن پورته شي، پالیسي پرېکړه کوي چې څه ترې تیریږي۔ د مخکښو لیستونه، د AS-لارې فلټرونه، د اعظمي مخکښو حد او د ډیفالټ لارو په اړه روښانه پرېکړه لږترلږه دي، او په دواړو لورو پلي کیږي۔ هغه peer چې هر څه چې ترلاسه کوي مني، کولی شي تاسو ته داسې ډیفالټ لاره درکړي چې ځایي انټرنیټ لاسرسی په چوپتیا بدلوي۔ دواړو لورو ته جلا لیستونه ته اړتیا ده، ځکه چې له peer څخه څه منئ او هغه ته څه اعلانوئ، دوه جلا پرېکړې دي۔
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 چیچي۔ انکپسولیشن ګټور بار کموي، نو لوی تازه کول کولی شي هغه سیشن ودروي چې بشپړ تاسیس شوی ښکاري: peer پورته پاتې کیږي، مخکښې هیڅکله نه رسیږي، او په لاګ کې څه روښانه نه لویږي۔ مخکې له دې چې فلټرونه ملامت کړئ، په تونل انټرفیس کې TCP MSS محدود کړئ، یا د اضافي لګښت لپاره ځای سره تونل MTU وټاکئ۔
بهرني پیکټونه بیا هم چیرته ځي
له یوه سایټ څخه بل ته کوډ شوي پیکټونه د هغه لارې له مخې وځي چې ځایي روټر د peer عامه آدرس لپاره غوره کوي۔ که دواړه سایټونه له یوې عرضه کوونکي څخه ټرانسټ اخلي، یوه میټرو اسانتیا تیریږي، یا یو اړخ د کیریر کچې 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 ستونزه وایي، ډیر اسانه تصویب کیږي۔
د پلان کولو وړ ناکامۍ بڼې
د peer د لنډیز لاره منل ترټولو عامه خپله جوړه شوې زخم دی۔ څوک د تبادلې ساده کولو لپاره لنډه ګډه اعلانوي، لرې اړخ یې مني، او د هغو ساحو ترافیک چې د تونل شاته نه دي د تونل تعقیبوي او مري۔ یوازې د تمه شوو مخکښو له مخې فلټر کړئ، یا د سم حدود سره د مخکښو لیست وکاروئ، او هیڅکله لوڅه ګډه مه منئ ځکه چې سیشن منظم ښکاري۔
د بیرته اخیستنې وخت دویم دی۔ پیژندنه د هولډ ټایمرونو، BFD که یې فعال کړی وي، د تونل د مړ peer پیژندنې او د دې چې لرې اړخ څومره ژر اعلان بندوي، پورې تړلې ده۔ شته سیشنونه جلا ستونزه ده: نوې لاره کولی شي نوي اړیکې بیرته راولي، خو تاسیس شوي TCP سیشنونه لا هم زاړه آدرسونه کاروي، او په لاره کې حالت ساتونکي فایر والونه یا NAT کولی شي هغه ننوتنې وساتي چې نور نه سمونږي۔ د دې پرځای چې فکر وکړئ د لارې بدلون هر څه حل کوي، د اپلیکیشن بیرته راوستل د منلو معیارونو کې کیږدئ۔
دریمه د بیرته راستنیدو لارې ناهمغږي ده۔ ترافیک کولی شي د تونل له لارې راشي او د هغې عرضه کوونکي لینک له لارې بیرته لاړ شي چې هیڅکله د هغې د وړلو لپاره نه وه ټاکل شوې، کوم چې د یوې خوا غږ، ناکام لاس ورکول یا د ځوابونو غورځوونکي فایر وال په بڼه ښکاري۔ دواړه لوري جلا وګورئ۔
په تړون کې څه ولیکو، او څنګه یې تایید کړو
اجازه شوې مخکښې په لیکلي ډول وغواړئ: څوک د هرې ساحې د جوړولو واک لري، ایا ډیفالټ لاره اجازه لري، او تونل خدمت کوم د آدرس کورنۍ ملاتړ کوي۔ RFC 8212 هغو تطبیقونو کې چې ورپسې ځي، eBGP لپاره روښانه واردات او صادرات پالیسي د تمې وړ وګرځوله، نو هغه peer چې لا هم پټ هر څه منلو چلند ته تکیه کوي، د پوښتنې وړ دی۔
بیا د ډیاګرام پرځای له وسیلې څخه تایید کړئ۔ د 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 فلټر۔ بیا د peer عامه آدرس په لور تعقیب کړئ او ټوپونه د تونل دننه تعقیب سره پرتله کړئ؛ که دواړه یوې عرضه کوونکې زنځیر تعقیبوي، ستاسو اضافي والی په شبکه کې نه، بلکې په لارې پالیسي کې ژوند کوي۔
په پای کې، په قصد سره د بیرته اخیستنې ازموینه وکړئ۔ د ساتنې وینډو په جریان کې تونل ښکته کړئ، ثبت کړئ چې مخکښ څومره وخت نصب پاتې کیږي، شته سیشنونو سره څه کیږي او لرې اړخ هغې لارې ته بیرته راځي چې تاسو به واقعاً منلې وای۔ هغه تمرین د هر ډیاګرام څخه د ډیزاین په اړه ډیر څه وایي۔
لاره اجازه نه ده۔ هغه مخکښې چې د تبادلې لپاره یې موافق یاست، د دې په اړه هیڅ نه وایي چې کوم کاروونکي د تونل شاته کوم خدمت ته رسیږي، نو تصدیق، اجازه شوې خدمتونه او د کوربه فایر والونه سم هغه ځای کې وساتئ چې وو۔ د رسیدو وړ peer هم د نامحدود ټرانسټ یا د خپل سر آدرسونو جوړولو اجازه نه ده، او داسې واک په BGP پالیسي کرښه کې نه، بلکې په تړون کې د سوداګریزې پوښتنې په توګه ځای لري۔
- هغه مخکښې ونوموئ چې هره خوا یې جوړولی شي، او هغه چې هیڅکله یې نه باید ومني۔
- په تونل کې MSS محدود کړئ او تایید کړئ چې لوی تازه کول واقعاً رسیږي۔
- شریکې لاندې طبقې انحصارونه لیست کړئ، نه د تونلونو شمیر۔
- د بیرته اخیستنې واقعي وخت وټاکئ او یادداشت کړئ چې اپلیکیشن څه کوي۔