استخدام 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 هي بدورها نظير لشبكة ظاهرية محورية، كما هو موضح في الرسم التخطيطي:
في الإعداد، يتم إنهاء دائرة 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 -.
يتم الإعلان عن المسار المحلي بواسطة جدار الحماية لأقران 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 .