معمارية السحابة ومناطق الهبوط

الاتصال الهجين

18 دقيقة الدرس 6 من 28

الاتصال الهجين

كل مؤسسة تنتقل إلى السحابة لا تزال تمتلك أحمال عمل في مراكز البيانات التقليدية — أنظمة ميانفريم قديمة، أو قواعد بيانات محلية تحتفظ ببيانات منظمة، أو أنظمة SCADA للتصنيع، أو ببساطة أحمال عمل تستهلك نطاقاً ترددياً كبيراً حيث تجعل تكلفة نقل البيانات الخارجة من السحابة النقية أمراً غير اقتصادي. الاتصال الهجين هو التخصص الهندسي الذي يربط هذين العالمين بشكل موثوق وآمن وبالنطاق الترددي والزمن الكامن اللذين تحتاجهما تطبيقاتك فعلياً.

في هذا الدرس نغطي البنيتين الأساسيتين للاتصال الهجين في AWS — Site-to-Site VPN وAWS Direct Connect — إلى جانب بنية DNS التي تجعل البيئة الهجينة بأكملها تبدو كفضاء أسماء متماسك واحد.

Site-to-Site VPN

يُنهي AWS Site-to-Site VPN نفق IPsec بين Customer Gateway (CGW) الموجود في مقر عملك — وهو جهاز توجيه مادي أو برمجي — وبين AWS Virtual Private Gateway (VGW) أو Transit Gateway (TGW). تُهيئ AWS نفقين لكل اتصال VPN عبر مناطق توافر مستقلة لضمان التكرار؛ يجب أن يكون جهازك المحلي قادراً على إنشاء النفقين والتبديل بينهما عند الحاجة.

الإنتاجية: كل نفق محدود بسرعة تقريبية ~1.25 Gbps؛ الإجمالي العملي ~2.5 Gbps لكل اتصال باستخدام ECMP عبر النفقين. يدعم TGW تقنية ECMP عبر اتصالات VPN متعددة، لتتمكن من ربط 4-8 اتصالات للحصول على ~5-10 Gbps.
الزمن الكامن: يمر عبر شبكة الإنترنت العامة — توقع 20-80 ملي ثانية إضافية حسب الموقع الجغرافي وجودة مسار مزود الخدمة. غير مناسب للنسخ المتزامن لقواعد البيانات الحساسة للزمن أو التداول الفوري.
التكلفة: ~0.05 دولار/ساعة لكل اتصال + 0.09 دولار/GB لنقل البيانات الخارجة. للبيانات المعتدلة (أقل من 1 TB/شهر) تبقى أرخص بكثير من Direct Connect.
حالات الاستخدام: المكاتب الفرعية، احتياطي التعافي من الكوارث، بيئات التطوير والاختبار، أو مرحلة انتقالية قبل تجهيز Direct Connect.

إنشاء اتصال VPN على Transit Gateway عبر Terraform:

# customer_gateway.tf
resource "aws_customer_gateway" "dc1" {
  bgp_asn    = 65001        # رقم ASN الخاص بشبكتك المحلية
  ip_address = "203.0.113.1" # عنوان IP العام لمنفذ الخروج
  type       = "ipsec.1"
  tags = { Name = "dc1-cgw" }
}

resource "aws_vpn_connection" "dc1_tgw" {
  customer_gateway_id = aws_customer_gateway.dc1.id
  transit_gateway_id  = aws_ec2_transit_gateway.core.id
  type                = "ipsec.1"
  static_routes_only  = false   # استخدام BGP

  tunnel1_preshared_key = var.vpn_psk_tunnel1
  tunnel2_preshared_key = var.vpn_psk_tunnel2

  tags = { Name = "dc1-to-tgw" }
}

# تنزيل إعدادات الجهاز من Console أو CLI بعد الإنشاء:
# aws ec2 describe-vpn-connections \
#   --vpn-connection-ids <id> \
#   --query 'VpnConnections[0].CustomerGatewayConfiguration'

BGP إلزامي على نطاق واسع. المسارات الثابتة تتطلب تحديثات يدوية في كل مرة تُضاف فيها شبكة CIDR جديدة في أي من البيئتين؛ BGP يُوزع المسارات تلقائياً. استخدم أرقام ASN من النطاق الخاص (64512-65534) لجهاز CGW المحلي ما لم تمتلك ASN عاماً حقيقياً.

AWS Direct Connect

