ولې ستاسو د BGP غونډه د VPC په روټ جدول کې نه ښکاري

هغه کیسه چې تکراریږي دا ده چې په EC2 VPN وسیله کې د روټینګ ډیمون به د BGP په پورته کېدو سره VPC ته خپل لرې پریفیکسونه ورزده کړي. د دې نیمایي رښتیا ده. غونډه پورته کیږي، او د دې له امله د VPC د روټ جدول کې هېڅ نه بدلیږي، نو ځکه لومړنی نښه معمولاً هغه فرعي شبکه ده چې ترافیک په چوپتیا کې تورې سوري ته غورځوي.

دلته دوه بېلابېل شیان ګډېږي: د روټ سرور سره پیرنګ، او په جدول کې د روټونو نصبول.

افسانه: BGP پورته کړه او VPC به پریفیکسونه زده کړي

BGP د دوو ویندویانو ترمنځ خبرې اترې دي، او په دې ډیزاین کې ویندویان ستاسو د وسیلې روټینګ ډیمون او د VPC Route Server هغه پای ټکی دی چې AWS ستاسو په ملکیت کې د یوې فرعي شبکې په داخل کې ځای پرځای کوي. هغه خبرې اترې پریفیکسونه لېږدوي. دا ستاسو د کاري بار فرعي شبکو روټ جدول ته لاس نه ورکوي، ځکه هغه جدولونه یوازې د خپرېدو له لارې زده کوي چې باید په هر یو کې فعال شي. تر هغه چې دا ونه شي، د VPC ټوکر د وسیلې د پوهې په اړه هېڅ نه پوهیږي.

د تنظیم ګامونه د یو دلیل له امله جلا دي: وتړه، پای ټکی جوړ کړه، پیرنګ وکړه، بیا خپرېدل فعال کړه.

Route Server د کنټرول پلین دی، تونل نه دی

Route Server یو هم پاکټ نه کوډ کوي، نه لیږدوي او نه ګوري. دا د دې لپاره شته چې له وسیلې سره BGP تبادله کړي او ترلاسه شوي پریفیکسونه هغو روټ جدولونو ته ورکړي چې د هغو د ترلاسه کولو لپاره تنظیم شوي. د ډاټا پلین بدل شوی نه دی: پاکټونه لا هم د وسیلې د شبکې انټرفیس له لارې وځي، د هغې VPN ته سفر کوي او هماغه لار بیرته راځي.

دا مانا لري چې د لیږدونکې انسټانس په سر د سرچینې او منزل کتنه لا هم مهمه ده، ځکه انسټانس اوس هغه ترافیک لیږدوي چې بل چاته نښه شوی دی.

د امنیت ګروپونه او د فرعي شبکې کنټرولونه هم پر لیږدول شوي بهیر باندې تطبیقیږي. Route Server به هغه وسیله چې ترافیک غورځوي اړ نه کړي چې هغه ولیږدوي، او په لرې اړخ کې به ورکه شوې د بیرته راستنېدو لاره هم نه ترمیموي.

خپرېدل د هر روټ جدول لپاره دی، د ټول VPC لپاره نه

د روټ سرور له VPC سره تړل او په روټ جدول کې د خپرېدو فعالول دوه پرېکړې دي، او یوازې دوهمه هغه څه بدلوي چې یوه فرعي شبکه یې کوي. یو VPC چې شپږ روټ جدولونه لري کولی شي خپور شوی پریفیکس په یوه کې ترلاسه کړي او په نورو پنځو کې نه، چې د هب فرعي شبکې لپاره بالکل سم دی او بالکل هماغه شی دی چې د «نیم کار کوي» حیرانوونکې پایله رامنځته کوي. حتی چېرې چې خپرېدل فعال وي، یو سیال روټ کولی شي وګټي، ځکه د VPC روټ ټاکنه ترټولو اوږد پریفیکس غوره ګڼي او په مساوي اوږدوالي کې پر خپور شوي روټ باندې سټاټیک روټ غوره ګڼي. دا غوره توب په چوپتیا کې تطبیقیږي.

د وسیلې لخوا اعلان شوو پریفیکسونو لست پرځای د مشخصې فرعي شبکې اغیزمن جدول وګوره. API دې پوښتنې ته مستقیم ځواب ورکوي: aws ec2 associate-route-server او aws ec2 enable-route-server-propagation --route-table-id <id> هغه دوه ګامونه دي چې خلک یې هېروي، او aws ec2 describe-route-tables --route-table-ids <id> ښیي چې پریفیکس اصلاً د route server د ننوتنې په توګه راغلی که نه.

وسیله لا هم هر پاکټ لېږدوي

د رسیدو وړتیا اعلانول د هغې درلودو سره یو شان نه دي. د BGP غونډه کولی شي ټینګه پاتې شي پداسې حال کې چې د وسیلې VPN ښکته وي، او هغه سټاټیک اعلان چې هیڅکله نه بدلیږي ترافیک مړې لارې ته راکاږي. Route Server د BFD په څېر د نیمګړتیا کشف ملاتړ کوي، خو هغه د سیال ژوند توب ازموي، نه د هغه شاته هر څه روغتیا.

اعلان له ریښتینې لرې لارې سره وتړه: پریفیکس اعلان کړه کله چې تونل او لرې شبکه پورته وي، او کله چې نه وي بیرته یې واخله.

یو پریفیکس بیرته واخله او وګوره څه کیږي

په پړاوونو کې ازموینه وکړه، او وروستی پړاو حذف وګرځوه. ډاډه شه چې اعلان رسیږي، پریفیکس په هر هدف جدول کې ښکاري، وسیله بل هپ ده، لیږد فعال تونل تېریږي او لرې اړخ ځواب ورکوي. بیا یو ازموینه پریفیکس بیرته واخله، یا تصویب شوی تونل وتړه، او وګوره چې ترافیک هغه ځای ته ځي چې ډیزاین یې وایي. تر ازموینې پورې چې خلاصه ده، د مخکې او وروسته جدولونه ثبت کړه.

د یوې لارې بلې وسیلې ته لېږدول هغه غونډې نه لېږدوي چې هغه یې لېږدولې، ځکه د NAT او فایر وال حالت په لومړنۍ وسیله پاتې کیږي.

د دولسو پریفیکسونو د یو ټاکلي سیټ لپاره، په VPC جدولونو کې سټاټیک لارې ارزانه ځواب پاتې کیږي. Route Server خپل ځای هغه وخت ګټي کله چې د پریفیکسونو لست واقعاً بدلیږي او د بیرته اخیستنې پالیسي هغه څه وي چې تاسو کولی شئ د کال پر مهال د اړیکې مسؤل کس ته تشریح کړئ.