في مارس 2025 نشرت شركة الاستجابة للحوادث S-RM تفاصيل هجوم لعصابة Akira على أحد عملائها، والجزء الذي يهمنا في هذا المقال ليس الثغرة التي دخل منها المهاجمون، وإنما ما فعلوه بعد أن أوقفهم برنامج الحماية على السيرفر: بحثوا في الشبكة الداخلية فوجدوا كاميرا ويب تعمل بنظام Linux خفيف فيها ثغرات، فشغلوا برنامج الفدية عليها، ومنها شفروا ملفات السيرفر عبر الشبكة، والكاميرا لا يمكن أصلاً أن يثبت عليها برنامج حماية. والسؤال الذي يطرحه أي مدير شبكة بعد قراءة القصة: لماذا تستطيع كاميرا أن تتصل بسيرفر الملفات أصلاً؟ والإجابة أن الكاميرا والسيرفر وأجهزة الموظفين كانوا في نفس الشبكة، أي ما يسمى الشبكة المسطحة Flat Network.
وفي مقال الشبكات الفرعية Subnets وCIDR و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، أجهزة الموظفين وطابعة المحاسبة ونقطة الوصول للضيوف وكاميرات المراقبة وقاعدة البيانات. وهذا الشكل يعمل ولا يشتكي منه أحد، والصورة التالية تبين لماذا هو خطر:
وفي الشكل أعلاه لاحظ ثلاث مشكلات:
- الحركة الجانبية Lateral Movement: المهاجم لا يحتاج أن يخترق الهدف من الإنترنت، وإنما يكفيه أي جهاز داخلي، ثم ينتقل منه إلى غيره، وأسهل الأجهزة اختراقاً هي التي لا يحدثها أحد: الكاميرات والطابعات وأجهزة إنترنت الأشياء IoT، وهي نفسها الأجهزة التي لا تحتاج أن تكلم قاعدة البيانات أبداً.
- لا يوجد مكان للقاعدة: الحركة بين جهازين في نفس الشبكة تمر على ال Switch فقط، وال Switch العادي لا يطبق قواعد، فلا يوجد مكان تكتب فيه «الكاميرات لا تكلم السيرفرات»، ولا مكان تسجل فيه المحاولة.
- ضجيج البث Broadcast: كل طلب ARP وDHCP وكل رسائل الاكتشاف من الطابعات والتلفزيونات تصل إلى كل جهاز، وهذا أيضاً ما يجعل الجهاز المخترق يعرف جيرانه دون أن يفحص الشبكة.
والحل بالطبع ليس أن نشتري Switch لكل مجموعة ونمد كابلات منفصلة، وهي الطريقة البسيطة التي تعمل في مكتب صغير جداً وتنهار عندما تكون كاميرا وحاسوب موظف وضيف في نفس الغرفة، والحل الذي تستخدمه كل الشبكات اليوم هو أن نقسم ال Switch الواحد إلى عدة شبكات منطقية، وهذا هو VLAN.
الشبكات المحلية الافتراضية VLAN: Switch واحد وعدة شبكات
الشبكة المحلية الافتراضية Virtual LAN، واختصاراً VLAN، هي مجموعة منافذ على Switch واحد أو أكثر تتصرف كأنها Switch مستقل: البث لا يخرج منها، والجهاز فيها لا يرى أجهزة VLAN أخرى على مستوى الطبقة الثانية Layer 2، حتى لو غير عنوان IP الخاص به كما سنرى في التجربة. وكل VLAN يأخذ رقماً، وتعرف الشبكة إلى أي VLAN ينتمي كل إطار Frame بوسم Tag يضاف إليه وفق المعيار IEEE 802.1Q، والصورة التالية تبين أين يوضع:
الوسم أربعة بايتات: أول 16 بتاً قيمتها 0x8100 وتقول للجهاز «هذا إطار موسوم»، ثم 3 بتات للأولوية PCP التي تستخدمها جودة الخدمة QoS، ثم بت DEI، ثم 12 بتاً لرقم ال VLAN، أي 4096 قيمة، و0 و4095 محجوزتان، لذلك تقول وثائق pfSense ووثائق OPNsense إن رقم ال VLAN بين 1 و4094. وسوف ترى هذا الوسم بعينك في مخرج tcpdump في التجربة.
منفذ Access ومنفذ Trunk
الحاسوب والكاميرا والطابعة لا تعرف شيئاً عن الوسم، ولا ينبغي أن تعرف، لذلك يقسم ال Switch منافذه إلى نوعين:
- منفذ Access: ينتمي إلى VLAN واحد، وهذا الرقم يسمى PVID أي Port VLAN ID، فال Switch يضيف الوسم على كل إطار يدخل من المنفذ، ويزيله من كل إطار يخرج إليه، والجهاز في الطرف الآخر يرى شبكة عادية.
- منفذ Trunk: يحمل عدة شبكات VLAN على كابل واحد، والإطارات عليه موسومة حتى يعرف الطرف الآخر لمن كل إطار، وتقول وثائق Open vSwitch إن منفذ Trunk يوصل عادة بجهاز Switch آخر أو Router وليس بجهاز عادي، لأن الأجهزة العادية لا تتوقع وسماً في الحركة التي تستقبلها.
والصورة التالية تبين كيف يعبر إطار من الكاميرا في VLAN 30 إلى السيرفر في VLAN 40:
وقد شرحنا ال Switch المدار Managed Switch وما يضيفه في المودم والراوتر والسويتش، وإعداد هذه المنافذ على أجهزة MikroTik بالأوامر في VLANs على السويتش المدمج. والقاعدة المهمة هنا: ال VLAN يفصل في الطبقة الثانية فقط، والجدار الناري هو الذي يقرر ما يعبر بين الشبكات، وهذا موضوع القسم التالي.
التوجيه بين شبكات VLAN وقواعد الجدار الناري
كل VLAN شبكة فرعية مستقلة لها بوابتها، والبوابة عادة واجهة فرعية Sub-interface على ال Router أو الجدار الناري تستقبل ال Trunk، فتصبح eth0.10 بوابة الموظفين وeth0.30 بوابة الكاميرات، وهذا الشكل يسمى أحياناً Router on a Stick لأن كل الشبكات تصل إليه على كابل واحد. وفي الشبكات الأكبر يقوم Switch من الطبقة الثالثة Layer 3 Switch بالتوجيه بسرعة العتاد، لكن الفكرة واحدة: الحركة بين شبكتين تمر على جهاز يستطيع أن يطبق قواعد.
وهنا يقع أهم خطأ في الموضوع: أن تقسم الشبكة إلى VLANs ثم تترك ال Router يوجه بينها كل شيء، فهو بطبيعته يوصل الشبكات المتصلة به، والنتيجة أن الكاميرا ما زالت تصل إلى قاعدة البيانات، لكن عبر ال Router هذه المرة، وسوف نرى هذا بالمخرج في التجربة. لذلك الخطوة الثانية دائماً جدول التدفقات المسموحة: من يكلم من، وعلى أي منفذ، ولماذا، والصورة التالية تبين مثالاً للمناطق الخمس في خطتنا:
في الجدول أعلاه لاحظ التالي:
- الكاميرات لا تكلم إلا مسجل الفيديو NVR على منفذ RTSP، ولا تخرج إلى الإنترنت، فإذا احتاجت الشركة المصنعة إلى خدمة سحابية فهذا قرار يكتب سببه.
- الضيوف يصلون إلى الإنترنت فقط، ولا يصلون حتى إلى صفحة إدارة ال Router، وهذا ما بنيناه في شبكة الضيوف على MikroTik.
- شبكة الإدارة Management هي الوحيدة التي تصل إلى واجهات إدارة الأجهزة، ولا يصل إليها أحد من الشبكات الأخرى، فسرقة حاسوب موظف لا تعطي المهاجم لوحة ال Switch.
- الخانات الرمادية داخل نفس المنطقة مفتوحة في هذا التصميم، وسنعود إليها في قسم التقسيم الدقيق.
ومناطق التطبيقات نفسها، أي ال DMZ ومنطقة التطبيق ومنطقة البيانات، وما تطلبه الضوابط الأساسية للأمن السيبراني في البند 2-15-3-2 من المعمارية متعددة المستويات، شرحناها بالتفصيل وبتجربة عملية في المعمارية متعددة الطبقات Tiers وLayers، أما عزل الشبكات وتقسيمها عموماً فهو في مكون إدارة أمن الشبكات 2-5 الذي لخصناه في الضوابط الأساسية للأمن السيبراني NCA ECC، وجدول التدفقات أعلاه هو الدليل الذي يطلبه المدقق في الحالتين. أما كتابة القواعد نفسها على RouterOS بالسلاسل وتتبع الاتصالات فهي في جدار الحماية في MikroTik RouterOS بالتفصيل.
الشبكات الفرعية في السحابة: VPC
في السحابة لا توجد VLANs تراها، لكن الفكرة نفسها موجودة باسم آخر: الشبكة الافتراضية الخاصة Virtual Private Cloud، واختصاراً VPC، وتعرفها وثائق AWS بأنها شبكة افتراضية في منطقة معزولة منطقياً من السحابة، وتنصح باستخدام الشبكات الفرعية لعزل مستويات التطبيق مثل الويب والتطبيق وقاعدة البيانات داخل VPC واحد. والصورة التالية تبين الشكل المعتاد:
وتقول صفحة الشبكات الفرعية في AWS إن نوع الشبكة يحدده جدول التوجيه: الشبكة العامة 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 إن الشبكة الفرعية كتلة عناوين مع إعدادها، وإن ال Router الافتراضي يوجه بين الشبكات ويطبق NAT، وإن Security Groups فيها رفض افتراضي ولا تحتوي إلا قواعد سماح، وإنها Stateful، وإن كل منفذ Port يمكن أن يرتبط بأكثر من مجموعة. فالتصميم الذي ترسمه لسحابة عامة تنقله إلى OpenStack دون تغيير في الفكرة.
التقسيم الدقيق Micro-segmentation
التقسيم إلى مناطق يمنع الكاميرا من الوصول إلى السيرفرات، لكنه يترك السيرفرات داخل منطقتها مفتوحة على بعضها، فإذا اخترق المهاجم سيرفر التقارير وصل إلى سيرفر قاعدة البيانات المجاور، والخطوة التالية هي التقسيم الدقيق: أن يكون لكل خدمة أو حمل عمل Workload سياسة خاصة به، والصورة التالية تبين الفرق:
ويصف معيار NIST SP 800-207 للثقة المعدومة Zero Trust هذا الأسلوب في القسم 3.1.2: أن تضع كل مورد أو مجموعة صغيرة من الموارد في قطعة شبكة خاصة يحميها مكون بوابة، سواء كان Switch أو Router ذكياً أو جداراً نارياً، أو أن تطبقه على الجهاز نفسه ببرامج وكيلة. وفي التطبيق العملي تراه في ثلاثة أشكال: Security Group لكل دور في السحابة، وسياسات NetworkPolicy لكل خدمة في Kubernetes، وجدار ناري على كل سيرفر. والترتيب مهم: ابدأ بالمناطق لأنها أرخص وتغلق أكبر الأبواب، ثم أضف التقسيم الدقيق للأنظمة الحساسة، وقد شرحنا فكرة Zero Trust من جهة الوصول في ما هو VPN؟.
تجربة عملية: Switch بشبكات VLAN وجدار ناري بأدوات Linux
الآن سوف نبني الفكرة كلها على جهاز واحد بأدوات Linux الأساسية: كل جهاز في الشبكة سيكون Namespace شبكة Network Namespace مستقلاً، وهو نفس ما يعزل به Docker شبكة كل Container، وال Switch سيكون Bridge في Linux يفهم VLAN، وال Router والجدار الناري سيكونان Namespace فيه واجهات VLAN وقواعد nftables. والصورة التالية تبين ما سنبنيه:
تجهيز ال Container
كل التجربة داخل Container واحد اسمه lab-seg-lab، والصلاحيات الإضافية فيه لا تخرج منه: NET_ADMIN لإنشاء الواجهات والقواعد، وSYS_ADMIN لأن الأمر ip netns add يحتاج أن يركب مجلد /run/netns، وNET_RAW لأداتي ping وtcpdump:
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 تمثل الويب ومسجل الفيديو وقاعدة البيانات:
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والمخرج سوف يكون كما يلي:
srv (id: 4)
router
guest (id: 2)
staff (id: 1)
cam (id: 3)كل جهاز له Namespace، وفيه واجهة eth0 طرفها الآخر sw-NAME موصول بال Bridge، تماماً مثل كابل من الجهاز إلى منفذ في ال Switch.
الشبكة المسطحة: الكاميرا تصل إلى قاعدة البيانات
نراقب ARP من جهاز الموظف، ثم نجعل الكاميرا تطلب منفذ قاعدة البيانات وترسل ping إلى هاتف الضيف:
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والمخرج سوف يكون كما يلي:
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 يحمل الشبكات الأربع:
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والمخرج سوف يكون كما يلي:
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.vlan_default_pvid 0يمنع ال Bridge من وضع كل منفذ جديد في VLAN 1 تلقائياً، وهذه نفس المشكلة التي يحذر منها توثيق MikroTik: شبكة افتراضية لم يقصدها أحد تصبح باباً مفتوحاً بين المنافذ.pvid untaggedفي الأمر bridge يجعل المنفذ Access: الإطار الداخل بلا وسم يأخذ رقم المنفذ، والخارج إليه يفقد الوسم، وفي المخرج تراهاPVID Egress Untagged.- منفذ
sw-routerعضو في الشبكات الأربع بلاuntagged، أي أن الإطارات عليه موسومة، وهذا هو ال Trunk.
ثم نعطي ال Router واجهة VLAN لكل شبكة، وعليها عنوان البوابة:
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والمخرج سوف يكون كما يلي:
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، ونختبر قبل أن نكتب أي قاعدة:
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والمخرج سوف يكون كما يلي:
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 من الكاميرا إلى السيرفر:
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والمخرج سوف يكون كما يلي:
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؟ لنجرب ذلك ثم نعيد عنوانها:
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والمخرج سوف يكون كما يلي:
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، وكل ما عدا ذلك بين المناطق مرفوض:
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والمخرج سوف يكون كما يلي:
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 على نفس السيرفر.
والآن نرى العدادات التي تسجل ما رفض:
ip netns exec router nft list chain inet zones forwardوالمخرج سوف يكون كما يلي:
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 علامة على اختراق يجب أن يراها أحد فوراً.
نكسر القاعدة: نسيان تتبع الاتصالات
خطأ شائع عند كتابة القواعد أول مرة أن تنسى سطر الاتصالات القائمة، فنحذفه ونرى ماذا يحدث لاتصال مسموح:
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=$?"والمخرج سوف يكون كما يلي:
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 الذي لا يتبع الاتصالات، لذلك إذا رأيت اتصالاً «مسموحاً» ينتهي بمهلة فابحث عن قاعدة الرد. ونعيد الملف كاملاً لنرجع إلى الإعداد الصحيح:
ip netns exec router nft -f /root/zones.nft
t staff 10.20.0.230 443والمخرج سوف يكون كما يلي:
staff -> 10.20.0.230 443 openولاحظ أن السطر flush ruleset في أول الملف يجعل تطبيقه آمناً للتكرار، فكل تطبيق يبدأ من الصفر بدل أن يضيف القواعد مرة ثانية.
التنظيف
كل ما أنشأناه داخل ال Container، فنخرج منه ونحذفه بالاسم:
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:
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.
وعندما يكبر العنقود Cluster يأتي دور الشبكات المعرفة بالبرمجيات SDN، وتقول وثائق Proxmox SDN إن حزمها الأساسية مثبتة افتراضياً منذ الإصدار 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
إذا أردت جداراً نارياً مستقلاً بواجهة رسومية فالخطوات في الاثنين متشابهة:
- أنشئ ال VLAN على الواجهة الفيزيائية الموصولة بمنفذ Trunk: في OPNsense من Interfaces ثم Devices ثم VLAN، وفي pfSense من Interfaces ثم Assignments ثم تبويب VLANs، وتختار الواجهة الأم Parent Interface ورقم ال VLAN بين 1 و4094 والأولوية PCP ووصفاً.
- اربط ال VLAN بواجهة من Interfaces ثم Assignments، ثم فعلها وأعطها عنوان البوابة من خطة العناوين.
- فعل خدمة DHCP لها إذا احتجت.
- اكتب قواعدها في تبويب الواجهة في Firewall ثم Rules، وتذكر وثائق pfSense أن واجهات VLAN تتصرف مثل أي واجهة إضافية، فيجب أن تفعلها وتعدها وتضيف لها قواعد الجدار الناري وتعد خدماتها مثل DHCP، والتفاصيل في وثائق جدار OPNsense.
وال Switch المدار في هذه الحالة يحمل الشبكات إلى الجدار الناري على منفذ Trunk واحد، وكل منفذ آخر فيه Access بالرقم المناسب، وإذا كان الجدار الناري من MikroTik فقد غطينا ذلك في MikroTik وRouterOS للمبتدئين والمقالين بعده.
Open vSwitch
Open vSwitch هو Switch برمجي يستخدم في OpenStack ويمكن أن يستخدمه Proxmox بدل Bridge لينكس، وفكرة المنافذ فيه نفسها، فالأمر التالي من أسئلته الشائعة يضيف منفذاً من نوع Access في VLAN 9:
ovs-vsctl add-port br0 tap0 tag=9وتحتاجه عادة عندما تريد مزايا لا يقدمها Bridge لينكس، مثل التحكم بالتدفقات OpenFlow أو الأنفاق بين عدة سيرفرات، أما لسيرفر واحد أو عنقود صغير فال Bridge الذي يفهم VLAN يكفي.
Docker وPodman: شبكات داخلية على سيرفر واحد
داخل السيرفر الواحد تفعل شبكات Docker نفس الفصل بين ال Containers: كل شبكة تنشئها Bridge مستقل، والخيار internal: true يمنع الشبكة من الخروج، وال Container لا يرى إلا الشبكات التي وصلته بها، وقد شرحنا ذلك في شبكات Docker وأفضل الممارسات، وبنينا به ثلاث مناطق DMZ وتطبيق وبيانات في تجربة المعمارية متعددة الطبقات. وإذا أردت أن يأخذ Container عنواناً في VLAN فعلية على شبكتك فهذا عمل شبكات 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كما في التجربة. - تقسيم بلا مراقبة: قواعد رفض لا يسجل منها شيء، فلا تعرف أن الكاميرا حاولت الوصول إلى قاعدة البيانات إلا بعد الحادثة.
قائمة التحقق
- هل لديك خطة عناوين فيها شبكة فرعية ورقم VLAN لكل منطقة، ولا تتداخل مع شبكات الفروع أو ال VPN أو Docker؟
- هل أجهزة إنترنت الأشياء والكاميرات في شبكة لا تصل إلى السيرفرات ولا إلى أجهزة الموظفين؟
- هل الضيوف في شبكة لا تصل إلا إلى الإنترنت؟
- هل واجهات الإدارة في شبكة مستقلة لا يصل إليها إلا المسؤولون، ويفضل عبر VPN؟
- هل سياسة الجدار الناري بين المناطق «ارفض كل شيء» مع استثناءات مكتوبة بسببها؟
- هل المنافذ عند المستخدمين Access، وال Trunk فقط بين أجهزة الشبكة؟
- هل جربت من كل منطقة أن الممنوع ممنوع فعلاً، كما فعلنا في التجربة؟
- هل تسجل الحركة المرفوضة بين المناطق وتصل السجلات إلى من يراقبها؟
- في السحابة: هل قواعد البيانات في شبكة خاصة أو معزولة، وSecurity Groups تشير إلى بعضها بدل العناوين؟
تدريب عملي
- أضف إلى التجربة Namespace خامساً للإدارة في VLAN 99 بالشبكة
10.20.0.240/28، واكتب قاعدة تسمح له وحده بالوصول إلى المنفذ 22 على ال Router، ثم اختبر من الموظفين ومن الإدارة. - أضف إلى قاعدة الرفض في السلسلة
forwardعبارةlog prefix "zone-drop "على سيرفر Linux حقيقي أو VM، وجرب الوصول من الكاميرا إلى 5432، ثم ابحث عن السطر بالأمرjournalctl -k | grep zone-drop. - ارسم جدول التدفقات لشبكة مكتبك أو بيتك كما في المصفوفة أعلاه قبل أن تغير أي إعداد.
الخلاصة
وصلنا لنهاية الموضوع، وأهم ما فيه:
- في الشبكة المسطحة أضعف جهاز هو باب الشبكة كلها، وحادثة 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 الداخلية.
وأقرب المقالات إلى هذا الموضوع على الموقع:
دليلSubnets وCIDR: كيف تقسم عناوين IP وتحسبها بيدكماذا يعني /26 وكيف تحسب الشبكة ومدى الأجهزة بيدك، ثم تبني خطة عناوين كاملة لشركة صغيرة لا تتعارض فيها الشبكات.
دليلالفرق بين Tiers وLayers: متى يكون نظامك ثلاثي الطبقات فعلاً؟ماذا يعني أن يكون نظامك ثلاثي الطبقات 3-tier فعلاً، والفرق بين الطبقة داخل الكود والمستوى في الشبكة، وما تطلبه الضوابط بالنص.
دليلMikroTik في الواقع: سيناريوهات عملية للبيت والمكتبكيف تبني على RouterOS ما تحتاجه فعلاً في البيت والمكتب، من شبكة ضيوف معزولة إلى الوصول الآمن من الخارج عبر WireGuard.
دليلجدار الحماية Firewall في MikroTik RouterOS بالتفصيلكيف تمر الحزمة داخل جدار الحماية في RouterOS، وكيف تكتب قواعد مرتبة تحمي الراوتر والشبكة خلفه دون أن تفقد الوصول إليه.
دليلشبكات Docker وأفضل الممارسات مع Docker Composeلماذا يبقى المنفذ الذي تنشره في Compose مفتوحاً للإنترنت رغم ufw، وكيف تصل التطبيقات إلى بعضها عبر شبكات Docker دون نشر منافذ.
دليلأجهزة الشبكة في البيت والمكتب: ماذا يفعل كل جهاز؟نأخذ كل جهاز في شبكة البيت والمكتب على حدة، من المودم إلى ال Router وال Switch، ونعرف ماذا يفعل ولماذا تحتاجه.سجل التحديثات
- أكتوبر 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.
