اعلانهای BGP از VGW در برابر جدول مسیرهای VPC: چه چیزی چه چیزی را تغییر میدهد
جدول مسیرهای VPC ارسال در زیرشبکهها را کنترل میکند؛ آنچه دروازه خصوصی مجازی از طریق BGP اعلام میکند را تغییر نمیدهد. هر جهت را جداگانه ردیابی کنید.
پیشوند گمشده در جدول مسیرهای یک زیرشبکه VPC و پیشوند گمشده روی روتر مشتری دو خرابی متفاوت هستند و فقط یکی از آنها داخل جدولهای مسیر AWS ترمیم میشود. دروازه خصوصی مجازی بلوکهای CIDR مرتبط با VPC خود را اعلام میکند؛ جدول مسیرهای زیرشبکه تعیین میکند که یک بار کاری پاسخ را کجا میفرستد. برخورد با دومی بهعنوان راهی برای تغییر اولی رایجترین پیچ اشتباه در این عیبیابی است. بررسیهای زیر را به ترتیب اجرا کنید و دو جهت را از هم جدا نگه دارید.
قبل از خواندن هر جدولی، نوع اتصال را نام ببرید
یک VPN سایت به سایت یا روی دروازه خصوصی مجازی یا روی دروازه ترانزیت پایان مییابد و شناسههای منبع تعیین میکنند که کدام مدل مسیریابی اعمال میشود. ابتدا آنها را بخوانید: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'. پاسخ به شما میگوید جدول بعدی که باید بررسی شود جدول مسیرهای VPC است یا جدول مسیرهای دروازه ترانزیت.
اگر VPN به دروازه ترانزیت متصل است، دست از رفتار با جدول مسیرهای VPC بهعنوان سطح کنترل بردارید. آنجا جدول VPC به اتصال دروازه اشاره میکند و انجمنسازی و انتشار در جدول مسیرهای دروازه ترانزیت رخ میدهند. آمیختن این دو دیدگاه نتیجههای مطمئن درباره شیء اشتباه تولید میکند.
جهت AWS به دفتر یک اعلان است
برای اتصال VGW، دروازه بلوکهای CIDR مرتبط با VPC خود را از طریق BGP به دروازه مشتری اعلام میکند. افزودن یک مسیر زیرشبکه جداگانه، یا اشاره دادن یک مسیر به VPC همتا یا به یک دستگاه، CIDR مرتبط دیگری اضافه نمیکند و در آن اعلان ظاهر نمیشود. اگر در دفتر پیشوندی کم است، پیش از ویرایش هر جدول مسیری، فهرست مسیرهای دریافتشده را با انجمنهای VPC مقایسه کنید.
قاعده ساده استثنا دارد، پس آن را در محدوده خودش نگه دارید. یک چیدمان VPN CloudHub میتواند پیشوندهای سایت را میان دروازههای مشتری دوباره اعلام کند و دروازه ترانزیت از قواعد انتشار خودش پیروی میکند. این گزاره که VGW فقط VPC خودش را اعلام میکند یک پیشفرض سودمند است، نه قانونی که هر توپولوژیای را که میبینید پوشش دهد.
جهت دفتر به AWS انتشار بهعلاوه انتخاب است
در جهت معکوس، VGW پیشوند دفتر را یاد میگیرد، اما این بهتنهایی بار کاری را جابهجا نمیکند. جدول مسیرهای زیرشبکه باید یا انتشار را برای اتصال فعال داشته باشد یا مسیری ایستا به همان مقصد داشته باشد. وقتی هر دو برای یک پیشوند وجود دارند، مسیر ایستا برنده میشود و تطبیق بلندترین پیشوند پیش از هر دوی آنها اجرا میشود.
مبدأ را بخوانید بهجای اینکه فرضش کنید: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'. ورودی با مبدأ EnableVgwRoutePropagation از BGP آمده است؛ ورودی با مبدأ CreateRoute را یک انسان تایپ کرده و تا کسی آن را حذف نکند برنده میماند.
یک رانبوک که دو جهت را جدا نگه میدارد
پیش از تغییر هر چیزی چهار واقعیت را در سمت AWS ثبت کنید: نوع اتصال، بلوکهای CIDR مرتبط VPC، مبدأ مسیر زیرشبکه برای پیشوند مورد بحث، و وضعیت تونل و BGP. همان فراخوانی describe مقدار VgwTelemetry را با شمار مسیرهای پذیرفتهشده در هر تونل برمیگرداند که به شما میگوید AWS اصلاً مسیری پذیرفته است یا نه. سپس آن را با آنچه دستگاه مشتری واقعاً نصب کرده مقایسه کنید. پیشوندی که در BGP هست اما در جدول ارسال نیست، مسئله درونریزی محلی یا بهترین مسیر است، نه مسئله جدول مسیرهای AWS.
اگر جدول زیرشبکه کاملاً پیشوند را ندارد، انتشار را فعال کنید یا مسیر ایستا بیفزایید، سپس همان پرسوجو را پس از بازه انتشار دوباره بخوانید بهجای اینکه فرض کنید تغییر فوری بوده است. اگر پیشوند وجود دارد و ترافیک هنوز شکست میخورد، سطح کنترل را رها کنید و به مسیر داده بروید.
چه چیزی را در آنجا تغییر ندهید
برای رفع یک پیشوند گمشده، انتشار را روی جدولهای مسیر بیربط روشن یا خاموش نکنید، و برای پوشاندن یک CIDR غایب مسیر پیشفرض اضافه نکنید. هر دو تغییر دامنه اثر را گستردهتر و عیبیابی بعدی را سختتر میکنند. ویرایش را به جدولی محدود کنید که به زیرشبکه بار کاری مورد بحث خدمت میکند.
مسیر داده از همه اینها جداست. گروههای امنیتی حالتدار هستند و ACLهای شبکه نیستند، و یک فایروال میزبان یا مسیر بازگشت نامتقارن میتواند ترافیکی را که مسیریابی درست تحویل داده است بیندازد. یک تجمیع اعلامشده هم هر سرویس درونش را مجاز نمیکند، پس دسترسی را در مرز سیاست محدود کنید بهجای تکیه بر اینکه نشانی تصادفاً در یک اعلان BGP ظاهر میشود یا نه.
وضعیت پیش و پس از هر پرسوجوی جدول مسیر را در سابقه تغییرات نگه دارید. اگر تغییر اوضاع را بدتر کرد، مسیرهای پیشین را بازگردانید و با همان پرسوجو تأیید کنید، زیرا بازگشتی که نمیتوانید بررسی کنید فقط یک حدس است.