Direct Connect (DX) هو دائرة Layer 2 مخصصة بين منشأتك (أو شريك الاستضافة المشتركة) وموقع AWS Direct Connect. لا يمر حركة المرور أبداً عبر شبكة الإنترنت العامة — مما يعني زمن كامن يمكن التنبؤ به، وإنتاجية ثابتة، ووضعاً أمنياً أبسط بكثير (لا حاجة لـ IPsec على مسار البيانات).

سرعات المنفذ: 1 Gbps أو 10 Gbps أو 100 Gbps. الاتصالات دون 1 Gbps (50/100/200/300/400/500 Mbps) متاحة عبر Hosted Connections من شركاء APN.
الزمن الكامن: حتمي — عادةً 1-5 ملي ثانية إلى أقرب منطقة AWS من موقع DX المشترك.
الواجهات الافتراضية (VIFs): Private VIF ← يتصل بـ VPC عبر VGW أو TGW؛ Transit VIF ← يتصل بـ TGW (المفضل على نطاق المؤسسة — اتصال DX واحد يغذي جميع VPCs عبر شبكة TGW)؛ Public VIF ← يصل إلى نقاط AWS العامة مثل S3 وDynamoDB.
اتفاقية مستوى الخدمة للمرونة: منفذ DX واحد لا يحمل SLA من AWS. للحصول على توافر 99.99% توصي AWS بمنفذين في موقعَي DX مختلفَين متصلَين بجهازَي توجيه منفصلَين محلياً (أربعة جلسات BGP إجمالاً).

VPN يستخدم شبكة الإنترنت العامة (مشفّر)؛ Direct Connect يستخدم دائرة ألياف ضوئية مخصصة عبر موقع AWS DX — كلاهما ينتهي عند Transit Gateway.

Direct Connect وحده لا يوفر تشفيراً. الدائرة المادية خاصة لكنها غير محمية تشفيرياً. لمتطلبات الامتثال مثل HIPAA أو PCI-DSS أو FedRAMP High، شغّل VPN (MACsec أو IPsec) فوق اتصال Direct Connect. MACsec (تشفير Layer 2، مدعوم على الاتصالات المخصصة 10G/100G) هو الخيار الحديث — تشفير عتادي بدون تكلفة أداء لنفق برمجي.

الاختيار بين VPN وDirect Connect

في الواقع العملي الاختيار ليس ثنائياً — معظم المؤسسات الإنتاجية تشغّل الاثنين معاً:

Direct Connect كمسار أساسي: أحمال العمل الإنتاجية، نقل البيانات بكميات كبيرة، الخدمات الحساسة للزمن الكامن.
VPN كمسار احتياطي / للتعافي من الكوارث: يتحول تلقائياً عبر BGP عند تعطل DX. اضبط BGP local-preference أو MED أدنى على مسارات VPN حتى يُفضَّل DX دائماً.
VPN فقط: المكاتب الفرعية، المواقع الصغيرة، بيئات التطوير والاختبار، أو أي موقع لا يتحمل وقت تجهيز DX (عادةً 30-90 يوماً لتوصيل الألياف).

DNS عبر البيئة الهجينة

الاتصال الهجين يحل توجيه Layer 3؛ DNS يحل التسمية. بدون تكامل DNS يضطر المهندسون إلى ترميز عناوين IP مباشرةً أو صيانة ملفات hosts هشة — كلاهما غير مقبول على نطاق إنتاجي.

الحل الأصيل في AWS هو Route 53 Resolver، الذي يوفر نقطتَي نهاية بدون خوادم لكل VPC:

Inbound Resolver Endpoint: واجهات ENI في شبكات VPC الخاصة تقبل استعلامات DNS من المقر المحلي. يُوجِّه محلل DNS المحلي الاستعلامات الخاصة بـ *.aws.internal (أو أي نطاق خاص) إلى هذه الواجهات عبر DX أو VPN.
Outbound Resolver Endpoint: واجهات ENI تُرسل استعلامات DNS نحو المحللات المحلية. قاعدة Resolver تقول "أعِد توجيه الاستعلامات الخاصة بـ corp.example.com إلى 10.0.1.53".

# route53_resolver.tf — نقاط نهاية داخلة وخارجة + قاعدة توجيه

resource "aws_route53_resolver_endpoint" "inbound" {
  name      = "hybrid-inbound"
  direction = "INBOUND"
  security_group_ids = [aws_security_group.r53_inbound.id]

  ip_address {
    subnet_id = aws_subnet.private_a.id
  }
  ip_address {
    subnet_id = aws_subnet.private_b.id
  }
}

