مسیریابی ترافیک بین دو شعبه از طریق یک دروازه VPN در Azure
دو اتصال سایت به سایت روی یک دروازه VPN در Azure می‌توانند ترافیک شعبه‌ها را عبور دهند، اما تنها زمانی که هر دو طرف پیشوند را یاد بگیرند و مسیر بازگشت در LAN وجود داشته باشد.
دو شعبه می‌توانند ترافیک را از طریق یک دروازه VPN در Azure و بدون هیچ تونل مستقیمی بین خودشان مبادله کنند. هر شعبه یک اتصال سایت به سایت به همان دروازه باز می‌کند، و دروازه پیشوندهای آموخته‌شده را بین دو اتصال منتقل می‌کند. چیزی که این کار را ممکن می‌کند تونل دوم نیست، بلکه تبادل مسیر است: شعبه A باید پیشوند شعبه B را یاد بگیرد و B باید پیشوند A را یاد بگیرد. بررسی‌های زیر را به ترتیب انجام دهید و در اولین بررسی که شکست می‌خورد متوقف شوید، چون هر گام بعدی به آن وابسته است.
پیش‌شرط‌ها، پیش از آنکه چیزی را پیکربندی کنید
چهار شرط تعیین می‌کند که این طراحی اصلاً می‌تواند کار کند یا نه. دروازه باید مبتنی بر مسیر باشد و روی SKUای باشد که BGP را پشتیبانی می‌کند، هر دو اتصال باید BGP فعال داشته باشند، فضاهای نشانی شعبه‌ها نباید همپوشانی داشته باشند، و هیچ طرفی نباید به NAT اتکا کند تا پیشوند واقعی خود را پنهان کند.
ASNها را آگاهانه برنامه‌ریزی کنید. مقدار پیش‌فرض مستند Azure برابر 65515 است، و هر مسیریاب شعبه به ASN خصوصی خودش نیاز دارد که با دروازه یا شعبه دیگر برخورد نکند. استفاده مجدد از یک مقدار پیش‌فرض بدون بررسی پیکربندی موجود دروازه همان روشی است که بعداً یک مسیر AS رد می‌شود.
همچنین مطمئن شوید که انتظار رفتار همتا‌سازی VNet را ندارید. دروازه مسیرها را بین دو اتصالی که پیکربندی کرده‌اید مبادله می‌کند؛ این کار همتا‌سازی‌های دلخواه را گذرا نمی‌کند. اگر شبکه سومی باید به هر دو شعبه برسد، به اتصال خودش یا مسیر خودش نیاز دارد، نه این فرض که دروازه ترافیک را پخش می‌کند. این مرز را پیش از اولین پنجره تغییر بنویسید، چون همان تصمیم طراحی است که مردم هنگام افزودن یک سایت بعدی به آن بازمی‌گردند.
به این ترتیب پیکربندی کنید
هر گام یک نتیجه قابل مشاهده دارد، پس تا زمانی که ظاهر نشود جلو نروید.
- BGP را روی دروازه شبکه مجازی فعال کنید و ASN و نشانی همتای آن را یادداشت کنید.
- برای هر شعبه یک دروازه شبکه محلی با فضای نشانی واقعی همان شعبه، ASN آن و نشانی همتای BGP آن بسازید.
- هر اتصال سایت به سایت را بسازید و BGP را روی خود اتصال فعال کنید.
- مسیریاب شعبه را طوری پیکربندی کنید که با نشانی دروازه‌ای که Azure تعیین کرده همتا شود، نه با نقطه پایانی عمومی IKE دروازه بر اساس فرض.
گام چهارم جایی است که بیشتر تلاش‌ها متوقف می‌شوند. نشانی همتای BGP که Azure گزارش می‌کند همانی است که مسیریاب شعبه باید به عنوان همسایه استفاده کند، و همیشه نشانی نیست که مردم از نمودار تونل انتظار دارند.
خود پیشوند شعبه را اعلام کنید، برای مثال 10.10.0.0/16 از A و 10.20.0.0/16 از B. مسیر پیش‌فرض یا تجمیع گسترده‌ای را برای پوشش یک شبکه مشخص جاافتاده اعلام نکنید؛ شکاف بعداً به شکل یک چاله سیاه خاموش بازمی‌گردد.
تبادل مسیر را در هر دو سر بررسی کنید
وضعیت اتصال بررسی نیست. IPsec می‌تواند روی هر دو اتصال برقرار باشد در حالی که هیچ پیشوندی بین آن‌ها عبور نمی‌کند. همتاهای BGP دروازه و مسیرهای آموخته‌شده آن را بخوانید، سپس تأیید کنید که مسیر به سمت شعبه دیگر به عنوان یک مسیر قابل استفاده ظاهر می‌شود.
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
پیشوندی که در جدول BGP وجود دارد هنوز می‌تواند تصمیم ارسال را به یک مسیر ایستا یا پیشوند مشخص‌تر واگذار کند. مسیر انتخاب‌شده را بررسی کنید، نه فقط مسیر دریافت‌شده را.
مسیر بازگشت را در سمت LAN دنبال کنید
این همان بخشی است که در Azure درست به نظر می‌رسد و در محل شکست می‌خورد. یک میزبان در شعبه A بسته خود را تنها زمانی به مسیریاب VPN شعبه A می‌فرستد که آن مسیریاب دروازه پیش‌فرضش باشد، یا میزبان یا دروازه‌اش مسیری برای پیشوند B داشته باشد. همین باید در جهت مخالف هم درست باشد.
اگر یک سوئیچ هسته جداگانه دروازه پیش‌فرض LAN باشد، به مسیری به سمت شعبه دیگر نیاز دارد که به مسیریاب VPN اشاره کند. بدون آن، درخواست می‌رسد و پاسخ از مسیر اینترنت خارج می‌شود، و کاربر اتصالی می‌بیند که باز می‌شود و سپس معلق می‌ماند.
برای رفع این مشکل به گروه امنیت شبکه روی زیرشبکه دروازه متوسل نشوید. آن زیرشبکه الزامات خودش را دارد و یک NSG در آنجا جایگزین پشتیبانی‌شده‌ای برای سیاست سمت شعبه نیست. فیلترکردن به دیوارهای آتش شعبه‌ها و به خود بارهای کاری تعلق دارد، جایی که قواعد را مالکانشان می‌توانند بازبینی کنند. انتقال این قواعد به NSG زیرشبکه آن‌ها را از تیمی که خرابی بعدی را اشکال‌زدایی می‌کند نیز پنهان می‌کند.
عملیات را مجاز کنید، سپس آن را با یک آزمون ردشده اثبات کنید
مسیر آموخته‌شده مجوز نیست. مبدأ، مقصد و سرویسی را که واقعاً نیاز دارید از طریق دیوارهای آتش شعبه‌ها و سیاست نقطه پایانی مجاز کنید، و بقیه را ردشده بگذارید.
از یک بار کاری معمولی در شعبه A به یک سرویس واقعی در شعبه B آزمایش کنید، پاسخ را تأیید کنید، سپس عملیاتی را امتحان کنید که باید ممنوع بماند. ترافیکی که خود دستگاه VPN تولید می‌کند می‌تواند از نشانی مبدأ متفاوتی استفاده کند و مرحله مسیریابی LAN را رد کند، بنابراین یک ping موفق از مسیریاب کمتر از آنچه به نظر می‌رسد اثبات می‌کند.
با نوشتن چهار واقعیت پایان دهید: پیشوندهای مبادله‌شده، ASNهای در استفاده، مسیر بازگشت LAN برای هر طرف، و سیاستی که سرویس را مجاز می‌کند. اگر یکی از آن‌ها نباشد، پیکربندی تا اولین تغییر کار می‌کند و سپس هیچ‌کس نمی‌تواند توضیح دهد چرا.