> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # تقسيم الشبكة Network Segmentation بال VLAN وال VPC - URL: https://arabroot.io/articles/تقسيم-الشبكة-network-segmentation-vlan-و-vpc/ - Published: 2026-10-07T16:15:00.000Z - Updated: 2026-10-09T13:02:33.000Z - Description: لماذا تصل كاميرا مخترقة إلى قاعدة بياناتك، وكيف تمنع ذلك بتقسيم الشبكة إلى مناطق لا يمر بينها إلا ما تسمح به. - Author: فريق عرب رووت - Tags: الأدلة التقنية, الشبكات والبنية التحتية, الشبكات والوصول, هوم لاب, الاستضافة الذاتية في مارس 2025 نشرت شركة الاستجابة للحوادث S-RM تفاصيل هجوم لعصابة Akira على أحد عملائها، والجزء الذي يهمنا في هذا المقال ليس الثغرة التي دخل منها المهاجمون، وإنما ما فعلوه بعد أن أوقفهم برنامج الحماية على السيرفر: بحثوا في الشبكة الداخلية فوجدوا كاميرا ويب تعمل بنظام Linux خفيف فيها ثغرات، فشغلوا برنامج الفدية عليها، ومنها شفروا ملفات السيرفر عبر الشبكة، والكاميرا لا يمكن أصلاً أن يثبت عليها برنامج حماية. والسؤال الذي يطرحه أي مدير شبكة بعد قراءة القصة: لماذا تستطيع كاميرا أن تتصل بسيرفر الملفات أصلاً؟ والإجابة أن الكاميرا والسيرفر وأجهزة الموظفين كانوا في نفس الشبكة، أي ما يسمى الشبكة المسطحة Flat Network. وفي مقال [الشبكات الفرعية Subnets وCIDR وVLSM](https://arabroot.io/articles/%D8%A7%D9%84%D8%B4%D8%A8%D9%83%D8%A7%D8%AA-%D8%A7%D9%84%D9%81%D8%B1%D8%B9%D9%8A%D8%A9-subnets-%D9%88-cidr-%D9%88-vlsm/) بنينا خطة عناوين فيها شبكة للموظفين وأخرى للضيوف وثالثة للكاميرات ورابعة للسيرفرات، وذكرنا أن الشبكة الفرعية حد للأمان، لكن الخطة على الورق لا تمنع شيئاً، فإذا كانت الأجهزة كلها موصولة بنفس ال Switch فالجهاز الذي يغير عنوانه يدخل أي شبكة. وفي هذا المقال سوف نحول الخطة إلى حدود حقيقية، وسوف نناقش ما يلي: - المشكلة: الشبكة المسطحة والحركة الجانبية Lateral Movement وضجيج البث. - الشبكات المحلية الافتراضية VLAN: الوسم 802.1Q ومنافذ Access وTrunk. - التوجيه بين شبكات VLAN وقواعد الجدار الناري Firewall بين المناطق Zones. - الشبكات الفرعية في السحابة: VPC والشبكات العامة والخاصة، وSecurity Groups أمام NACL، والبديل المفتوح في OpenStack. - التقسيم الدقيق Micro-segmentation باختصار. - تجربة عملية كاملة بأدوات Linux: Bridge يفهم VLAN، وRouter بجدار nftables، ومخرجات حقيقية تبين ما يمر وما يمنع. - كيف تبني نفس الفكرة في Proxmox VE SDN وOPNsense وpfSense وOpen vSwitch وDocker. ## المشكلة: كل جهاز يصل إلى كل جهاز الشبكة المسطحة هي الشكل الذي تبدأ به أغلب المكاتب: Router من المزود، وخلفه Switch أو اثنان، وكل الأجهزة في شبكة واحدة مثل `192.168.1.0/24`، أجهزة الموظفين وطابعة المحاسبة ونقطة الوصول للضيوف وكاميرات المراقبة وقاعدة البيانات. وهذا الشكل يعمل ولا يشتكي منه أحد، والصورة التالية تبين لماذا هو خطر: ![شبكة واحدة 192.168.1.0/24 حول Switch عليه دوائر بث، ومتصل به Staff PCs وAccounting وGuest Wi-Fi وIP camera حمراء وDatabase وFile server. مهاجم يدخل الكاميرا في الخطوة 1، ثم من الكاميرا سهم أحمر إلى قاعدة البيانات على المنفذ 5432 في الخطوة 2، وسهم إلى سيرفر الملفات على SMB 445 في الخطوة 3، وسهم منحن إلى أجهزة الموظفين مكتوب عليه scan في الخطوة 4](https://arabroot.io/content/images/2026/10/network-segmentation-01-flat-network.webp) أضعف جهاز في الشبكة المسطحة هو باب الشبكة كلها وفي الشكل أعلاه لاحظ ثلاث مشكلات: - **الحركة الجانبية Lateral Movement**: المهاجم لا يحتاج أن يخترق الهدف من الإنترنت، وإنما يكفيه أي جهاز داخلي، ثم ينتقل منه إلى غيره، وأسهل الأجهزة اختراقاً هي التي لا يحدثها أحد: الكاميرات والطابعات وأجهزة إنترنت الأشياء IoT، وهي نفسها الأجهزة التي لا تحتاج أن تكلم قاعدة البيانات أبداً. - **لا يوجد مكان للقاعدة**: الحركة بين جهازين في نفس الشبكة تمر على ال Switch فقط، وال Switch العادي لا يطبق قواعد، فلا يوجد مكان تكتب فيه «الكاميرات لا تكلم السيرفرات»، ولا مكان تسجل فيه المحاولة. - **ضجيج البث Broadcast**: كل طلب ARP وDHCP وكل رسائل الاكتشاف من الطابعات والتلفزيونات تصل إلى كل جهاز، وهذا أيضاً ما يجعل الجهاز المخترق يعرف جيرانه دون أن يفحص الشبكة. 📌 في [تقرير S-RM المنشور في 5 مارس 2025](https://www.s-rminform.com/latest-thinking/camera-off-akira-deploys-ransomware-via-webcam?ref=arabroot.io) دخل المهاجمون شبكة الضحية عبر حل للوصول عن بعد معرض للإنترنت، وثبتوا AnyDesk للبقاء، ثم أوقف برنامج الحماية EDR على سيرفر Windows ملف برنامج الفدية، فبحثوا في الشبكة ووجدوا كاميرا ويب تعمل بنظام Linux خفيف فيها ثغرات تسمح بتنفيذ الأوامر عن بعد، فشغلوا عليها نسخة Linux من برنامج الفدية، وشفروا الملفات على السيرفر عبر حركة SMB من الكاميرا، ولم ينتبه أحد لأن الكاميرا لا يوجد عليها أي برنامج حماية، وبسبب مساحتها المحدودة يشك التقرير أن يمكن تثبيته أصلاً. وأول توصية في التقرير: ضع أجهزة إنترنت الأشياء في شبكة مقسمة لا يمكن الوصول إليها من السيرفرات أو أجهزة المستخدمين. والحل بالطبع ليس أن نشتري Switch لكل مجموعة ونمد كابلات منفصلة، وهي الطريقة البسيطة التي تعمل في مكتب صغير جداً وتنهار عندما تكون كاميرا وحاسوب موظف وضيف في نفس الغرفة، والحل الذي تستخدمه كل الشبكات اليوم هو أن نقسم ال Switch الواحد إلى عدة شبكات منطقية، وهذا هو VLAN. ## الشبكات المحلية الافتراضية VLAN: Switch واحد وعدة شبكات الشبكة المحلية الافتراضية Virtual LAN، واختصاراً VLAN، هي مجموعة منافذ على Switch واحد أو أكثر تتصرف كأنها Switch مستقل: البث لا يخرج منها، والجهاز فيها لا يرى أجهزة VLAN أخرى على مستوى الطبقة الثانية Layer 2، حتى لو غير عنوان IP الخاص به كما سنرى في التجربة. وكل VLAN يأخذ رقماً، وتعرف الشبكة إلى أي VLAN ينتمي كل إطار Frame بوسم Tag يضاف إليه وفق المعيار IEEE 802.1Q، والصورة التالية تبين أين يوضع: ![إطار Ethernet بلا وسم فيه Dest MAC وSrc MAC وEtherType 0x0800 وPayload وFCS، وتحته نفس الإطار موسوماً وفيه صندوق برتقالي 802.1Q tag من 4 بايتات بعد Src MAC، ثم تفصيل الوسم: TPID بقيمة 0x8100 من 16 بتاً، وPCP من 3 بتات، وDEI بت واحد، وVID أي VLAN ID من 12 بتاً من 1 إلى 4094](https://arabroot.io/content/images/2026/10/network-segmentation-02-vlan-tag.webp) أربعة بايتات بعد عنوان المرسل، وأهم ما فيها رقم ال VLAN الوسم أربعة بايتات: أول 16 بتاً قيمتها `0x8100` وتقول للجهاز «هذا إطار موسوم»، ثم 3 بتات للأولوية PCP التي تستخدمها جودة الخدمة QoS، ثم بت DEI، ثم 12 بتاً لرقم ال VLAN، أي 4096 قيمة، و0 و4095 محجوزتان، لذلك تقول [وثائق pfSense](https://docs.netgate.com/pfsense/en/latest/vlan/configuration.html?ref=arabroot.io) و[وثائق OPNsense](https://docs.opnsense.org/manual/other-interfaces.html?ref=arabroot.io) إن رقم ال VLAN بين 1 و4094\. وسوف ترى هذا الوسم بعينك في مخرج `tcpdump` في التجربة. ### منفذ Access ومنفذ Trunk الحاسوب والكاميرا والطابعة لا تعرف شيئاً عن الوسم، ولا ينبغي أن تعرف، لذلك يقسم ال Switch منافذه إلى نوعين: - **منفذ Access**: ينتمي إلى VLAN واحد، وهذا الرقم يسمى PVID أي Port VLAN ID، فال Switch يضيف الوسم على كل إطار يدخل من المنفذ، ويزيله من كل إطار يخرج إليه، والجهاز في الطرف الآخر يرى شبكة عادية. - **منفذ Trunk**: يحمل عدة شبكات VLAN على كابل واحد، والإطارات عليه موسومة حتى يعرف الطرف الآخر لمن كل إطار، وتقول [وثائق Open vSwitch](https://docs.openvswitch.org/en/latest/faq/vlan/?ref=arabroot.io) إن منفذ Trunk يوصل عادة بجهاز Switch آخر أو Router وليس بجهاز عادي، لأن الأجهزة العادية لا تتوقع وسماً في الحركة التي تستقبلها. والصورة التالية تبين كيف يعبر إطار من الكاميرا في VLAN 30 إلى السيرفر في VLAN 40: ![Switch في الوسط وتحته أربعة كابلات ملونة إلى Staff PC على access VLAN 10، وGuest phone على access VLAN 20، وCamera على access VLAN 30، وServer على access VLAN 40، وفوقه كابل Trunk فيه أربعة ألوان مكتوب عليه tagged 10,20,30,40 إلى Router / Firewall له الواجهات eth0.10 وeth0.20 وeth0.30 وeth0.40. وخمس خطوات مرقمة: الكاميرا ترسل إطاراً بلا وسم، ال Switch يضيف الوسم 30، ال Trunk يحمله إلى ال Router، ال Router يطبق القواعد ثم يرسله بالوسم 40، ال Switch يزيل الوسم قبل منفذ السيرفر](https://arabroot.io/content/images/2026/10/network-segmentation-03-access-trunk.webp) الأجهزة لا ترى الوسم، والعبور بين شبكات VLAN يمر دائماً على ال Router وقد شرحنا ال Switch المدار Managed Switch وما يضيفه في [المودم والراوتر والسويتش](https://arabroot.io/articles/%D8%A7%D9%84%D9%85%D9%88%D8%AF%D9%85-%D9%88%D8%A7%D9%84%D8%B1%D8%A7%D9%88%D8%AA%D8%B1-%D9%88%D8%A7%D9%84%D8%B3%D9%88%D9%8A%D8%AA%D8%B4-%D9%85%D8%A7-%D8%A7%D9%84%D9%81%D8%B1%D9%82-%D8%A8%D9%8A%D9%86%D9%87%D8%A7/#switch)، وإعداد هذه المنافذ على أجهزة MikroTik بالأوامر في [VLANs على السويتش المدمج](https://arabroot.io/articles/mikrotik-%D9%81%D9%8A-%D8%A7%D9%84%D9%88%D8%A7%D9%82%D8%B9-%D8%B4%D8%A8%D9%83%D8%A9-%D8%A7%D9%84%D8%B6%D9%8A%D9%88%D9%81-%D9%88vlan-%D9%88%D8%A7%D9%84vpn-%D9%88%D8%AA%D9%88%D8%AC%D9%8A%D9%87-%D8%A7%D9%84%D9%85%D9%86%D8%A7%D9%81%D8%B0/#vlan-filtering). والقاعدة المهمة هنا: ال VLAN يفصل في الطبقة الثانية فقط، والجدار الناري هو الذي يقرر ما يعبر بين الشبكات، وهذا موضوع القسم التالي. ## التوجيه بين شبكات VLAN وقواعد الجدار الناري كل VLAN شبكة فرعية مستقلة لها بوابتها، والبوابة عادة واجهة فرعية Sub-interface على ال Router أو الجدار الناري تستقبل ال Trunk، فتصبح `eth0.10` بوابة الموظفين و`eth0.30` بوابة الكاميرات، وهذا الشكل يسمى أحياناً Router on a Stick لأن كل الشبكات تصل إليه على كابل واحد. وفي الشبكات الأكبر يقوم Switch من الطبقة الثالثة Layer 3 Switch بالتوجيه بسرعة العتاد، لكن الفكرة واحدة: الحركة بين شبكتين تمر على جهاز يستطيع أن يطبق قواعد. وهنا يقع أهم خطأ في الموضوع: أن تقسم الشبكة إلى VLANs ثم تترك ال Router يوجه بينها كل شيء، فهو بطبيعته يوصل الشبكات المتصلة به، والنتيجة أن الكاميرا ما زالت تصل إلى قاعدة البيانات، لكن عبر ال Router هذه المرة، وسوف نرى هذا بالمخرج في التجربة. لذلك الخطوة الثانية دائماً جدول التدفقات المسموحة: من يكلم من، وعلى أي منفذ، ولماذا، والصورة التالية تبين مثالاً للمناطق الخمس في خطتنا: ![مصفوفة صفوفها المصدر Staff 10 وGuests 20 وCameras 30 وServers 40 وMgmt 99، وأعمدتها الوجهة نفس المناطق مع Internet. خانات خضراء: Staff إلى Servers على tcp/443 وإلى الإنترنت web، وGuests إلى الإنترنت web، وCameras إلى Servers على NVR tcp/554، وServers إلى الإنترنت updates، وMgmt إلى Staff وGuests وServers على ssh وإلى Cameras على https. وكل الخانات الأخرى حمراء عليها علامة منع، وخانات القطر رمادية مكتوب فيها same zone](https://arabroot.io/content/images/2026/10/network-segmentation-04-zone-matrix.webp) الرفض هو الأصل، وكل خانة خضراء استثناء له سبب في الجدول أعلاه لاحظ التالي: - الكاميرات لا تكلم إلا مسجل الفيديو NVR على منفذ RTSP، ولا تخرج إلى الإنترنت، فإذا احتاجت الشركة المصنعة إلى خدمة سحابية فهذا قرار يكتب سببه. - الضيوف يصلون إلى الإنترنت فقط، ولا يصلون حتى إلى صفحة إدارة ال Router، وهذا ما بنيناه في [شبكة الضيوف على MikroTik](https://arabroot.io/articles/mikrotik-%D9%81%D9%8A-%D8%A7%D9%84%D9%88%D8%A7%D9%82%D8%B9-%D8%B4%D8%A8%D9%83%D8%A9-%D8%A7%D9%84%D8%B6%D9%8A%D9%88%D9%81-%D9%88vlan-%D9%88%D8%A7%D9%84vpn-%D9%88%D8%AA%D9%88%D8%AC%D9%8A%D9%87-%D8%A7%D9%84%D9%85%D9%86%D8%A7%D9%81%D8%B0/#guest-network). - شبكة الإدارة Management هي الوحيدة التي تصل إلى واجهات إدارة الأجهزة، ولا يصل إليها أحد من الشبكات الأخرى، فسرقة حاسوب موظف لا تعطي المهاجم لوحة ال Switch. - الخانات الرمادية داخل نفس المنطقة مفتوحة في هذا التصميم، وسنعود إليها في قسم التقسيم الدقيق. ومناطق التطبيقات نفسها، أي ال DMZ ومنطقة التطبيق ومنطقة البيانات، وما تطلبه الضوابط الأساسية للأمن السيبراني في البند 2-15-3-2 من المعمارية متعددة المستويات، شرحناها بالتفصيل وبتجربة عملية في [المعمارية متعددة الطبقات Tiers وLayers](https://arabroot.io/articles/%D8%A7%D9%84%D9%85%D8%B9%D9%85%D8%A7%D8%B1%D9%8A%D8%A9-%D9%85%D8%AA%D8%B9%D8%AF%D8%AF%D8%A9-%D8%A7%D9%84%D8%B7%D8%A8%D9%82%D8%A7%D8%AA-tiers-%D9%88-layers/#in-practice)، أما عزل الشبكات وتقسيمها عموماً فهو في مكون إدارة أمن الشبكات 2-5 الذي لخصناه في [الضوابط الأساسية للأمن السيبراني NCA ECC](https://arabroot.io/articles/%D8%A7%D9%84%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%84%D8%A7%D8%B3%D8%A7%D8%B3%D9%8A%D8%A9-%D9%84%D9%84%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D9%8A%D8%A8%D8%B1%D8%A7%D9%86%D9%8A-nca-ecc-%D8%A8%D9%84%D8%BA%D8%A9-%D8%A8%D8%B3%D9%8A%D8%B7%D8%A9/#defense)، وجدول التدفقات أعلاه هو الدليل الذي يطلبه المدقق في الحالتين. أما كتابة القواعد نفسها على RouterOS بالسلاسل وتتبع الاتصالات فهي في [جدار الحماية في MikroTik RouterOS بالتفصيل](https://arabroot.io/articles/%D8%AC%D8%AF%D8%A7%D8%B1-%D8%A7%D9%84%D8%AD%D9%85%D8%A7%D9%8A%D8%A9-%D9%81%D9%8A-mikrotik-routeros-%D8%A8%D8%A7%D9%84%D8%AA%D9%81%D8%B5%D9%8A%D9%84/). ## الشبكات الفرعية في السحابة: VPC في السحابة لا توجد VLANs تراها، لكن الفكرة نفسها موجودة باسم آخر: الشبكة الافتراضية الخاصة Virtual Private Cloud، واختصاراً VPC، وتعرفها [وثائق AWS](https://docs.aws.amazon.com/vpc/latest/userguide/infrastructure-security.html?ref=arabroot.io) بأنها شبكة افتراضية في منطقة معزولة منطقياً من السحابة، وتنصح باستخدام الشبكات الفرعية لعزل مستويات التطبيق مثل الويب والتطبيق وقاعدة البيانات داخل VPC واحد. والصورة التالية تبين الشكل المعتاد: ![VPC بالعنوان 10.0.0.0/16 فيه ثلاث شبكات: Public subnet 10.0.1.0/24 فيها Load balancer وNAT gateway، وPrivate subnet 10.0.2.0/24 فيها نسختان من التطبيق داخل مربعات security group متقطعة، وIsolated subnet 10.0.3.0/24 فيها Database داخل security group مكتوب تحتها SG: 5432 from app SG. الإنترنت يدخل عبر IGW على 443 إلى ال Load balancer ثم 8000 إلى التطبيق ثم 5432 إلى قاعدة البيانات، والتطبيق يخرج عبر NAT gateway فقط، وسهم أحمر متقطع من الإنترنت إلى قاعدة البيانات عليه علامة منع، وعلى حد كل شبكة شريط NACL](https://arabroot.io/content/images/2026/10/network-segmentation-05-cloud-vpc.webp) نوع الشبكة يحدده جدول التوجيه، والحماية على طبقتين: NACL للشبكة وSecurity Group للجهاز وتقول [صفحة الشبكات الفرعية في AWS](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html?ref=arabroot.io) إن نوع الشبكة يحدده جدول التوجيه: الشبكة العامة Public Subnet لها مسار مباشر إلى بوابة الإنترنت Internet Gateway، والخاصة Private Subnet لا يوجد لها هذا المسار وتحتاج جهاز NAT لتخرج إلى الإنترنت، والمعزولة Isolated Subnet لا يوجد لها مسار خارج ال VPC أصلاً. ثم تأتي طبقتان من القواعد، والجدول التالي من نفس الوثائق: | | Security Group | Network ACL | | ------------- | ------------------------- | ------------------------------- | | أين يعمل | على مستوى الجهاز Instance | على مستوى الشبكة الفرعية Subnet | | نوع القواعد | سماح فقط | سماح ورفض | | طريقة التقييم | يقيم كل القواعد ثم يقرر | بالترتيب حتى أول قاعدة مطابقة | | الرد | مسموح تلقائياً Stateful | يجب السماح به صراحة Stateless | وتنصح AWS بأن تكون Security Groups الوسيلة الأساسية، لأنها تتبع الاتصالات وتستطيع أن تشير إلى Security Group أخرى، فتكتب «قاعدة البيانات تقبل 5432 من مجموعة التطبيق» بدل قائمة عناوين تتغير مع كل نسخة جديدة، وأن تستخدم NACL كطبقة ثانية خشنة على حدود الشبكة. ولاحظ أن ال NACL الافتراضي يسمح بكل شيء، وأن AWS تحجز خمسة عناوين في كل Subnet كما ذكرنا في مقال الشبكات الفرعية. وإذا كنت تبني سحابتك الخاصة فالمفاهيم نفسها موجودة في OpenStack: تقول [وثائق Neutron](https://docs.openstack.org/neutron/latest/admin/intro-os-networking.html?ref=arabroot.io) إن الشبكة الفرعية كتلة عناوين مع إعدادها، وإن ال Router الافتراضي يوجه بين الشبكات ويطبق NAT، وإن Security Groups فيها رفض افتراضي ولا تحتوي إلا قواعد سماح، وإنها Stateful، وإن كل منفذ Port يمكن أن يرتبط بأكثر من مجموعة. فالتصميم الذي ترسمه لسحابة عامة تنقله إلى OpenStack دون تغيير في الفكرة. ## التقسيم الدقيق Micro-segmentation التقسيم إلى مناطق يمنع الكاميرا من الوصول إلى السيرفرات، لكنه يترك السيرفرات داخل منطقتها مفتوحة على بعضها، فإذا اخترق المهاجم سيرفر التقارير وصل إلى سيرفر قاعدة البيانات المجاور، والخطوة التالية هي التقسيم الدقيق: أن يكون لكل خدمة أو حمل عمل Workload سياسة خاصة به، والصورة التالية تبين الفرق: ![لوحتان. في اليمين SEGMENTATION (ZONES): منطقتا App zone وData zone بينهما جدار ناري، وداخل App zone أربع نسخ تطبيق وسهم أحمر متقطع بين اثنتين منها مكتوب تحته inside a zone: all open. وفي اليسار MICRO-SEGMENTATION: كل تطبيق داخل دائرة سياسة خضراء خاصة به، وقاعدة البيانات داخل دائرة، وسهم أخضر واحد مسموح api to db:5432، وعلامة منع بين تطبيقين متجاورين، ومكتوب policy per workload, by label or identity](https://arabroot.io/content/images/2026/10/network-segmentation-07-micro-segmentation.webp) المناطق تمنع العبور بينها، والتقسيم الدقيق يمنع العبور داخل المنطقة ويصف [معيار NIST SP 800-207](https://csrc.nist.gov/pubs/sp/800/207/final?ref=arabroot.io) للثقة المعدومة Zero Trust هذا الأسلوب في القسم 3.1.2: أن تضع كل مورد أو مجموعة صغيرة من الموارد في قطعة شبكة خاصة يحميها مكون بوابة، سواء كان Switch أو Router ذكياً أو جداراً نارياً، أو أن تطبقه على الجهاز نفسه ببرامج وكيلة. وفي التطبيق العملي تراه في ثلاثة أشكال: Security Group لكل دور في السحابة، وسياسات [NetworkPolicy](https://kubernetes.io/docs/concepts/services-networking/network-policies/?ref=arabroot.io) لكل خدمة في Kubernetes، وجدار ناري على كل سيرفر. والترتيب مهم: ابدأ بالمناطق لأنها أرخص وتغلق أكبر الأبواب، ثم أضف التقسيم الدقيق للأنظمة الحساسة، وقد شرحنا فكرة Zero Trust من جهة الوصول في [ما هو VPN؟](https://arabroot.io/articles/%D9%85%D8%A7-%D9%87%D9%88-vpn-%D8%B4%D8%B1%D8%AD-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/#zero-trust). ## تجربة عملية: Switch بشبكات VLAN وجدار ناري بأدوات Linux الآن سوف نبني الفكرة كلها على جهاز واحد بأدوات Linux الأساسية: كل جهاز في الشبكة سيكون Namespace شبكة Network Namespace مستقلاً، وهو نفس ما يعزل به Docker شبكة كل Container، وال Switch سيكون Bridge في Linux يفهم VLAN، وال Router والجدار الناري سيكونان Namespace فيه واجهات VLAN وقواعد [nftables](https://wiki.nftables.org/wiki-nftables/index.php/Main%5FPage?ref=arabroot.io). والصورة التالية تبين ما سنبنيه: ![داخل container lab-seg-lab أربعة صناديق Namespace في الأسفل: staff على 10.20.0.10/25 وguest على 10.20.0.150/26 وcam على 10.20.0.200/27 وsrv على 10.20.0.230/28 مع المنافذ 443 و554 و5432، وكل منها متصل بمنفذ في br0 مكتوب عليه sw-staff pvid 10 وsw-guest pvid 20 وsw-cam pvid 30 وsw-srv pvid 40. وال Bridge مكتوب عليه vlan_filtering 1 وvlan_default_pvid 0، ومنه منفذ sw-router tagged 10,20,30,40 إلى Namespace router فيه eth0.10 إلى eth0.40 وnftables table inet zones. وفي اليمين نتائج: staff إلى srv 443 مسموح، cam إلى srv 554 مسموح، cam إلى srv 5432 ممنوع، cam إلى staff icmp ممنوع، guest إلى srv 443 ممنوع](https://arabroot.io/content/images/2026/10/network-segmentation-06-lab-topology.webp) كل Namespace جهاز، وال Bridge هو ال Switch، وال Namespace router هو الجدار الناري ### تجهيز ال Container كل التجربة داخل Container واحد اسمه `lab-seg-lab`، والصلاحيات الإضافية فيه لا تخرج منه: `NET_ADMIN` لإنشاء الواجهات والقواعد، و`SYS_ADMIN` لأن الأمر `ip netns add` يحتاج أن يركب مجلد `/run/netns`، و`NET_RAW` لأداتي `ping` و`tcpdump`: ```bash docker run -d --name lab-seg-lab --hostname lab-seg --cap-add NET_ADMIN --cap-add SYS_ADMIN --cap-add NET_RAW alpine:3.24 sleep 14400 docker exec lab-seg-lab apk add -q iproute2 nftables tcpdump iputils-ping busybox-extras docker exec -it lab-seg-lab sh ``` وكل الأوامر التالية داخل ال Container. نبدأ بالشكل المسطح: خمسة Namespaces، أربعة منها أجهزة على Bridge عادي في شبكة واحدة `192.168.1.0/24`، والخامس للـ Router الذي نستخدمه بعد قليل، ثم نشغل على السيرفر ثلاث خدمات صغيرة بأداة `httpd` من BusyBox على المنافذ 443 و554 و5432 تمثل الويب ومسجل الفيديو وقاعدة البيانات: ```bash for h in staff guest cam srv router; do ip netns add $h; ip -n $h link set lo up; done ip link add br-flat type bridge ip link set br-flat up i=10 for h in staff guest cam srv; do ip link add sw-$h type veth peer name eth0 netns $h ip link set sw-$h master br-flat up ip -n $h addr add 192.168.1.$i/24 dev eth0 ip -n $h link set eth0 up i=$((i + 10)) done ip netns exec srv sh -c 'for p in 443 554 5432; do mkdir -p /srv/$p; echo "port $p ok" > /srv/$p/index.html; httpd -p $p -h /srv/$p; done' ip netns list ``` والمخرج سوف يكون كما يلي: ```text srv (id: 4) router guest (id: 2) staff (id: 1) cam (id: 3) ``` كل جهاز له Namespace، وفيه واجهة `eth0` طرفها الآخر `sw-NAME` موصول بال Bridge، تماماً مثل كابل من الجهاز إلى منفذ في ال Switch. ### الشبكة المسطحة: الكاميرا تصل إلى قاعدة البيانات نراقب ARP من جهاز الموظف، ثم نجعل الكاميرا تطلب منفذ قاعدة البيانات وترسل ping إلى هاتف الضيف: ```bash ip netns exec staff tcpdump -l -n -i eth0 arp 2>/dev/null & sleep 1 ip netns exec cam wget -qO- http://192.168.1.40:5432/ ip netns exec cam ping -c 1 -W 1 192.168.1.20 > /dev/null sleep 1; kill %1 ip -n cam neigh show ``` والمخرج سوف يكون كما يلي: ```text port 5432 ok 10:28:34.489124 ARP, Request who-has 192.168.1.40 tell 192.168.1.30, length 28 10:28:34.494140 ARP, Request who-has 192.168.1.20 tell 192.168.1.30, length 28 192.168.1.20 dev eth0 lladdr 16:cb:40:73:5c:35 REACHABLE 192.168.1.40 dev eth0 lladdr 5e:e6:ac:df:00:86 REACHABLE ``` في المخرج أعلاه لاحظ التالي: - الكاميرا فتحت منفذ قاعدة البيانات مباشرة، ولا يوجد أي جهاز في الطريق يمكن أن يمنعها. - جهاز الموظف `192.168.1.10` رأى طلبي ARP اللذين أرسلتهما الكاميرا لتسأل عن السيرفر وعن هاتف الضيف، مع أنهما لا يخصانه، وهذا هو نطاق البث المشترك. - جدول الجيران في الكاميرا فيه الآن عنوانا MAC للجهازين، أي أن الجهاز المخترق يتعرف على جيرانه من الحركة العادية. ### تقسيم ال Bridge إلى شبكات VLAN الآن نحذف الشبكة المسطحة ونبني Bridge يفهم VLAN، ونضع كل جهاز في منفذ Access بالرقم والعنوان الذي في خطة العناوين، ونجعل منفذ ال Router منفذ Trunk يحمل الشبكات الأربع: ```bash for h in staff guest cam srv; do ip link del sw-$h; done ip link del br-flat ip link add br0 type bridge vlan_filtering 1 vlan_default_pvid 0 ip link set br0 up set -- staff 10 10.20.0.10/25 10.20.0.1 \ guest 20 10.20.0.150/26 10.20.0.129 \ cam 30 10.20.0.200/27 10.20.0.193 \ srv 40 10.20.0.230/28 10.20.0.225 while [ $# -gt 0 ]; do h=$1 vid=$2 addr=$3 gw=$4; shift 4 ip link add sw-$h type veth peer name eth0 netns $h ip link set sw-$h master br0 up bridge vlan add dev sw-$h vid $vid pvid untagged ip -n $h addr add $addr dev eth0 ip -n $h link set eth0 up ip -n $h route add default via $gw done ip link add sw-router type veth peer name eth0 netns router ip link set sw-router master br0 up for vid in 10 20 30 40; do bridge vlan add dev sw-router vid $vid; done bridge vlan show ``` والمخرج سوف يكون كما يلي: ```text port vlan-id sw-staff 10 PVID Egress Untagged sw-guest 20 PVID Egress Untagged sw-cam 30 PVID Egress Untagged sw-srv 40 PVID Egress Untagged sw-router 10 20 30 40 ``` في الإعداد أعلاه لاحظ التالي: - `vlan_filtering 1` هو ما يجعل ال Bridge يحترم أرقام VLAN، وبدونه يمرر كل الإطارات بين كل المنافذ، والخيارات موثقة في [صفحة ip-link](https://man7.org/linux/man-pages/man8/ip-link.8.html?ref=arabroot.io). - `vlan_default_pvid 0` يمنع ال Bridge من وضع كل منفذ جديد في VLAN 1 تلقائياً، وهذه نفس المشكلة التي يحذر منها توثيق MikroTik: شبكة افتراضية لم يقصدها أحد تصبح باباً مفتوحاً بين المنافذ. - `pvid untagged` في [الأمر bridge](https://man7.org/linux/man-pages/man8/bridge.8.html?ref=arabroot.io) يجعل المنفذ Access: الإطار الداخل بلا وسم يأخذ رقم المنفذ، والخارج إليه يفقد الوسم، وفي المخرج تراها `PVID Egress Untagged`. - منفذ `sw-router` عضو في الشبكات الأربع بلا `untagged`، أي أن الإطارات عليه موسومة، وهذا هو ال Trunk. ثم نعطي ال Router واجهة VLAN لكل شبكة، وعليها عنوان البوابة: ```bash ip -n router link set eth0 up set -- 10 10.20.0.1/25 20 10.20.0.129/26 30 10.20.0.193/27 40 10.20.0.225/28 while [ $# -gt 0 ]; do ip -n router link add link eth0 name eth0.$1 type vlan id $1 ip -n router addr add $2 dev eth0.$1 ip -n router link set eth0.$1 up shift 2 done ip -n router -br -4 addr show ip -n router route ip netns exec router sysctl net.ipv4.ip_forward ``` والمخرج سوف يكون كما يلي: ```text lo UNKNOWN 127.0.0.1/8 eth0.10@eth0 UNKNOWN 10.20.0.1/25 eth0.20@eth0 UNKNOWN 10.20.0.129/26 eth0.30@eth0 UNKNOWN 10.20.0.193/27 eth0.40@eth0 UNKNOWN 10.20.0.225/28 10.20.0.0/25 dev eth0.10 proto kernel scope link src 10.20.0.1 10.20.0.128/26 dev eth0.20 proto kernel scope link src 10.20.0.129 10.20.0.192/27 dev eth0.30 proto kernel scope link src 10.20.0.193 10.20.0.224/28 dev eth0.40 proto kernel scope link src 10.20.0.225 net.ipv4.ip_forward = 1 ``` لكل شبكة مسار متصل Connected Route أضافته النواة من العنوان وطوله، والتمرير بين الواجهات `ip_forward` مفعل في بيئتنا أصلاً، أما على سيرفر Linux حقيقي تجعله Router فتفعله بالأمر `sysctl -w net.ipv4.ip_forward=1` وتحفظه في ملف داخل `/etc/sysctl.d/`، ولا يمكن تغييره من داخل Container لأن Docker يجعل `/proc/sys` للقراءة فقط. ### VLAN بلا قواعد: الكاميرا ما زالت تصل نكتب دالة صغيرة تختبر الاتصال من جهاز إلى عنوان ومنفذ، أو ping إذا كتبنا `icmp`، ونختبر قبل أن نكتب أي قاعدة: ```bash t() { if [ "$3" = icmp ]; then ip netns exec $1 ping -c 1 -W 2 $2 > /dev/null 2>&1 else ip netns exec $1 nc -z -w 2 $2 $3 2>/dev/null; fi if [ $? = 0 ]; then r=open; else r=blocked; fi printf '%-6s -> %-11s %-9s %s\n' $1 $2 $3 $r } t staff 10.20.0.230 443 t cam 10.20.0.230 5432 t guest 10.20.0.230 5432 t cam 10.20.0.10 icmp ``` والمخرج سوف يكون كما يلي: ```text staff -> 10.20.0.230 443 open cam -> 10.20.0.230 5432 open guest -> 10.20.0.230 5432 open cam -> 10.20.0.10 icmp open ``` كل شيء مفتوح، وهذا هو الخطأ الذي ذكرناه: قسمنا الشبكة إلى أربع شبكات VLAN، لكن ال Router يوجه بينها كل شيء. ولنرى الوسم على ال Trunk ونحن نرسل ping من الكاميرا إلى السيرفر: ```bash tcpdump -e -n -l -i sw-router icmp 2>/dev/null & sleep 1 ip netns exec cam ping -c 1 -W 1 10.20.0.230 > /dev/null sleep 1; kill %1 ``` والمخرج سوف يكون كما يلي: ```text 10:28:40.094370 ce:2f:84:67:16:b9 > 56:28:19:dc:5e:d1, ethertype 802.1Q (0x8100), length 102: vlan 30, p 0, ethertype IPv4 (0x0800), 10.20.0.200 > 10.20.0.230: ICMP echo request, id 164, seq 1, length 64 10:28:40.094395 56:28:19:dc:5e:d1 > 0a:b8:a8:65:8d:67, ethertype 802.1Q (0x8100), length 102: vlan 40, p 0, ethertype IPv4 (0x0800), 10.20.0.200 > 10.20.0.230: ICMP echo request, id 164, seq 1, length 64 10:28:40.094512 0a:b8:a8:65:8d:67 > 56:28:19:dc:5e:d1, ethertype 802.1Q (0x8100), length 102: vlan 40, p 0, ethertype IPv4 (0x0800), 10.20.0.230 > 10.20.0.200: ICMP echo reply, id 164, seq 1, length 64 10:28:40.094518 56:28:19:dc:5e:d1 > ce:2f:84:67:16:b9, ethertype 802.1Q (0x8100), length 102: vlan 30, p 0, ethertype IPv4 (0x0800), 10.20.0.230 > 10.20.0.200: ICMP echo reply, id 164, seq 1, length 64 ``` هذه نفس الخطوات في صورة منافذ Access وTrunk: الطلب يصل إلى ال Router موسوماً `vlan 30` بقيمة `0x8100` التي رأيناها في الوسم، ثم يخرج منه نحو السيرفر موسوماً `vlan 40`، والرد يعود بالعكس، ولاحظ أن عنوان MAC المرسل في السطر الثاني هو عنوان ال Router نفسه `56:28:19:dc:5e:d1`، أي أن العبور حدث في الطبقة الثالثة وليس في ال Switch. وقد يتساءل البعض: إذا غيرت الكاميرا عنوانها إلى عنوان في شبكة السيرفرات، ألا تصل إلى السيرفر مباشرة دون ال Router؟ لنجرب ذلك ثم نعيد عنوانها: ```bash ip -n cam addr flush dev eth0 ip -n cam addr add 10.20.0.231/28 dev eth0 ip netns exec cam ping -c 2 -W 1 10.20.0.230 ip -n cam neigh show ip -n cam addr flush dev eth0 ip -n cam addr add 10.20.0.200/27 dev eth0 ip -n cam route add default via 10.20.0.193 ``` والمخرج سوف يكون كما يلي: ```text PING 10.20.0.230 (10.20.0.230) 56(84) bytes of data. --- 10.20.0.230 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1062ms 10.20.0.230 dev eth0 INCOMPLETE ``` الحالة `INCOMPLETE` تعني أن طلب ARP لم يجد من يجيب، لأنه خرج من منفذ الكاميرا موسوماً 30 ولم يصل إلى أي منفذ في VLAN 40، وهذا هو الفرق بين الشبكة الفرعية وحدها والشبكة الفرعية فوق VLAN: العنوان يكتبه الجهاز بنفسه، أما رقم ال VLAN فيحدده المنفذ في ال Switch ولا يملك الجهاز تغييره. ### جدار ناري بين المناطق بـ nftables الآن نكتب القواعد في الملف `/root/zones.nft`، ونطبق منها جزءاً من جدول التدفقات: الموظفون يصلون إلى السيرفرات على 443، والكاميرات تصل إلى مسجل الفيديو على 554، وكل ما عدا ذلك بين المناطق مرفوض: ```bash cat > /root/zones.nft <<'EOF' flush ruleset define STAFF = "eth0.10" define GUESTS = "eth0.20" define CAMERAS = "eth0.30" define SERVERS = "eth0.40" define NVR = 10.20.0.230 table inet zones { chain input { type filter hook input priority filter; policy drop; ct state established,related accept iif "lo" accept icmp type echo-request limit rate 5/second accept iifname $STAFF tcp dport 22 accept comment "admin from staff only" counter comment "dropped to the router itself" } chain forward { type filter hook forward priority filter; policy drop; ct state established,related accept ct state invalid drop iifname $STAFF oifname $SERVERS tcp dport 443 accept comment "staff -> servers: https" iifname $CAMERAS oifname $SERVERS ip daddr $NVR tcp dport 554 accept comment "cameras -> NVR: rtsp" counter comment "dropped between zones" } } EOF ip netns exec router nft -f /root/zones.nft t staff 10.20.0.230 443 t staff 10.20.0.230 5432 t cam 10.20.0.230 554 t cam 10.20.0.230 5432 t cam 10.20.0.10 icmp t guest 10.20.0.230 443 t guest 10.20.0.129 icmp ``` والمخرج سوف يكون كما يلي: ```text staff -> 10.20.0.230 443 open staff -> 10.20.0.230 5432 blocked cam -> 10.20.0.230 554 open cam -> 10.20.0.230 5432 blocked cam -> 10.20.0.10 icmp blocked guest -> 10.20.0.230 443 blocked guest -> 10.20.0.129 icmp open ``` في الإعداد أعلاه لاحظ التالي: - السلسلة `forward` هي ما يمر عبر ال Router بين الشبكات، وسياستها `drop`، فكل ما لم نسمح به صراحة مرفوض، وهذا هو جدول التدفقات بالكود. - السطر `ct state established,related accept` يسمح بالردود على الاتصالات المسموحة، وهو ما يجعل الجدار الناري Stateful مثل Security Groups في السحابة. - القواعد تكتب بأسماء الواجهات، أي بالمناطق وليس بالعناوين، فإضافة كاميرا جديدة لا تحتاج تغيير أي قاعدة، أما قاعدة الكاميرات فمحددة بعنوان مسجل الفيديو حتى لا تفتح بقية السيرفرات. - السلسلة `input` تحمي ال Router نفسه: الضيف يستطيع أن يرسل ping إلى بوابته، لكنه لا يصل إلى أي منفذ إدارة، و SSH مسموح من شبكة الموظفين فقط. - الكاميرا ما زالت تصل إلى مسجل الفيديو على 554 لأن هذا عملها، ولا تصل إلى 5432 على نفس السيرفر. والآن نرى العدادات التي تسجل ما رفض: ```bash ip netns exec router nft list chain inet zones forward ``` والمخرج سوف يكون كما يلي: ```text table inet zones { chain forward { type filter hook forward priority filter; policy drop; ct state established,related accept ct state invalid drop iifname "eth0.10" oifname "eth0.40" tcp dport 443 accept comment "staff -> servers: https" iifname "eth0.30" oifname "eth0.40" ip daddr 10.20.0.230 tcp dport 554 accept comment "cameras -> NVR: rtsp" counter packets 7 bytes 444 comment "dropped between zones" } } ``` سبع حزم رفضت بين المناطق، وهي محاولات الاتصال الممنوعة في الاختبار. وفي الإنتاج تضيف إلى هذا السطر `log prefix "zone-drop "` وترسل السجلات إلى نظام المراقبة، لأن كاميرا تحاول الوصول إلى 5432 علامة على اختراق يجب أن يراها أحد فوراً. ### نكسر القاعدة: نسيان تتبع الاتصالات خطأ شائع عند كتابة القواعد أول مرة أن تنسى سطر الاتصالات القائمة، فنحذفه ونرى ماذا يحدث لاتصال مسموح: ```bash ip netns exec router nft -a list chain inet zones forward | grep "ct state established" ip netns exec router nft delete rule inet zones forward handle 8 t staff 10.20.0.230 443 ip netns exec staff wget -T 3 -qO- http://10.20.0.230:443/; echo "exit=$?" ``` والمخرج سوف يكون كما يلي: ```text ct state established,related accept # handle 8 staff -> 10.20.0.230 443 blocked wget: download timed out exit=1 ``` الطلب من الموظف إلى السيرفر مسموح، لكن الرد من السيرفر إلى الموظف يدخل من `eth0.40` ويخرج إلى `eth0.10`، ولا توجد قاعدة تسمح بهذا الاتجاه، فيرفض وينتهي الاتصال بانتهاء المهلة. وهذا بالضبط سلوك NACL في AWS الذي لا يتبع الاتصالات، لذلك إذا رأيت اتصالاً «مسموحاً» ينتهي بمهلة فابحث عن قاعدة الرد. ونعيد الملف كاملاً لنرجع إلى الإعداد الصحيح: ```bash ip netns exec router nft -f /root/zones.nft t staff 10.20.0.230 443 ``` والمخرج سوف يكون كما يلي: ```text staff -> 10.20.0.230 443 open ``` ولاحظ أن السطر `flush ruleset` في أول الملف يجعل تطبيقه آمناً للتكرار، فكل تطبيق يبدأ من الصفر بدل أن يضيف القواعد مرة ثانية. ### التنظيف كل ما أنشأناه داخل ال Container، فنخرج منه ونحذفه بالاسم: ```bash exit docker rm -f lab-seg-lab ``` ## كيف تبنيه في بيئتك بأدوات مفتوحة المصدر؟ التجربة السابقة هي نفس ما تفعله الأدوات التالية من الداخل، والفرق أنها تحفظ الإعداد وتعطيك واجهة لإدارته. ### سيرفر Linux بواجهتين إذا كان عندك سيرفر Linux بين ال Switch والإنترنت فالأوامر نفسها تعمل عليه، مع واجهة فيزيائية مكان `eth0`: واجهات `type vlan` فوق المنفذ الموصول بمنفذ Trunk في ال Switch، والتمرير مفعل في `/etc/sysctl.d/`، وملف القواعد في `/etc/nftables.conf` مع تفعيل خدمة `nftables`، والواجهات في `/etc/network/interfaces` أو Netplan بحسب التوزيعة. وإذا كانت الأجهزة الافتراضية على نفس السيرفر فاجعل ال Bridge نفسه يفهم VLAN كما فعلنا. ### Proxmox VE: Bridge يفهم VLAN وSDN في Proxmox VE أبسط طريقة أن تجعل ال Bridge الرئيسي `vmbr0` يفهم VLAN، والمثال التالي من [صفحة إعداد الشبكة في Proxmox](https://pve.proxmox.com/wiki/Network%5FConfiguration?ref=arabroot.io): ```ini auto vmbr0 iface vmbr0 inet manual bridge-ports eno1 bridge-stp off bridge-fd 0 bridge-vlan-aware yes bridge-vids 2-4094 ``` وبعدها تكتب رقم ال VLAN في حقل VLAN Tag في إعداد بطاقة الشبكة لكل VM أو Container، فيضعه Proxmox في منفذ Access بذلك الرقم دون أي إعداد داخل النظام الضيف، وقد شرحنا تبويب الشبكة عند إنشاء VM في [إنشاء أول VM في Proxmox](https://arabroot.io/articles/%D8%A5%D9%86%D8%B4%D8%A7%D8%A1-%D8%A3%D9%88%D9%84-vm-%D9%81%D9%8A-proxmox-%D8%A8%D8%B9%D9%86%D9%88%D8%A7%D9%86-ip-%D8%AB%D8%A7%D8%A8%D8%AA/#tab-network). وعندما يكبر العنقود Cluster يأتي دور الشبكات المعرفة بالبرمجيات SDN، وتقول [وثائق Proxmox SDN](https://pve.proxmox.com/pve-docs/chapter-pvesdn.html?ref=arabroot.io) إن حزمها الأساسية مثبتة افتراضياً منذ الإصدار 8.1، وإنها مبنية على ثلاثة مفاهيم: - **المنطقة Zone**: نوع الفصل، وأنواعها Simple لشبكة معزولة مع توجيه وNAT، وVLAN، وQinQ أي VLAN فوق VLAN بالمعيار 802.1ad، وVXLAN لشبكة طبقة ثانية فوق نفق UDP بين السيرفرات، وEVPN الذي يضيف التوجيه بين الشبكات بـ BGP، ومنطقة VLAN تحتاج Bridge موجوداً من نوع Linux أو OVS على كل عقدة. - **الشبكة الافتراضية VNet**: الشبكة التي توصل بها الأجهزة، وعندما تنشئها تظهر واجهة بنفس الاسم على كل عقدة في العنقود. - **الشبكة الفرعية Subnet**: نطاق CIDR داخل ال VNet مع البوابة، وخيار SNAT في المناطق التي توجه، وتوزيع العناوين على الأجهزة عبر IPAM. والتغييرات تحفظ أولاً كتغييرات معلقة Pending، ثم تطبقها كلها مرة واحدة من شاشة SDN، والإعداد في `/etc/pve/sdn` ويتزامن بين العقد. وتذكر الوثائق أيضاً جدار ناري على مستوى ال VNet، وتنصح فيه بالرفض الافتراضي والسماح فقط بالحركة بين الشبكة الفرعية وبوابتها. ### OPNsense وpfSense: الجدار الناري بين شبكات VLAN إذا أردت جداراً نارياً مستقلاً بواجهة رسومية فالخطوات في الاثنين متشابهة: 1. أنشئ ال VLAN على الواجهة الفيزيائية الموصولة بمنفذ Trunk: في OPNsense من Interfaces ثم Devices ثم VLAN، وفي pfSense من Interfaces ثم Assignments ثم تبويب VLANs، وتختار الواجهة الأم Parent Interface ورقم ال VLAN بين 1 و4094 والأولوية PCP ووصفاً. 2. اربط ال VLAN بواجهة من Interfaces ثم Assignments، ثم فعلها وأعطها عنوان البوابة من خطة العناوين. 3. فعل خدمة DHCP لها إذا احتجت. 4. اكتب قواعدها في تبويب الواجهة في Firewall ثم Rules، وتذكر [وثائق pfSense](https://docs.netgate.com/pfsense/en/latest/vlan/configuration.html?ref=arabroot.io) أن واجهات VLAN تتصرف مثل أي واجهة إضافية، فيجب أن تفعلها وتعدها وتضيف لها قواعد الجدار الناري وتعد خدماتها مثل DHCP، والتفاصيل في [وثائق جدار OPNsense](https://docs.opnsense.org/manual/firewall.html?ref=arabroot.io). وال Switch المدار في هذه الحالة يحمل الشبكات إلى الجدار الناري على منفذ Trunk واحد، وكل منفذ آخر فيه Access بالرقم المناسب، وإذا كان الجدار الناري من MikroTik فقد غطينا ذلك في [MikroTik وRouterOS للمبتدئين](https://arabroot.io/articles/mikrotik-%D9%88-routeros-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-%D8%A7%D9%88%D9%84-%D8%A7%D8%B9%D8%AF%D8%A7%D8%AF-%D8%A7%D9%85%D9%86/) والمقالين بعده. ### Open vSwitch [Open vSwitch](https://www.openvswitch.org/?ref=arabroot.io) هو Switch برمجي يستخدم في OpenStack ويمكن أن يستخدمه Proxmox بدل Bridge لينكس، وفكرة المنافذ فيه نفسها، فالأمر التالي من [أسئلته الشائعة](https://docs.openvswitch.org/en/latest/faq/vlan/?ref=arabroot.io) يضيف منفذاً من نوع Access في VLAN 9: ```bash ovs-vsctl add-port br0 tap0 tag=9 ``` وتحتاجه عادة عندما تريد مزايا لا يقدمها Bridge لينكس، مثل التحكم بالتدفقات OpenFlow أو الأنفاق بين عدة سيرفرات، أما لسيرفر واحد أو عنقود صغير فال Bridge الذي يفهم VLAN يكفي. ### Docker وPodman: شبكات داخلية على سيرفر واحد داخل السيرفر الواحد تفعل شبكات Docker نفس الفصل بين ال Containers: كل شبكة تنشئها Bridge مستقل، والخيار `internal: true` يمنع الشبكة من الخروج، وال Container لا يرى إلا الشبكات التي وصلته بها، وقد شرحنا ذلك في [شبكات Docker وأفضل الممارسات](https://arabroot.io/articles/%D8%B4%D8%A8%D9%83%D8%A7%D8%AA-docker-%D9%88%D8%A3%D9%81%D8%B6%D9%84-%D8%A7%D9%84%D9%85%D9%85%D8%A7%D8%B1%D8%B3%D8%A7%D8%AA/#network-drivers)، وبنينا به ثلاث مناطق DMZ وتطبيق وبيانات في [تجربة المعمارية متعددة الطبقات](https://arabroot.io/articles/%D8%A7%D9%84%D9%85%D8%B9%D9%85%D8%A7%D8%B1%D9%8A%D8%A9-%D9%85%D8%AA%D8%B9%D8%AF%D8%AF%D8%A9-%D8%A7%D9%84%D8%B7%D8%A8%D9%82%D8%A7%D8%AA-tiers-%D9%88-layers/#lab). وإذا أردت أن يأخذ Container عنواناً في VLAN فعلية على شبكتك فهذا عمل [شبكات macvlan وipvlan](https://arabroot.io/articles/%D8%B4%D8%A8%D9%83%D8%A7%D8%AA-docker-%D9%88%D8%A3%D9%81%D8%B6%D9%84-%D8%A7%D9%84%D9%85%D9%85%D8%A7%D8%B1%D8%B3%D8%A7%D8%AA/#macvlan-ipvlan)، فهي تقبل واجهة أم مثل `eth0.30`. ## أخطاء شائعة - **VLANs بلا قواعد**: كما رأينا في التجربة، ال Router يوجه بين الشبكات كل شيء حتى تكتب سياسة رفض، فالتقسيم بلا جدار ناري يقلل البث فقط. - **VLAN 1 الافتراضية**: ترك المنافذ غير المستخدمة وشبكة الإدارة على VLAN 1، فأي جهاز يوصل بمنفذ فارغ يصل إلى واجهات الإدارة، والأفضل أن تضع المنافذ غير المستخدمة في VLAN لا يوجه إلى أي مكان وتغلقها. - **منفذ Trunk عند المستخدم**: منفذ في مكتب يحمل كل الشبكات موسومة، فيستطيع من يوصل به حاسوباً أن ينشئ واجهات VLAN ويدخل أي شبكة، فالمنافذ عند الأجهزة Access دائماً، وال Trunk فقط بين ال Switches وال Router ونقاط الوصول وسيرفرات الأجهزة الافتراضية. - **نسيان الردود**: قاعدة سماح بلا تتبع للاتصالات كما رأينا، أو NACL في AWS بلا قاعدة للمنافذ المؤقتة Ephemeral Ports. - **قاعدة any مؤقتة**: قاعدة تسمح بكل شيء بين منطقتين لحل مشكلة عاجلة ثم تبقى سنوات، فاكتب لكل قاعدة سببها وتاريخها وراجعها. - **الإدارة من نفس الشبكة**: واجهات إدارة ال Switch والكاميرات وال Hypervisor في شبكة الموظفين، فاختراق حاسوب واحد يعطي المهاجم مفاتيح الشبكة كلها. - **شبكة الضيوف تصل إلى ال Router**: الضيف يصل إلى صفحة إدارة ال Router أو إلى DNS داخلي يكشف أسماء الأجهزة، فاحم سلسلة `input` كما في التجربة. - **تقسيم بلا مراقبة**: قواعد رفض لا يسجل منها شيء، فلا تعرف أن الكاميرا حاولت الوصول إلى قاعدة البيانات إلا بعد الحادثة. ## قائمة التحقق 1. هل لديك خطة عناوين فيها شبكة فرعية ورقم VLAN لكل منطقة، ولا تتداخل مع شبكات الفروع أو ال VPN أو Docker؟ 2. هل أجهزة إنترنت الأشياء والكاميرات في شبكة لا تصل إلى السيرفرات ولا إلى أجهزة الموظفين؟ 3. هل الضيوف في شبكة لا تصل إلا إلى الإنترنت؟ 4. هل واجهات الإدارة في شبكة مستقلة لا يصل إليها إلا المسؤولون، ويفضل عبر VPN؟ 5. هل سياسة الجدار الناري بين المناطق «ارفض كل شيء» مع استثناءات مكتوبة بسببها؟ 6. هل المنافذ عند المستخدمين Access، وال Trunk فقط بين أجهزة الشبكة؟ 7. هل جربت من كل منطقة أن الممنوع ممنوع فعلاً، كما فعلنا في التجربة؟ 8. هل تسجل الحركة المرفوضة بين المناطق وتصل السجلات إلى من يراقبها؟ 9. في السحابة: هل قواعد البيانات في شبكة خاصة أو معزولة، وSecurity Groups تشير إلى بعضها بدل العناوين؟ ## تدريب عملي 1. أضف إلى التجربة Namespace خامساً للإدارة في VLAN 99 بالشبكة `10.20.0.240/28`، واكتب قاعدة تسمح له وحده بالوصول إلى المنفذ 22 على ال Router، ثم اختبر من الموظفين ومن الإدارة. 2. أضف إلى قاعدة الرفض في السلسلة `forward` عبارة `log prefix "zone-drop "` على سيرفر Linux حقيقي أو VM، وجرب الوصول من الكاميرا إلى 5432، ثم ابحث عن السطر بالأمر `journalctl -k | grep zone-drop`. 3. ارسم جدول التدفقات لشبكة مكتبك أو بيتك كما في المصفوفة أعلاه قبل أن تغير أي إعداد. ## الخلاصة وصلنا لنهاية الموضوع، وأهم ما فيه: - في الشبكة المسطحة أضعف جهاز هو باب الشبكة كلها، وحادثة Akira مع كاميرا الويب في 2025 مثال موثق على ذلك. - VLAN يقسم ال Switch الواحد إلى شبكات منفصلة في الطبقة الثانية بوسم 802.1Q من أربعة بايتات، والجهاز لا يستطيع أن يغير ال VLAN الذي يحدده المنفذ. - منافذ الأجهزة Access، وال Trunk يحمل الشبكات موسومة بين أجهزة الشبكة فقط. - ال VLAN وحده لا يمنع شيئاً إذا كان ال Router يوجه بين الشبكات، والقرار في الجدار الناري بسياسة رفض واستثناءات مكتوبة. - في السحابة نفس الفكرة بالشبكات العامة والخاصة والمعزولة داخل VPC، مع Security Groups على الأجهزة وNACL على الشبكات، وفي OpenStack بنفس المفاهيم. - التقسيم الدقيق يمنع الحركة داخل المنطقة نفسها، ويأتي بعد المناطق وليس بدلها. - كل ذلك يبنى بأدوات مفتوحة المصدر: Bridge لينكس وnftables، وProxmox VE SDN، وOPNsense وpfSense، وOpen vSwitch، وشبكات Docker الداخلية. وأقرب المقالات إلى هذا الموضوع على الموقع: [![](https://arabroot.io/content/images/2026/10/subnets-cidr-cover-cover.webp)دليلSubnets وCIDR: كيف تقسم عناوين IP وتحسبها بيدكماذا يعني /26 وكيف تحسب الشبكة ومدى الأجهزة بيدك، ثم تبني خطة عناوين كاملة لشركة صغيرة لا تتعارض فيها الشبكات.](https://arabroot.io/articles/%D8%A7%D9%84%D8%B4%D8%A8%D9%83%D8%A7%D8%AA-%D8%A7%D9%84%D9%81%D8%B1%D8%B9%D9%8A%D8%A9-subnets-%D9%88-cidr-%D9%88-vlsm/)[![](https://arabroot.io/content/images/2026/10/tiers-layers-cover-cover.webp)دليلالفرق بين Tiers وLayers: متى يكون نظامك ثلاثي الطبقات فعلاً؟ماذا يعني أن يكون نظامك ثلاثي الطبقات 3-tier فعلاً، والفرق بين الطبقة داخل الكود والمستوى في الشبكة، وما تطلبه الضوابط بالنص.](https://arabroot.io/articles/%D8%A7%D9%84%D9%85%D8%B9%D9%85%D8%A7%D8%B1%D9%8A%D8%A9-%D9%85%D8%AA%D8%B9%D8%AF%D8%AF%D8%A9-%D8%A7%D9%84%D8%B7%D8%A8%D9%82%D8%A7%D8%AA-tiers-%D9%88-layers/)[![](https://arabroot.io/content/images/2026/10/mikrotik-scenarios-cover-cover.webp)دليلMikroTik في الواقع: سيناريوهات عملية للبيت والمكتبكيف تبني على RouterOS ما تحتاجه فعلاً في البيت والمكتب، من شبكة ضيوف معزولة إلى الوصول الآمن من الخارج عبر WireGuard.](https://arabroot.io/articles/mikrotik-%D9%81%D9%8A-%D8%A7%D9%84%D9%88%D8%A7%D9%82%D8%B9-%D8%B4%D8%A8%D9%83%D8%A9-%D8%A7%D9%84%D8%B6%D9%8A%D9%88%D9%81-%D9%88vlan-%D9%88%D8%A7%D9%84vpn-%D9%88%D8%AA%D9%88%D8%AC%D9%8A%D9%87-%D8%A7%D9%84%D9%85%D9%86%D8%A7%D9%81%D8%B0/)[![](https://arabroot.io/content/images/2026/10/mikrotik-firewall-cover-cover.webp)دليلجدار الحماية Firewall في MikroTik RouterOS بالتفصيلكيف تمر الحزمة داخل جدار الحماية في RouterOS، وكيف تكتب قواعد مرتبة تحمي الراوتر والشبكة خلفه دون أن تفقد الوصول إليه.](https://arabroot.io/articles/%D8%AC%D8%AF%D8%A7%D8%B1-%D8%A7%D9%84%D8%AD%D9%85%D8%A7%D9%8A%D8%A9-%D9%81%D9%8A-mikrotik-routeros-%D8%A8%D8%A7%D9%84%D8%AA%D9%81%D8%B5%D9%8A%D9%84/)[![](https://arabroot.io/content/images/2026/10/docker-networking-cover-cover.webp)دليلشبكات Docker وأفضل الممارسات مع Docker Composeلماذا يبقى المنفذ الذي تنشره في Compose مفتوحاً للإنترنت رغم ufw، وكيف تصل التطبيقات إلى بعضها عبر شبكات Docker دون نشر منافذ.](https://arabroot.io/articles/%D8%B4%D8%A8%D9%83%D8%A7%D8%AA-docker-%D9%88%D8%A3%D9%81%D8%B6%D9%84-%D8%A7%D9%84%D9%85%D9%85%D8%A7%D8%B1%D8%B3%D8%A7%D8%AA/)[![](https://arabroot.io/content/images/2026/10/network-devices-cover-cover.webp)دليلأجهزة الشبكة في البيت والمكتب: ماذا يفعل كل جهاز؟نأخذ كل جهاز في شبكة البيت والمكتب على حدة، من المودم إلى ال Router وال Switch، ونعرف ماذا يفعل ولماذا تحتاجه.](https://arabroot.io/articles/%D8%A7%D9%84%D9%85%D9%88%D8%AF%D9%85-%D9%88%D8%A7%D9%84%D8%B1%D8%A7%D9%88%D8%AA%D8%B1-%D9%88%D8%A7%D9%84%D8%B3%D9%88%D9%8A%D8%AA%D8%B4-%D9%85%D8%A7-%D8%A7%D9%84%D9%81%D8%B1%D9%82-%D8%A8%D9%8A%D9%86%D9%87%D8%A7/) ## سجل التحديثات - أكتوبر 2026: كتابة المقال، ومراجعة تقرير S-RM ووثائق Proxmox VE SDN وOPNsense وpfSense وOpen vSwitch وAWS VPC وOpenStack Neutron وNIST SP 800-207، وتنفيذ التجربة العملية على Docker Engine 29.8.0 مع alpine:3.24 وiproute2 7.0.0 وnftables 1.1.6 وtcpdump 4.99.6 وBusyBox 1.37.0.