استخدام S2S VPN كنسخة احتياطية لمحاذاة ExpressRoute الخاصة

في المقالة التي بعنوان Designing for disaster recovery with ExpressRoute private peering، ناقشنا الحاجة إلى حل اتصال النسخ الاحتياطي عند استخدام التناظر الخاص ExpressRoute. ناقشنا أيضا كيفية استخدام دوائر ExpressRoute المتكررة جغرافيا للحصول على قابلية وصول عالية. في هذه المقالة، نشرح كيفية استخدام وصيانة VPN من موقع إلى موقع (S2S) كنسخة احتياطية لنظير ExpressRoute الخاص.

إشعار

لا ينصح باستخدام VPN من موقع إلى موقع كحل احتياطي لاتصال ExpressRoute عند التعامل مع أحمال العمل الحساسة لزمن الانتقال أو المهمة الحرجة أو كثيفة النطاق الترددي. في مثل هذه الحالات، من المستحسن تصميم التعافي من الكوارث باستخدام مرونة ExpressRoute متعددة المواقع لضمان أقصى قدر من التوفر.

على عكس دوائر ExpressRoute المكررة جغرافيا، يمكنك فقط استخدام مجموعة التعافي من الكوارث ExpressRoute وVPN في إعداد نشط-سلبي. يتمثل أحد التحديات الرئيسة لاستخدام أي اتصال احتياطي للشبكة في الوضع الخامل في أن الاتصال الخامل غالباً ما يفشل جنباً إلى جنب مع الاتصال الأساسي. السبب الشائع لفشل الاتصال السلبي هو نقص الصيانة النشطة. لذلك، في هذه المقالة، ينصب التركيز على كيفية التحقق من اتصال S2S VPN الذي ينسخ نسخة احتياطية من نظير ExpressRoute الخاص والحفاظ عليه بنشاط.

إشعار

عند الإعلان عن مسار معين من خلال كل من ExpressRoute وVPN، سيفضل Azure التوجيه عبر ExpressRoute.

في هذه المقالة، ستتعلم أيضا كيفية التحقق من الاتصال من منظور Azure وجانب حافة الشبكة المحلية. تساعد القدرة على التحقق من الصحة من أي جانب بغض النظر عما إذا كنت تدير أجهزة الشبكة المحلية التي تتناظر مع كيانات شبكة Microsoft أم لا.

مثال طوبولوجيا

في الإعداد لدينا، لدينا شبكة محلية متصلة بشبكة ظاهرية لمركز Azure عبر كل من دائرة ExpressRoute واتصال S2S VPN. الشبكة الظاهرية لمركز Azure هي بدورها نظير لشبكة ظاهرية محورية، كما هو موضح في الرسم التخطيطي:

1

في الإعداد، يتم إنهاء دائرة ExpressRoute على زوج من أجهزة توجيه حافة العميل (CE) في الموقع. شبكة LAN المحلية متصلة بأوجه توجيه CE مع زوج من جدران الحماية التي تعمل في وضع المتابعين السابقين. يتم إنهاء S2S VPN مباشرة على جدران الحماية.

يسرد الجدول التالي بادئات IP الرئيسة للطوبولوجيا:

الكيان البادئة
LAN في أماكن العمل 10.1.11.0/25
شبكة Azure Hub الظاهرية 10.17.11.0/25
الشبكة الظاهرية ل Azure spoke 10.17.11.128/26
خادم اختبار محلي 10.1.11.10
الجهاز الظاهري لاختبار الشبكة الظاهرية Spoke 10.17.11.132
الشبكة الفرعية لاتصال ExpressRoute الأساسي P2P 192.168.11.16/30
الشبكة الفرعية لاتصال ExpressRoute الثانوي P2P 192.168.11.20/30
بوابة VPN IP للأقران BGP الأساسي 10.17.11.76
بوابة VPN الثانوية BGP نظير IP 10.17.11.77
جدار الحماية الداخلي VPN BGP نظير IP 192.168.11.88
موجه CE الأساسي i / f نحو IP لجدار الحماية 192.168.11.0/31
جدار الحماية i / f باتجاه IP الأساسي لجهاز التوجيه CE 192.168.11.1/31
موجه CE الثانوي i / f نحو IP لجدار الحماية 192.168.11.2/31
جدار الحماية i / f باتجاه IP الثانوي لجهاز التوجيه CE 192.168.11.3/31