resource "aws_route53_resolver_endpoint" "outbound" {
  name      = "hybrid-outbound"
  direction = "OUTBOUND"
  security_group_ids = [aws_security_group.r53_outbound.id]

  ip_address {
    subnet_id = aws_subnet.private_a.id
  }
  ip_address {
    subnet_id = aws_subnet.private_b.id
  }
}

resource "aws_route53_resolver_rule" "on_prem_forward" {
  domain_name          = "corp.example.com"
  name                 = "forward-to-on-prem"
  rule_type            = "FORWARD"
  resolver_endpoint_id = aws_route53_resolver_endpoint.outbound.id

  target_ip {
    ip   = "10.10.1.53"   # محلل DNS الأساسي المحلي
    port = 53
  }
  target_ip {
    ip   = "10.10.2.53"   # محلل DNS الثانوي المحلي
    port = 53
  }
}

resource "aws_route53_resolver_rule_association" "core_vpc" {
  resolver_rule_id = aws_route53_resolver_rule.on_prem_forward.id
  vpc_id           = aws_vpc.core.id
}

# مشاركة القاعدة مع جميع VPCs عبر RAM:
resource "aws_ram_resource_share" "resolver_rules" {
  name                      = "resolver-rules"
  allow_external_principals = false
}

resource "aws_ram_resource_association" "rule" {
  resource_arn       = aws_route53_resolver_rule.on_prem_forward.arn
  resource_share_arn = aws_ram_resource_share.resolver_rules.arn
}

شارك قواعد Resolver عبر RAM، لا لكل VPC على حدة. في مؤسسة متعددة الحسابات، أنشئ Resolver Endpoints وقواعده في حساب الخدمات المشتركة (أو الشبكة)، ثم استخدم AWS Resource Access Manager لمشاركة القواعد مع كل VPC فرعي. هذا يعني مصدر حقيقة واحد لإعدادات التوجيه — لا عشرات النسخ المتفرقة لكل VPC التي يصعب إبقاؤها متزامنة.

أنماط الفشل الإنتاجية التي يجب معرفتها

اضطراب جلسة BGP: تهيئة خاطئة لمهلة الانتظار أو عدم تطابق MTU على دائرة DX يتسبب في إعادة ضبط BGP بشكل متقطع. تحقق دائماً من أن MTU الواجهة مضبوط على 8500 بايت على الواجهة المنطقية لـ DX (إطارات Jumbo مدعومة ومستحسنة).
التوجيه غير المتماثل: عند تشغيل VPN وDX معاً، قد تسلك حركة المرور العائدة مساراً مختلفاً عن المسار الذهابي. تأكد من أن جدار الحماية المحلي ذو حالة (stateful) وأن NAT لا يُطبَّق على مسار VPN عندما يكون DX هو المسار الأساسي.
الانقسام في DNS: مثيل EC2 يحل اسماً إلى عنوان IP خاص عبر Route 53، لكن المضيف المحلي يحل الاسم ذاته إلى عنوان IP عام. يحدث هذا عند عدم ربط النطاقات المستضافة الخاصة بجميع VPCs ذات الصلة. راجع باستخدام aws route53 list-vpc-association-authorizations.
تأخر تعافي DX: قد يستغرق تقارب BGP عند تعطل DX 90 ثانية إذا لم يُهيَّأ BFD (Bidirectional Forwarding Detection). فعّل BFD دائماً على واجهة DX الافتراضية — يكتشف أعطال الوصلة في أقل من ثانية واحدة ويُطلق سحب BGP فوراً.

اختبر التعافي قبل أن تحتاجه. محاكاة تعطل DX كل ربع سنة بوضع جلسة BGP في وضع الإيقاف الإداري على الموجه والتأكد من أن VPN يتولى المهمة ضمن هدف RTO المستهدف (عادةً أقل من 60 ثانية مع BFD). وثّق الاختبار في دفتر التشغيل.

الخلاصة

Site-to-Site VPN سريع التجهيز وفعال من حيث التكلفة للنطاق الترددي المنخفض إلى المتوسط؛ Direct Connect هو العمود الفقري لأحمال العمل الإنتاجية التي تتطلب زمناً كامناً ثابتاً وإنتاجية عالية — مع التشفير دائماً عبر MACsec للصناعات المنظمة. الاثنان متكاملان: DX كمسار أساسي، VPN كمسار احتياطي دافئ. Route 53 Resolver يجسر DNS عبر البيئة الهجينة بدون ترميز عناوين IP. شارك قواعد Resolver عبر RAM، فعّل BFD على جلسات DX، واختبر التعافي بجدول منتظم — هذه هي العادات التي تميز الهياكل الهوايتية عن شبكات الاتصال الهجينة بمستوى المؤسسة.