لماذا يُسقط AWS Client VPN حركة المرور مع عدم وجود مسار مطابق

Client VPN يمنح العميل عنوانًا، وتكتمل المصافحة، ومع ذلك لا يصل الاتصال إلى أي مكان. قبل أن تلمس الشهادات أو إصدارات العميل، انظر إلى جدول مسارات الطرف الطرفي نفسه. لا يُمرّر طرف AWS Client VPN الطرفي أي حزمة إلا إذا كان أحد مساراته يغطّي بادئة الوجهة؛ وإذا لم يتطابق شيء، تُهمَل الحزمة عند الطرف الطرفي ولا يرى المضيف الهدف أي SYN أبدًا.

هذا قرار إعادة توجيه، وليس قرار مصادقة. يحدث بعد أن يصبح النفق قائمًا وبعد تقييم قواعد التفويض، ولهذا قد تُنتج شهادة صالحة ومجموعة صالحة اتصالًا ميتًا مع ذلك.

الطرف الطرفي لا يُمرّر إلا ما يغطّيه جدول مساراته

كل مسار هو CIDR للوجهة مضافًا إليه الشبكة الفرعية التي يجب أن تستقبل المرور. يقارن الطرف الطرفي وجهة العميل بتلك القائمة، ويختار الإدخال المطابق، ويرسل الحزمة إلى الشبكة الفرعية المرتبطة. لا إدخال يعني لا قفزة تالية.

لاحظ ما ليس عليه المسار. إنه ليس إدخالًا في جدول مسارات VPC، وهو لا يُفوّض شيئًا. قواعد التفويض تحدّد ما إذا كانت المجموعة قد تصل إلى وجهة؛ والمسارات تحدّد ما إذا كان لدى الطرف الطرفي مكان يرسل إليه الحزمة. يجب أن يتوافق الاثنان، وكلاهما يفشل بأعراض مختلفة، لذا تخمين أيّهما معطوب يُهدر بعد الظهر.

عدم التطابق الكلاسيكي هو VPC مناظر. يضيف أحدهم مسارًا لـ 10.20.0.0/24 بينما يوجد المضيف في 10.20.4.0/24، فيقع العنوان خارج كل إدخال. يُظهر التقاط على جانب العميل حزم SYN متكررة دون رد، وسجلات الهدف لا تُظهر شيئًا على الإطلاق.

اقرأ قائمة المسارات قبل الشهادة

مسارات الطرف الطرفي كائن مستقل، لذا استعلم عنها مباشرة بدلًا من قراءة جدول VPC:

aws ec2 describe-client-vpn-routes --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 --query 'Routes[].{Dest:DestinationCidr,Target:TargetSubnet,Origin:Origin}'

خذ العنوان الدقيق وطول البادئة من العميل الفاشل، ثم تحقّق من التغطية حرفًا بحرف. يُطبّق أطول تطابق بادئة، لذا لا ينقذك مسار أوسع عندما يشير مسار أضيق إلى مكان آخر.

مورد واحد لكل وجهة باستخدام for_each

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

variable "client_vpn_routes" {
  type = map(string)
  default = {
    "10.20.0.0/16"  = "subnet-0aa11bb22cc33dd44"
    "172.31.0.0/20" = "subnet-0aa11bb22cc33dd44"
  }
}

resource "aws_ec2_client_vpn_route" "this" {
  for_each               = var.client_vpn_routes
  client_vpn_endpoint_id = var.client_vpn_endpoint_id
  destination_cidr_block = each.key
  target_vpc_subnet_id   = each.value
  depends_on             = [aws_ec2_client_vpn_network_association.this]
}

احتفظ بالاعتماد على اقتران الشبكة. يحتاج المسار إلى شبكة فرعية مقترنة، لذا يجب أن يرتّب تطبيقٌ ينشئ الاثنين الاقتران أولًا، وبدون ذلك المرجع يبقى Terraform حرًا في تجربة المسار أولًا. ثم اقرأ الخطة: يجب أن يطابق عدد إضافات المسارات البادئات التي أضفتها. وإذا كانت الخطة تستبدل الطرف الطرفي أيضًا، فمورد الطرف الطرفي مكتوب بشكل خاطئ، وتطبيقه يفصل كل عميل متصل.

تبنّي طرف طرفي لم تُنشئه

ترث معظم الفرق طرفًا طرفيًا بُني في وحدة التحكم، ولهذا لا يوجد كود مسارات. لا تُقِم طرفًا طرفيًا ثانيًا لمجرد إدخال المسارات إلى Terraform.

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

تتبّع الحزمة بالترتيب الذي تسير به

عندما يوجد المسار ويظل الاتصال يفشل، امشِ المسار بالترتيب بدلًا من التخمين في الطبقة العليا.

1. المسار: تغطّي بادئة الوجهة وتشير إلى شبكة فرعية مقترنة بالطرف الطرفي.
2. التفويض: تسمح قاعدة تفويض بتلك الوجهة لمجموعة المستخدم. المسار وحده لا يمنح الوصول أبدًا.
3. مسار العودة: يرسل جدول مسارات الشبكة الفرعية الهدف الردود عائدة نحو الطرف الطرفي، وتسمح مجموعة الأمان بالمنفذ من مجموعة عناوين العميل.
4. التطبيق: افتح اتصال TCP حقيقيًا من العميل، ثم أكّد أن سجلات الهدف تُظهر عنوان المصدر المتوقع من المجموعة.

غيّر بادئة واحدة في كل تطبيق، وأعد قراءة قائمة المسارات بعد ذلك، وسجّل الوجهة وقاعدة التفويض ومسار العودة معًا. من يصلح اتصالًا مرفوضًا لاحقًا يجب أن يبدأ من ذلك الجرد، لا من نظرية عن الشهادات.