يسرد الجدول التالي ASNs للطوبولوجيا:

النظام الذاتي ASN
محلي 65020
Microsoft إنتربرايز إيدج 12076
الشبكة الظاهرية GW (ExR) 65515
الشبكة الظاهرية GW (VPN) 65515

التوافر العالي دون عدم التماثل

تكوين لتوافر عالية

تشرح المقالة تكوين اتصالات ExpressRoute والاتصالات المتعايشة من موقع إلى موقع كيفية إعداد اتصالات ExpressRoute وS2S VPN المتعايشة. كما ذكرنا في Designing for high availability with ExpressRoute، يضمن إعدادنا تكرار الشبكة للقضاء على أي نقطة فشل واحدة تصل إلى نقاط النهاية، ما يحسن توفر ExpressRoute العالي. بالإضافة إلى ذلك، تكون كل من الاتصالات الأساسية والثانوية لدائرات ExpressRoute نشطة وتعلن عن البادئات المحلية بنفس الطريقة من خلال كلا الاتصالين.

يتم عرض إعلان المسار المحلي لموجه CE الأساسي من خلال الاتصال الأساسي لدائرة ExpressRoute كما يلي (أوامر Junos):

user@SEA-MX03-01> show route advertising-protocol bgp 192.168.11.18 

Cust11.inet.0: 8 destinations, 8 routes (7 active, 0 holddown, 1 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.1.11.0/25            Self                                    I

يتم عرض إعلان المسار المحلي لموجه CE الثانوي من خلال الاتصال الثانوي لدائرة ExpressRoute كما يلي (أوامر Junos):

user@SEA-MX03-02> show route advertising-protocol bgp 192.168.11.22 

Cust11.inet.0: 8 destinations, 8 routes (7 active, 0 holddown, 1 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.1.11.0/25            Self                                    I

لتحسين التوفر العالي لاتصال النسخ الاحتياطي، يتم أيضاً تكوين S2S VPN في الوضع النشط -النشط. يظهر تكوين بوابة Azure VPN كما يلي. ملاحظة كجزء من تكوين VPN، يتم أيضاً سرد عناوين IP للأقران BGP للبوابة - 10.17.11.76 و10.17.11.77 -.

2

يتم الإعلان عن المسار المحلي بواسطة جدار الحماية لأقران BGP الأساسيين والثانويين لبوابة VPN. يتم عرض إعلانات المسار كما يلي (Junos):

user@SEA-SRX42-01> show route advertising-protocol bgp 10.17.11.76 

Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.1.11.0/25            Self                                    I

{primary:node0}
user@SEA-SRX42-01> show route advertising-protocol bgp 10.17.11.77    

Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
* 10.1.11.0/25            Self                                    I

إشعار

لا يوفر تكوين S2S VPN في الوضع النشط-النشط توفرا عاليا لاتصال شبكة النسخ الاحتياطي للتعافي من الكوارث فحسب، بل يوفر أيضا معدل نقل أعلى لاتصال النسخ الاحتياطي. لذلك، يوصى بتكوين S2S VPN في الوضع النشط-النشط لأنه سينشئ أنفاقا أساسية متعددة.

التكوين لتدفق حركة المرور المتماثل

لاحظنا أنه عند الإعلان عن مسار محلي معين من خلال كل من ExpressRoute وS2S VPN، يفضل Azure مسار ExpressRoute. لإجبار Azure على تفضيل مسار S2S VPN على ExpressRoute المتعايش، تحتاج إلى الإعلان عن مسارات أكثر تحديدا (بادئة أطول بقناع شبكة فرعية أكبر) من خلال اتصال VPN. هدفنا هو استخدام اتصالات VPN كنسخة احتياطية فقط. لذلك، يتماشى سلوك تحديد المسار الافتراضي لـ Azure مع هدفنا.

تقع على عاتقنا مسؤولية التأكد من أن نسبة استخدام الشبكة الموجهة إلى Azure من أماكن العمل تفضل أيضا مسار ExpressRoute عبر VPN من موقع إلى موقع. التفضيل المحلي الافتراضي لأجهزة توجيه CE وجدران الحماية في الإعداد المحلي لدينا هو 100. لذلك، من خلال تكوين التفضيل المحلي للمسارات التي يتم تلقيها من خلال النظراء الخاصين ExpressRoute أكبر من 100، يمكننا جعل حركة المرور الموجهة إلى Azure تفضل دائرة ExpressRoute.

يظهر تكوين BGP لموجه CE الأساسي الذي ينهي الاتصال الأساسي لدائرة ExpressRoute كما يلي. لاحظ أن قيمة التفضيل المحلي للمسارات المعلن عنها خلال جلسة iBGP مهيئة لتكون 150. وبالمثل، نحتاج إلى التأكد من أن التفضيل المحلي للموجه CE الثانوي الذي ينهي الاتصال الثانوي لدائرة ExpressRoute قد تَكَوَّنَ أيضاً ليكون 150.

user@SEA-MX03-01> show configuration routing-instances Cust11
description "Customer 11 VRF";
instance-type virtual-router;
interface xe-0/0/0:0.110;
interface ae0.11;
protocols {
  bgp {
    group ibgp {
        type internal;
        local-preference 150;
        neighbor 192.168.11.1;
    }
    group ebgp {
        peer-as 12076;
        bfd-liveness-detection {
            minimum-interval 300;
            multiplier 3;
        }
        neighbor 192.168.11.18;
    }
  }
}

يؤكد جدول التوجيه لجدار الحماية المحلي أنه بالنسبة لنسبة استخدام الشبكة المحلية الموجهة إلى Azure، يكون المسار المفضل عبر ExpressRoute في الحالة الثابتة.

user@SEA-SRX42-01> show route table Cust11.inet.0 10.17.11.0/24

Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.17.11.0/25      *[BGP/170] 2d 00:34:04, localpref 150
                      AS path: 12076 I, validation-state: unverified
                    > to 192.168.11.0 via reth1.11
                      to 192.168.11.2 via reth2.11
                    [BGP/170] 2d 00:34:01, localpref 150
                      AS path: 12076 I, validation-state: unverified
                     > to 192.168.11.2 via reth2.11
                    [BGP/170] 2d 21:12:13, localpref 100, from 10.17.11.76
                       AS path: 65515 I, validation-state: unverified
                    > via st0.118
                    [BGP/170] 2d 00:41:51, localpref 100, from 10.17.11.77
                       AS path: 65515 I, validation-state: unverified
                     > via st0.119
10.17.11.76/32     *[Static/5] 2d 21:12:16
                     > via st0.118
10.17.11.77/32     *[Static/5] 2d 00:41:56
                    > via st0.119
10.17.11.128/26    *[BGP/170] 2d 00:34:04, localpref 150
                       AS path: 12076 I, validation-state: unverified
                     > to 192.168.11.0 via reth1.11
                       to 192.168.11.2 via reth2.11
                    [BGP/170] 2d 00:34:01, localpref 150
                      AS path: 12076 I, validation-state: unverified
                     > to 192.168.11.2 via reth2.11
                    [BGP/170] 2d 21:12:13, localpref 100, from 10.17.11.76
                       AS path: 65515 I, validation-state: unverified
                    > via st0.118
                     [BGP/170] 2d 00:41:51, localpref 100, from 10.17.11.77
                       AS path: 65515 I, validation-state: unverified
                     > via st0.119

في جدول التوجيه أعلاه، بالنسبة إلى مسارات الشبكة الظاهرية المحورية- 10.17.11.0/25 و10.17.11.128/26- نرى دائرة ExpressRoute مفضلة على اتصالات VPN. 192.168.11.0 و192.168.11.2 عبارة عن عناوين IP على واجهة جدار الحماية تجاه أجهزة توجيه CE.

التحقق من صحة تبادل المسار عبر S2S VPN

في وقت سابق من هذه المقالة، تحققنا من إعلان المسار المحلي لجدران الحماية إلى نظراء BGP الأساسيين والثانويين لبوابة VPN. بالإضافة إلى ذلك، دعنا نؤكد مسارات Azure التي تتلقاها جدران الحماية من نظراء BGP الأساسيين والثانويين لبوابة VPN.

user@SEA-SRX42-01> show route receive-protocol bgp 10.17.11.76 table Cust11.inet.0 

Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  10.17.11.0/25           10.17.11.76                             65515 I
  10.17.11.128/26         10.17.11.76                             65515 I

{primary:node0}
user@SEA-SRX42-01> show route receive-protocol bgp 10.17.11.77 table Cust11.inet.0    

Cust11.inet.0: 14 destinations, 21 routes (14 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  10.17.11.0/25           10.17.11.77                             65515 I
  10.17.11.128/26         10.17.11.77                             65515 I

وبالمثل، فلنتحقق من بادئات مسار الشبكة المحلية التي تتلقاها بوابة Microsoft Azure VPN.

PS C:\Users\user> Get-AzVirtualNetworkGatewayLearnedRoute -ResourceGroupName SEA-Cust11 -VirtualNetworkGatewayName SEA-Cust11-VNet01-gw-vpn | where {$_.Network -eq "10.1.11.0/25"} | select Network, NextHop, AsPath, Weight

Network      NextHop       AsPath      Weight
-------      -------       ------      ------
10.1.11.0/25 192.168.11.88 65020        32768
10.1.11.0/25 10.17.11.76   65020        32768
10.1.11.0/25 10.17.11.69   12076-65020  32769
10.1.11.0/25 10.17.11.69   12076-65020  32769
10.1.11.0/25 192.168.11.88 65020        32768
10.1.11.0/25 10.17.11.77   65020        32768
10.1.11.0/25 10.17.11.69   12076-65020  32769
10.1.11.0/25 10.17.11.69   12076-65020  32769

كما رأينا سابقا، تحتوي بوابة VPN على مسارات تم تلقيها من قبل نظراء BGP الأساسيين والثانويين لبوابة VPN. كما أنها تتمتع بإمكانية الرؤية عبر المسارات المستلمة عبر اتصالات ExpressRoute الأولية والثانوية (تلك التي تحتوي على مسار AS مُسبق بـ 12076). لتأكيد المسارات التي يتم تلقيها عبر اتصالات VPN، نحتاج إلى معرفة عنوان IP المحلي الخاص بنظير BGP للاتصالات. في الإعداد قيد النظر، IP هو 192.168.11.88 ونرى المسارات المستلمة منه.

بعد ذلك، دعنا نتحقق من المسارات التي تم الإعلان عنها بواسطة بوابة Microsoft Azure VPN إلى نظير BGP لجدار الحماية الداخلي (192.168.11.88).

PS C:\Users\user> Get-AzVirtualNetworkGatewayAdvertisedRoute -Peer 192.168.11.88 -ResourceGroupName SEA-Cust11 -VirtualNetworkGatewayName SEA-Cust11-VNet01-gw-vpn |  select Network, NextHop, AsPath, Weight

Network         NextHop     AsPath Weight
-------         -------     ------ ------
10.17.11.0/25   10.17.11.76 65515       0
10.17.11.128/26 10.17.11.76 65515       0
10.17.11.0/25   10.17.11.77 65515       0
10.17.11.128/26 10.17.11.77 65515       0

يشير الفشل في رؤية تبادلات المسار إلى فشل الاتصال. راجع استكشاف الأخطاء وإصلاحها: لا يمكن اتصال VPN من موقع إلى موقع من Azure ويتوقف عن العمل للحصول على تعليمات حول استكشاف أخطاء اتصال VPN وإصلاحها.

اختبار تجاوز الفشل

الآن بعد أن تأكدنا من تبادل المسار الناجح عبر اتصال VPN (مستوى التحكم)، تم تعييننا لتبديل نسبة استخدام الشبكة (مستوى البيانات) من اتصال ExpressRoute إلى اتصال VPN.

إشعار

في بيئات الإنتاج، يجب إجراء اختبار تجاوز الفشل أثناء نافذة عمل صيانة الشبكة المجدولة حيث يمكن أن يؤدي ذلك إلى تعطيل الخدمة.

قبل إجراء تبديل نسبة استخدام الشبكة، دعنا نتتبع المسار الحالي في الإعداد لدينا من خادم الاختبار المحلي إلى الجهاز الظاهري للاختبار في الشبكة الظاهرية المحورية.

C:\Users\PathLabUser>tracert 10.17.11.132

Tracing route to 10.17.11.132 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  10.1.11.1
  2    <1 ms    <1 ms    11 ms  192.168.11.0
  3    <1 ms    <1 ms    <1 ms  192.168.11.18
  4     *        *        *     Request timed out.
  5     6 ms     6 ms     5 ms  10.17.11.132

Trace complete.

الشبكات الفرعية لاتصال ExpressRoute الأولية والثانوية من إعدادنا هي، على التوالي، 192.168.11.16/30 و192.168.11.20/30. في مسار التتبع أعلاه، في الخطوة 3 نرى أننا نصل إلى 192.168.11.18، وهو عنوان IP لواجهة MSEE الأساسي. يؤكد وجود واجهة MSEE أنه كما هو متوقع يكون مسارنا الحالي عبر ExpressRoute.

كما تم الإبلاغ عنه في تناظرات إعادة تعيين دائرة ExpressRoute، دعنا نستخدم أوامر PowerShell التالية لتعطيل كل من التناظر الأساسي والثانوي لدائرة ExpressRoute.

$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Disabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt

يعتمد وقت تبديل تجاوز الفشل على وقت تقارب BGP. في إعدادنا، يستغرق مفتاح تجاوز الفشل بضع ثوانٍ (أقل من 10). بعد التبديل، يُظهر تكرار مسار التتبع المسار التالي:

C:\Users\PathLabUser>tracert 10.17.11.132

Tracing route to 10.17.11.132 over a maximum of 30 hops

  1    <1 ms    <1 ms    <1 ms  10.1.11.1
  2     *        *        *     Request timed out.
  3     6 ms     7 ms     9 ms  10.17.11.132

Trace complete.

تؤكد نتيجة traceroute أن اتصال النسخ الاحتياطي عبر S2S VPN نشط، ويمكن أن يوفر استمرارية الخدمة إذا فشلت اتصالات ExpressRoute الأساسية والثانوية. لإكمال اختبار تجاوز الفشل، لنقم بتمكين اتصالات ExpressRoute مرة أخرى وتطبيع تدفق حركة المرور، باستخدام مجموعة الأوامر التالية.

$ckt = Get-AzExpressRouteCircuit -Name "expressroute name" -ResourceGroupName "SEA-Cust11"
$ckt.Peerings[0].State = "Enabled"
Set-AzExpressRouteCircuit -ExpressRouteCircuit $ckt

لتأكيد إعادة حركة المرور إلى ExpressRoute، كرر مسار التتبع وتأكد من أنها تمر عبر نظير ExpressRoute الخاص.

الخطوات التالية

تم تصميم ExpressRoute لتوفير إمكانية عالية مع عدم وجود نقطة فشل واحدة داخل شبكة Microsoft. لا تزال دائرة ExpressRoute مقصورة على منطقة جغرافية واحدة ومزود خدمة. يمكن أن يكون S2S VPN حلّاً جيداً للنسخ الاحتياطي السلبي لاستعادة البيانات بعد الكوارث لدائرة ExpressRoute. للحصول على حل اتصال احتياطي سلبي يمكن الاعتماد عليه، تعد الصيانة الدورية للتكوين السلبي والتحقق الدوري من صحة الاتصال أمراً مهمّاً. من الضروري عدم السماح لتكوين VPN بأن يصبح قديما، وتكرار خطوات التحقق من الصحة واختبار تجاوز الفشل الموضحة في هذه المقالة بشكل دوري (على سبيل المثال كل ثلاثة أشهر) أثناء نافذة الصيانة.

لتمكين المراقبة والتنبيهات استنادا إلى مقاييس بوابة VPN، راجع إعداد التنبيهات على مقاييس بوابة VPN.

لتسريع تقارب BGP بعد فشل ExpressRoute، كَوِّن BFD عبر ExpressRoute .