صفحهٔ Cloud Router مربوط به VPN را باز کنید و یک نشست BGP با آدرسی در 169.254.0.0/16 به شما خیره شده است. واکنش طبیعی این است که آن آدرس را جایی روی ماشین مجازی بگذارید و منتظر بالا آمدن نشست بمانید. این واکنش به شکلی مشخص نادرست است: این جفت به پیوند منطقی تعلق دارد که تونل IPsec می‌سازد، نه به رابط شبکهٔ معمولی ماشین. هر چیزی که به کارت شبکه اضافه کنید، تونل را وادار به حمل BGP نمی‌کند.

جفت را در پشته پایین پی بگیرید، به جای آنکه آن را روی میزبان اضافه کنید.

از جایی شروع کنید که کنسول جفت را نشان می‌دهد

صفحهٔ نشست یک آدرس BGP در Cloud Router و یک آدرس همتا را فهرست می‌کند که هر دو برای HA VPN از نوع IPv4 به صورت link-local هستند. کنار آن‌ها آدرس‌های دروازهٔ بیرونی قرار دارند که تونل‌ها را پایان می‌دهند. این‌ها اشیای متفاوتی هستند: جفت link-local درون زندگی می‌کند و آدرس‌های دروازه بیرون زندگی می‌کنند و پیش از کار کردن هر چیز دیگری باید قابل مسیریابی باشند.

پیش از باز کردن پروندهٔ پیکربندی، هر سه را بنویسید، چون اشتباه گرفتن آن‌ها همان کل حالت شکست است.

تا تونلی که آن را حمل می‌کند پایین بروید

جفت link-local تنها زمانی معنا پیدا می‌کند که یک انجمن امنیتی IPsec میان دو دروازه وجود داشته باشد. در سمت Google تونل‌های HA VPN آن را روی دو رابط می‌سازند؛ در سمت شما همان چیزی است که همتا مذاکره کرده است. نخست انجمن داده را با swanctl --list-sas بررسی کنید و بنویسید کدام تونل روی کدام رابط بالاست، چون نشست BGP سالم روی تونل مرده ناممکن است و تونل مرده با پیکربندی امیدوارانه امری معمول است.

بستهٔ BGP ترافیک IP درونی است. شبکهٔ بیرونی هرگز آن را نمی‌بیند، پس هیچ سوئیچی به هر دو آدرس روی یک VLAN نیاز ندارد.

اکنون همتای Linux را هم‌تراز پیکربندی کنید

طرح تونل پشتیبانی‌شده را برگزینید و بگذارید آدرس‌های درونی را تعیین کند. با رابط مبتنی بر مسیریابی، مدخل مسیریابی و انتخاب‌گرهای ترافیک مذاکره‌شده باید هم‌خوان باشند، چون نام رابط به‌تنهایی چیزی را مجاز نمی‌کند. BIRD را به آدرس محلی درونی و آدرس درونی Cloud Router اشاره دهید، شماره‌های AS را از صفحهٔ نشست تنظیم کنید و TCP 179 را درون مسیر محافظت‌شده مجاز کنید. مسیر به آدرس بیرونی دور را روی پیوند فیزیکی نگه دارید تا تونل ترابری خودش را نگیرد.

تونلی که خودش را مسیریابی می‌کند یک حلقه با دست‌دادن است و یک ساعت شبیه مشکل دیوار آتش به نظر می‌رسد.

هر مرحله را به ترتیب بررسی کنید، نه همه را یک‌جا

مراحل را بپیمایید: انجمن امنیتی بالا، همتای درونی از آدرس تونل قابل دسترسی، نشست BGP برقرار، پیشوندها پذیرفته و سپس یک پیشوند بار کاری که واقعاً استفاده شده است. birdc show protocols به پرسش سوم پاسخ می‌دهد و به هیچ چیز دیگری، و به همین دلیل افراد زود پیروزی اعلام می‌کنند.

همسایهٔ برقرارشده تضمین نمی‌کند که هر دو طرف پیشوندهای مورد نیاز شما را اعلام کرده باشند، یا اینکه آن مسیرها به‌عنوان ترجیحی نصب شده باشند.

اگر نشست برقرار است و ترافیک هنوز مسیر اشتباه را می‌گیرد، پیشوندهای اعلام‌شده را با کاری که جدول مسیریابی با آن‌ها می‌کند مقایسه کنید. یک مسیر مشخص‌تر در جای دیگر، یا ترجیحی برای مسیری دیگر، نشست BGP کارآمد و هیچ ارسال سودمندی به شما می‌دهد.

پیش از اعمال این روی Router Appliance توقف کنید

Network Connectivity Center Router Appliance مدل اتصال متفاوتی است. همتاهای Cloud Router آن از آدرس‌های درونی حاصل از چیدمان VPC و زیرشبکه استفاده می‌کنند، نه از جفت link-local مربوط به HA VPN. اگر هدف واقعی BGP با یک ماشین مجازی مسیریابی است، الزامات رابط آن محصول را پی بگیرید، نه کپی کردن یک نشست link-local.

دامنهٔ link-local هنوز همان معنایی را دارد که می‌گوید. تونل منطقی این همسایگی را فراهم می‌کند و مجوز مسیریابی مقصدهای دلخواه link-local در سراسر VPC را نمی‌دهد.

مقالات مرتبط