كان لخادم Lantern القديم عنوان IP عام وجدار حماية لم ينظر إليه أحد، بصراحة، منذ عامين. وكانت قاعدة بياناته تستمع على المنفذ 5432 في الآلة نفسها. على AWS ستعمل قاعدة البيانات وحدها، والسؤال الأول: من يستطيع الوصول إليها أصلًا؟ الجواب يُصمَّم في Amazon VPC، شبكتك الخاصة داخل AWS.
\nالـ VPC (السحابة الخاصة الافتراضية) شبكة معزولة في Region واحدة بنطاق عناوين IP تختاره، مثل 10.0.0.0/16 (65,536 عنوانًا). تمنح كل Region كل حساب VPC افتراضيًا بشبكات فرعية عامة، وهو مفيد للتجارب؛ أما الإنتاج فيحصل على VPC تصمّمه بنفسك.
الشبكة الفرعية (subnet) شريحة من ذلك النطاق داخل منطقة توافر واحدة، مثل 10.0.1.0/24 (256 عنوانًا، تحجز AWS خمسة منها). ولأن كل شبكة فرعية مرتبطة بمنطقة توافر واحدة (zonal)، فالصمود يعني أزواجًا: يستخدم Lantern منطقتي توافر، في كلٍّ منهما شبكة فرعية عامة وأخرى خاصة.
لا شيء في الشبكة الفرعية نفسها. إنه جدول التوجيه (route table):
\nPublic route table Private route table\n10.0.0.0/16 -> local 10.0.0.0/16 -> local\n0.0.0.0/0 -> igw-0abc... 0.0.0.0/0 -> nat-0def...الشبكة الفرعية التي يرسل جدول التوجيه الخاص بها 0.0.0.0/0 (كل ما ليس محليًا) إلى بوابة إنترنت (internet gateway) شبكة عامة: يستطيع المورد الموجود فيها والذي له IP عام أن يتواصل مع الإنترنت وأن يُوصَل إليه منه. أما الشبكة الفرعية الخاصة فليس فيها مسار إلى بوابة الإنترنت، فلا يستطيع أي شيء على الإنترنت أن يبدأ اتصالًا بها. وإذا احتاجت الموارد الخاصة إلى بدء اتصالات صادرة، لتنزيل تحديثات نظام التشغيل مثلًا، فإنها توجّهها عبر بوابة NAT (NAT gateway) تقع في شبكة فرعية عامة.
تذهب قاعدة بيانات Lantern وخادم الترحيل إلى شبكات فرعية خاصة. أما الشبكات الفرعية العامة فلا تضم إلا بوابة NAT، ولاحقًا load balancer.
\n\nمجموعة الأمان (security group) قائمة سماح تُرفق بواجهة الشبكة الخاصة بمورد ما: instance، أو قاعدة بيانات RDS، أو دالة Lambda داخل الـ VPC. ثلاث خصائص تجعل العمل معها مريحًا:
\nlantern-app-sg” تعني “من أي شيء يحمل تلك المجموعة”، مهما كان عدد الـ instances ومهما كانت عناوينها.aws ec2 authorize-security-group-ingress \\\n --group-id sg-0db1111111111111a \\\n --protocol tcp --port 5432 \\\n --source-group sg-0app222222222222bهذه القاعدة الواحدة تقول كل شيء: قاعدة البيانات تقبل PostgreSQL من طبقة التطبيق ولا شيء غير ذلك.
\n\nالـ network ACL ترشّح الزيارات عند حدود الشبكة الفرعية. وتختلف عن مجموعة الأمان في كل شيء:
\n| \n | مجموعة الأمان | \nالـ network ACL | \n
|---|---|---|
| تُرفق بـ | \nالموارد (واجهات الشبكة) | \nالشبكات الفرعية | \n
| القواعد | \nسماح فقط | \nسماح ورفض | \n
| الحالة | \nذات حالة: الردود مسموح بها | \nعديمة الحالة: الردود تحتاج إلى قواعد | \n
| الترتيب | \nتُؤخذ كل القواعد في الحسبان | \nالرقم الأصغر أولًا، وأول تطابق ينتصر | \n
لأن الـ ACLs عديمة الحالة، فالسماح بالمنفذ 443 الوارد لا يكفي: الرد يخرج من المنفذ 443 إلى المنفذ المؤقت (ephemeral port) لدى العميل (1024–65535)، ويجب أن تسمح القواعد الصادرة بذلك أيضًا. تسمح الـ network ACL الافتراضية بكل شيء في الاتجاهين، ومعظم الفرق تتركها كذلك وتنجز العمل الحقيقي في مجموعات الأمان. الجأ إلى ACL مخصّصة حين تحتاج إلى رفض على مستوى الشبكة الفرعية كلها، مثل حجب نطاق عناوين مسيء.
\nالـ VPC والشبكات الفرعية وجداول التوجيه ومجموعات الأمان والـ ACLs مجانية. ما يُحتسب هو ما تضعه فيها: بوابات NAT بالساعة إضافة إلى كل غيغابايت، وعناوين IPv4 العامة بالساعة، والزيارات بين مناطق التوافر لكل غيغابايت. بوابة NAT واحدة لكل منطقة توافر هي الخيار الصامد؛ أما بوابة واحدة مشتركة فتوفّر المال وتقبل أن يقطع تعطّل منطقة توافر الزيارات الصادرة من الموارد الخاصة. ولمشروع بحجم Lantern، الخيار الافتراضي المعقول هو بوابة NAT واحدة مع نقاط نهاية من نوع gateway، ثم إعادة النظر حين تنمو الزيارات. (ومنذ أواخر 2025 توفّر AWS أيضًا بوابة NAT إقليمية (regional) تتوزّع على مناطق التوافر من تلقاء نفسها ولا تحتاج إلى شبكة فرعية عامة؛ قارن سعرها قبل أن تنتقل إليها.)
\nبهذا تكتمل الخدمات الأساسية. يجمعها القسم الرابع معًا وينشر Lantern الجديد.
\n","toc":[{"id":"sec-1","text":"الـ VPC وشبكاته الفرعية","level":2},{"id":"sec-2","text":"ما الذي يجعل الشبكة الفرعية عامة","level":2},{"id":"sec-3","text":"مجموعات الأمان: جدران حماية ذات حالة على الموارد","level":2},{"id":"sec-4","text":"الـ network ACLs: قواعد عديمة الحالة على الشبكات الفرعية","level":2},{"id":"sec-5","text":"كم يكلّف هذا","level":2}],"takeaways":["الـ VPC شبكتك الخاصة في Region واحدة، وكل شبكة فرعية (subnet) نطاق عناوين داخل منطقة توافر واحدة.","تكون الشبكة الفرعية عامة فقط لأن جدول التوجيه الخاص بها يرسل 0.0.0.0/0 إلى بوابة إنترنت (internet gateway)؛ أما الشبكات الفرعية الخاصة فليس فيها مسار كهذا.","مجموعات الأمان (security groups) قوائم سماح ذات حالة (stateful) تُرفق بالموارد، ويمكنها أن تسمّي مجموعة أمان أخرى كمصدر مسموح به.","الـ network ACLs قوائم قواعد عديمة الحالة (stateless) على الشبكات الفرعية، تُقيَّم بترتيب أرقامها، ويمكنها الرفض كما يمكنها السماح.","بوابات NAT وعناوين IPv4 العامة تُحتسب بالساعة، بينما تتيح نقاط النهاية من نوع gateway للشبكات الفرعية الخاصة الوصول إلى S3 وDynamoDB دون رسوم إضافية."],"further":[{"title":"How Amazon VPC works","url":"https://docs.aws.amazon.com/vpc/latest/userguide/how-it-works.html"},{"title":"Control traffic to your AWS resources using security groups","url":"https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html"},{"title":"Control subnet traffic with network access control lists","url":"https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html"},{"title":"Gateway endpoints","url":"https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html"}],"quiz":[{"q":"شبكتان فرعيتان في الـ VPC الخاص بـ Lantern متطابقتان، إلا أن جدول التوجيه في إحداهما يحتوي على المسار 0.0.0.0/0 → igw-0abc…. ما الذي يغيّره هذا المسار؟
يجب أن تقبل مجموعة الأمان الخاصة بقاعدة بيانات Lantern اتصالات PostgreSQL من خوادم التطبيق فقط. أيّ قاعدة واردة (inbound) هي الأفضل؟
","options":[{"text":"TCP 5432 من مجموعة الأمان الخاصة بخوادم التطبيق.","why":"صحيح. الإشارة إلى مجموعة أمان تظل تعمل حين تُستبدل خوادم التطبيق أو يتغيّر عددها، دون تتبّع عناوين IP."},{"text":"TCP 5432 من 0.0.0.0/0، لأن قاعدة البيانات في شبكة فرعية خاصة على أي حال.","why":"الشبكة الفرعية الخاصة طبقة حماية واحدة. والسماح للإنترنت كله يزيل الطبقة الثانية ويتيح لأي شيء داخل الـ VPC الاتصال."},{"text":"كل الزيارات من نطاق CIDR الخاص بالـ VPC.","why":"هذا يتيح لكل مورد في الـ VPC الوصول إلى كل منفذ في قاعدة البيانات، وهذا أوسع بكثير مما يحتاجه التطبيق."},{"text":"TCP 5432 من عنوان IP الخاص الحالي لكل خادم تطبيق.","why":"يعمل حتى تُستبدل instance وتحصل على عنوان جديد. عندها تفشل الاتصالات، أو ترث instance غريبة العنوان القديم."}],"answer":0},{"q":"تسمح network ACL بزيارات TCP 443 الواردة من أي مكان، لكن طلبات HTTPS إلى instance في الشبكة الفرعية تنتهي مهلتها، مع أن مجموعة الأمان الخاصة بها تسمح بـ 443. ما السبب المرجّح؟
","options":[{"text":"مجموعات الأمان تتجاوز الـ network ACLs، لذا تُتجاهل الـ ACL.","why":"الطبقتان تنطبقان كلتاهما. يجب أن تمرّ الزيارات عبر الـ network ACL وعبر مجموعة الأمان."},{"text":"تحتاج الـ instance إلى بوابة NAT للرد على الطلبات.","why":"بوابة NAT للموارد الخاصة التي تبدأ اتصالات صادرة. أما الردود على الطلبات الواردة في شبكة فرعية عامة فتمرّ عبر بوابة الإنترنت."},{"text":"الـ network ACLs عديمة الحالة، لذا يجب أن تسمح القواعد الصادرة أيضًا بزيارات الرد إلى المنافذ المؤقتة (ephemeral ports).","why":"صحيح. على عكس مجموعات الأمان، لا تتذكّر الـ network ACL الاتصال، فتحتاج زيارات الرد إلى قاعدة سماح خاصة بها."},{"text":"تحجب AWS المنفذ 443 في الحسابات الجديدة.","why":"لا تحجب AWS المنفذ 443 عن مواردك. الزيارات الواردة تتحكّم فيها الـ network ACLs ومجموعات الأمان الخاصة بك."}],"answer":2}],"exercise":{"kind":"spot-bug","language":"bash","code":"#!/usr/bin/env bash\nset -euo pipefail\nVPC_ID=\"vpc-0abc1234def567890\"\n\nAPP_SG=$(aws ec2 create-security-group --group-name lantern-app-sg \\\n --description \"Lantern app servers\" --vpc-id \"$VPC_ID\" \\\n --query GroupId --output text)\nDB_SG=$(aws ec2 create-security-group --group-name lantern-db-sg \\\n --description \"Lantern PostgreSQL\" --vpc-id \"$VPC_ID\" \\\n --query GroupId --output text)\n\n# Visitors reach the app over HTTPS during the migration\naws ec2 authorize-security-group-ingress --group-id \"$APP_SG\" \\\n --protocol tcp --port 443 --cidr 0.0.0.0/0\n\n# Maintainers need a shell on the app servers\naws ec2 authorize-security-group-ingress --group-id \"$APP_SG\" \\\n --protocol tcp --port 22 --cidr 0.0.0.0/0\n\n# Only the app servers may talk to PostgreSQL\naws ec2 authorize-security-group-ingress --group-id \"$DB_SG\" \\\n --protocol tcp --port 5432 --cidr 0.0.0.0/0","bugLines":[18,22],"title":"راجع سكربت مجموعات الأمان","prompt":"كتب أحد المتطوّعين هذا السكربت لإنشاء مجموعات الأمان الخاصة بـ Lantern خلال عملية الترحيل. التعليقات تصف المقصود، والمقصود صحيح. اختر كل سطر لا يطابق فيه الكود نسخةً آمنة من ذلك المقصود.
\n","hints":["HTTPS العام على خوادم التطبيق مقصود في الوقت الحالي. انظر إلى القاعدتين الأخريين.","أيّ قاعدة تكشف للإنترنت كله منفذًا يمسحه المهاجمون باستمرار؟","يقول تعليق قاعدة البيانات “only the app servers”. ماذا يعني0.0.0.0/0؟"],"explanation":"السطر 18 يفتح SSH لكل عنوان على الإنترنت. يجب أن يستخدم القائمون على المشروع AWS Systems Manager Session Manager، الذي لا يحتاج إلى أي قاعدة واردة على الإطلاق؛ وإذا كان SSH لا مفرّ منه، فقيّد --cidr بنطاق معروف للمكتب أو للـ VPN مثل 203.0.113.0/24. والسطر 22 يتيح لأي شيء الوصول إلى PostgreSQL. استبدل الـ CIDR بإشارة إلى مجموعة طبقة التطبيق، كي تتبع القاعدة خوادم التطبيق أينما عملت:
aws ec2 authorize-security-group-ingress --group-id \"$DB_SG\" \\\n --protocol tcp --port 5432 --source-group \"$APP_SG\"السطر 14 سليم: خلال الترحيل يصل الزوّار فعلًا إلى التطبيق عبر HTTPS. ووجود قاعدة البيانات في شبكة فرعية خاصة كان سيقلّل ضرر السطر 22، لكن الدفاع المتعدّد الطبقات يعني أن كل طبقة يجب أن تكون صحيحة بذاتها.
\n","checkLabels":{}},"words":770,"readMinutes":5}