مقدمة

في هذا الدليل سنتعلّم كيف نصنع موجّهًا (راوترًا) بديعًا يعمل بنظام «أوبن بي إس دي»، معتمدين على عتادٍ رخيصٍ متواضع القدرات، لكنه ينهض بالمهمة على أكمل وجه: جدارٌ عازلٌ وتقسيماتٌ للشبكة المحلية، ونظام اسماء نطاقات مزوّد بحظرٍ للنطاقات، و«معيار تهيئةُ المُضيف الآلية» (DHCP)، وغير ذلك كثير.

وسنُنشئ إعدادًا يُقسّم الشبكة المحلية (LAN) إلى ثلاث شبكاتٍ منفصلة: إحداها للكبار في المنزل، وأخرى للأطفال، وثالثة تُجعل منطقةً عامة (DMZ) تُستضاف فيها الخوادم المواجهة للعامة، كخادمٍ خاصٍّ للشابكة (web) أو خادمٍ للبريد. وسنرى كذلك كيف نُسخّر نظام أسماء النطاقات (DNS) لحجب الإعلانات والمواقع الفاحشة وغيرها من مواقع الشابكة التي لا نرغب بها.ويمكن اعتماد موجّه «أوبن بي إس دي» هذا في المكاتب الصغيرة والمتوسطة، إذ يقدّم أداءً حسنًا لا يُخيّب.

لماذا جدار الحماية؟

مهما تكن وسيلتك للاتصال بالإنترنت، من منزلك أو مكتبك، فأنت بحاجة إلى جدار حماية يفصل بين شبكتك وبين المودم أو الموجّه الذي زوّدك به مزوّد الإنترنت.

ونادراً ما تحصل اجهزة المودم والموجّهات المنزلية على تحديثات للبرمجيات الثابتة (firmware)، ولذا تكون عرضةً لهجمات الشبكة التي قد تحولها الى جزءٍ من شبكات «البوتنت» botnets, مثل برمجية «ميراي» الخبيثة. وقد كانت هذه الأجهزة سببًا في بعضٍ من أكبر هجمات الحرمان من الخدمة (DDoS).

جدارُ حمايةٍ بينك وبين موديم أو موجه مزود الإنترنت ISP لايحمي الجهاز الموديم نفسه من الهجمات، لكنه يحمي حاسبك واجهزتك، ويتيح لك مراقبة حركة البيانات الواردة والصادرة في شبكتك والتحكم بها.

وبدون هذا الجدار بين شبكتك المحلية وجهاز مزود الإنترنت تكون كمن يترك باب بيته مشرعاً، إذ لا يمكن الوثوق بجودة أجهزة مزوّدي الإنترنت دائمًا.

وإنه لمن الحكمة وضع جدار حمايةٍ بين شبكتك المحلية والإنترنت، ويقدّم لك نظام «أوبن بي إس دي» حلًّا متينًا لهذا الغرض.

العَتاد

لا تشتري العتاد الغال لتصنع موجه وجدارُ حمايةٍ لبيتك او مكتبك، بل عتاد رخيص ويسير يكفي ويكون ممتازاً.

وقد بنيت عدداً من الحلول بلوحة ASRock Q1900DC-ITX ذات معالج إنتل Celeron رباعيّ النوى.

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

وللوحة ASRock Q1900DC-ITX ميزةٌ ظاهرة، إذ تأتي بمقبس DC-In يقبل مهايئًا بين 9 و19 فولت، فيجعلها مُقتَصدة في الطاقة. غير أنّ هذه اللوحة — ويا للأسف — قد انقطع صنعها، وإنما أذكرها مثالًا، فقد استخدمتُ سواها من اللوحات الرخيصة غير واحدة.

وقد جرّبتُ لوحة ASRock Q1900-ITX (وهي بلا مقبس DC-In) مقترنةً بوحدة PicoPSU.

ستجد لِـ PicoPSU علاماتٍ تجارية وإصداراتٍ شتّى، يختلف بعضها عن بعض في الجودة. ولديّ اثنان منها: الأصلي، وآخر مقلّد زهيد الثمن، وكلاهما يؤديان الغرض أداءً حسناً، ويوفّران قدراً لا بأس به من الطاقة، خلاف ما لو شغّلت اللوحة بمزوّد طاقة اعتيادي.

وأخيراً، فإني أستعمل بطاقةَ شبكة NIC رباعيةَ المنافذ مقلّدةً لبطاقات إنتل، زهيدةَ الثمن، تجدُها على Ebay… كهذه:

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

أوصيك بالبحث عن لوحة mini-ITX منخفضة الاستهلاك، يكون عتادها مدعوماً من نظام «أوبن بي إس دي»، كالمعالجات من فئة إنتل Celeron أو إنتل i3. فهذه اللوحات في العادة رخيصة، قليلة النَّهَم للطاقة، ولا تحتل حيزاً من المكان. ولا أوصي باستخدام معالج إنتل Atom إن كانت لديك شبكة جيجابت، إذ غالباً ما يختنق تحت وطأة مرور البيانات ولا يقوى على مجاراتها، وإن كان الأمر يختلف من مستخدم لآخر.

وقد تحتاج إلى بضع محوّلات جيجابت رخيصة لتقسيم الشبكة المحليّة، ولا سيّما إن كان لديك أكثر من حاسوبٍ تودّ وصله بالشبكة ذاتها :)

لِمَ نظام «أوبن بي إس دي»؟

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

وما هو أبعد من ذلك، فإن «أوبن بي إس دي» مميز حقاً، وليس في هذا مبالغة. فكُتيّباته (man pages) واضحة وسهلة القراءة، وغالباً ما تكفي وحدها لإنشاء ملفات الإعداد التي تحتاجها لخدماتك المختلفة دون عناء يُذكر. ويحافظ مشروع »أوبن بي إس دي« على مستوى عالٍ جداً من الجودة، سواء في البرمجيات أو كتيّباتها.

هذا الدليل لن يشرح كيفية تثبيت «أوبن بي إس دي». وإن لم يسبق لك القيام بذلك، فأوصيك بتجربة النظام داخل آلة افتراضية، أو على قطعة عتادٍ قديمة مدعومة تتدرب عليها. و »أوبن بي إس دي« من أسهل الأنظمة تثبيتاً وأسرعها. ولا تخشَ غياب الواجهة الرسومية أثناء التثبيت—فما إن تجربه حتى تُقدّر تلك البساطة. وعند التردد، اختر ما افتُرِض من الإعدادات.

قبل أن تبدأ رحلتك، احرص على الرجوع إلى توثيق «أوبن بي إس دي»! فالتوثيق دقيق للغاية، وغالباً ستجد كل ما تحتاجه هناك. واقرأ الأسئلة الشائعة واطّلع على كتيّبات الإستعمال للبرامج التي سنستعملها.

وهناك مصدر آخر مهم للمعلومات العامة حول «أوبن بي إس دي» وهو أرشيف القوائم البريدية. كما أنصح بالاشتراك في قوائم الإعلانات والتنبيهات الأمنية للبقاء على اطّلاعٍ دائم بكل جديد.

الشبكة

الـمُوجِّه ـ في حقيقته ـ جهازٌ ينظّم حركة البيانات بين شبكتين أو أكثر من الشبكات المنفصلة. فهو يضمن أن الحركة المقصودة للشبكة المحليّة لا تتسرّب إلى فضاء الإنترنت، وأن ما يجري في الإنترنت مما لا يُقصَد به شبكتك يبقى حيث هو ولا يتعدّى حدوده.

في هذا الدليل سنبني موجّهًا، ولدينا أربع شبكات من نفس النوع: إحداها الإنترنت، والثلاث الأُخَر شبكاتٌ محليّة داخليّة مقسّمة (LANs). وبعض الناس يفضّلون العمل مع الشبكات الافتراضية (VLANs)، لكنّا هنا سنستخدم بطاقة الشبكة الرباعية المنافذ المشار إليها آنفًا. ويمكنك أن تبلغ النتيجة نفسها باستخدام عدّة بطاقات شبكيّة أحادية المنفذ، إن أحببت ذلك، شريطة أن يكون في اللوحة الأم حيّزٌ كافٍ وما يكفي من منافذ PCI. وكذلك يمكن استعمال منفذ الشبكة الموجود أصلًا في اللوحة الأم نفسها، لكن الأمر يتوقّف على شأن التعاريف (driver) ودعم النظام للجهاز. ولستُ أذكر أني واجهت مشكلة مع متحكّم Realtek PCI gigabit الموجود في كثيرٍ من اللوحات، وإن كنتُ ـ في الجملة ـ أفضّل منتجات إنتل عليه.

وليس لزامًا عليك أن تُقسّم شبكتك إلى أجزاء عدّة إن لم يكن لك حاجة، ويمكن تعديل الإعدادات في هذا الدليل بسهولة. غير أني اخترت هذا النهج لأبيّن لك كيف يمكنك حماية أبنائك بفصل شبكتهم في LAN مستقل، لا يكتفي بحجب الإعلانات ومواقع الفحش عبر حجب «نظام اسماء النطاقات» (وهذا يشمل جميع الشبكات)، بل يمكنك أن تجعل لهم «قائمة مرور» لا ينفذون إلا لما أذنتَ لهم به من أجزاء الإنترنت. غير أن إعداد «قائمة المرور» هذه أمرٌ عسير، ولا يُنصح به غالبًا إلا إن كان أطفالك لا يحتاجون إلا إلى جزءٍ محدود جدًا من الشبكة، لكنه ـ مع ذلك ـ ممكن، وسيرشدك هذا الدليل إلى أحد أساليبه.

وهذه صورةٌ توضّح بنيان الشبكة التي سنُعدّها:

                       الإنترنت
                          |
                   xxx.xxx.xxx.xxx
                 مودِم المزوّد (WAN)
                      10.24.0.23
                          |
                       OpenBSD
                      10.24.0.50
               (الراوتر / جدار الحماية)
                          |
    ┌─────────────────────+─────────────────────┐
    |                     |                     |
   NIC1                  NIC2               NIC3 (DMZ)
192.168.1.1           192.168.2.1           192.168.3.1
 مبدّل LAN1             مبدّل LAN2             مبدّل LAN3
    |                     |                     |
    └─ 192.168.1.x        ├─ 192.168.2.x        └─ 192.168.3.2
       حاسوب البالغين      |   حاسوب طفل 1           خادم ويب عام
                          |
                          └─ 192.168.2.x
                             حاسوب طفل 2

العناوين التي تبدأ بـ 10.24.0 هي ما يعطيك إياه مودم مزود الإنترنت، وقد تكون مختلفة تمامًا عندك. أمّا العناوين التي تبدأ بـ 192.168 فهي ما سنستعمله في هذا الدليل لشبكتنا المحلية (LAN).

ولا يشرح هذا الدليل شيئًا من الاتصال اللاسلكي. فالبرمجية الثابتة (firmware) للشرائح اللاسلكية ـ كما هو مشهور ـ كثيرة العلل، سهلة الاستغلال، ولا أنصح باللاسلكي ما استطعت الاستغناء عنه. فإن احتجت إليه فالواجب عندي أن تعطّل الواي فاي في موجه المزود كليًا (إن استطعت)، ثم تبتاع أفضل موجه لاسلكي تجده، وتضعه خلف جدار الحماية في قطعةٍ معزولة من الشبكة. وبهذا، إن أُخترِق الجهاز اللاسلكي لاحقًا استطعت ضبط العواقب وتحديد الضرر. ويمكنك أيضًا أن تُعِدَّ الموجه اللاسلكي بحيث ينال كل جهازٍ يتصل به عنوانَه الخاص الذي يمرّ عبره فقط، مع حجب أي حركة تصدر عن الموجه نفسه، لكي تمنعه من “الاتصال بموطنه (phoning home)” أو إرسال بيانات خفية. ويمكن كذلك أن تقتني بطاقة لاسلكية يدعمها «أوبن بي إس دي» وتجعله هو نفسه نقطة الوصول (Access Point)، غير أني أميل إلى عزل الجزء اللاسلكي في موجه خارجي مستقل، أو في جهاز »أوبن بي إس دي« آخر يقوم بدور نقطة الوصول خلف جدار الحماية .

إعداد الشبكة

أول ما نبدأ به هو تهيئة بطاقات الشبكة (NICs) المختلفة في موجّهنا العامل بـ «أوبن بي إس دي». أمّا في جهازي هذا فقد عطّلتُ بطاقة الشبكة المدمجة في اللوحة الأم من الـبايوس، ولن أستعمل إلا بطاقة إنتل المقلّدة ذات المنافذ الأربعة.

فإن كنت تتّبع هذا الدليل، ولا تريد إلا جدارَ حمايةٍ يسير، فحسبُك بطاقتا شبكة منفصلتان على الأقل.

وقبل الشروع، احرص على قراءة كتيّب hostname.if وفهم مختلف خياراتها. وانظر أيضًا قسم الشبكات في سؤال وجواب عن «أوبن بي إس دي».

ولأنّي أستخدم بطاقات إنتل، فإن التعريف (driver) الذي يحمّله «أوبن بي إس دي» هو em وتُعدّ كل منفذٍ من منافذ البطاقة كأنه بطاقة مستقلة. فيُسمّى كلٌّ منها: emX حيث X هو رقم المنفذ في البطاقة.

وعند تشغيل أمر dmesg تظهر بطاقة الشبكة ذات المنافذ الأربعة عندي على هذا النحو:

$ doas dmesg
em0 at pci2 dev 0 function 0 "Intel I350" rev 0x01: msi, address a0:36:9f:a1:66:b8
em1 at pci2 dev 0 function 1 "Intel I350" rev 0x01: msi, address a0:36:9f:a1:66:b9
em2 at pci2 dev 0 function 2 "Intel I350" rev 0x01: msi, address a0:36:9f:a1:66:ba
em3 at pci2 dev 0 function 3 "Intel I350" rev 0x01: msi, address a0:36:9f:a1:66:bb

وهذا يُظهر أنّ بطاقتي قد عرفها النظام على أنها Intel I350-T4 PCI Express Quad Port Gigabit NIC.

والخطوة التالية هي معرفة أيّ منفذٍ فعليّ يقابل الرقم المذكور آنفًا. ويمكنك عمل ذلك بسهولة: أوصل سلك الإيثرنت القادم من مُبدّل أو مودم أو موجه فعّال — واحدًا بعد الآخر — في كل منفذ، لترى أيُّها ينشط، ثم دوّن ذلك عندك.

ويمكنك التحقق من حالة النشاط بأمر ifconfig فالمنافذ التي لا سلك فيها ستظهر حالتها no carrier في قسم status وأما المنفذ الذي فيه السلك فسيكون حاله active. على نحوٍ كهذا:

$ doas ifconfig
em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr a0:36:9f:a1:66:b9
        index 2 priority 0 llprio 3
        media: Ethernet autoselect (none)
        status: active
em2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr a0:36:9f:a1:66:ba
        index 3 priority 0 llprio 3
        media: Ethernet autoselect (none)
        status: no carrier

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

وعندي، يجب أن أضع عنوانًا ثابتًا للمنفذ em0 ثم يقوم مزوّد الإنترنت بتمرير الحركة القادمة من عنواني العام إليه. ولعمل ذلك أضبط بطاقة em0 بالمعلومات الآتية:

$ doas  echo 'inet 10.24.0.50 255.255.254.0 NONE' > /etc/hostname.em0

فإن لم تكن بحاجةٍ إلى عنوانٍ عام، وكان مزوّدك يمنحك العنوان عبر معيار تهيئةُ المُضيف الآلية، فحسبك أن تضع كلمة dhcp مكان الإعداد السابق:

$ doas echo 'dhcp' > /etc/hostname.em0

ثم أُهيّئ بقيّة منافذ بطاقة الشبكة بالعناوين الشبكية التي بيّنتُها في التصوير السابق.

$ doas echo 'inet 192.168.1.1 255.255.255.0 NONE' > /etc/hostname.em1
$ doas echo 'inet 192.168.2.1 255.255.255.0 NONE' > /etc/hostname.em2
$ doas echo 'inet 192.168.3.1 255.255.255.0 NONE' > /etc/hostname.em3

اطَّلع على كتيب hostname.if لمزيد من المعلومات.

ثم نحتاج إلى ضبط العنوان الـشبكي الخاص ببوّابة مزوّد الإنترنت (ISP gateway). وقد يكون هذا العنوان مختلفًا عن عنوان المودم أو الموجّه نفسه وفق إعداد مزوّدك . وإن لم تُنشئ الملف /etc/mygate فلن يُضاف أيُّ بوابة افتراضية (default gateway) إلى جدول التوجيه. ولا تحتاج إلى ملف /etc/mygate أصلًا إن كنت تحصل على عنوانك من المودم أو الموجّه عبر معيار تهيئةُ المُضيف الآلية. فحين تستعمل توجيه dhcp في أيّ ملف hostname.ifX فإن النظام يتجاهل ما في /etc/mygate لأن البطاقة التي تتلقّى عنوانها بواسطة معيار تهيئةُ المُضيف الآلية تحصل كذلك على معلومات البوّابة والتوجيه من خادم تهيئةُ المُضيف الآلية.

وأخيرًا، وليس آخرًا، نحتاج إلى تمكين تمرير الحزم IP forwarding. وتمريريّة العنوان الشبكي هي العملية التي تتيح للحزم أن تنتقل بين وجهات الشبكة المختلفة في الموجّه. وبشكلٍ افتراضي لا يقوم «أوبن بي إس دي» بتمرير الحزم بين الواجهات، أي إن وظائف التوجيه — أو ما يُعرف بوظائف البوّابة — معطّلة.

ويمكننا تفعيل تمرير الحزم بالأوامر الآتية:

$ doas sysctl net.inet.ip.forwarding=1
$ doas echo 'net.inet.ip.forwarding=1' >> /etc/sysctl.conf

الآن، سيكون النظام قادرًا على تمرير رزم IPv4 من بطاقة شبكة إلى أخرى. أو في حالتنا المحددة مع بطاقة الشبكة ذات الأربع منافذ، من منفذ إلى آخر. وإن احتجت إلى إعداد IPv6، فألقِ نظرة على كتيّبه.

معيار تهيئةُ المُضيف الآلية(DHCP)

جاهزون الآن لإعداد «معيار تهيئة المضيف الآلية» التي سنشغلها للحواسيب ومختلف المعدات المتصلة بشبكات محلية لدينا. قبل أن نبدأ، تأكد من أنك قرأت وفهمت الخيارات في كُتيّب dhcpd.conf. وألقِ نظرة على dhcp-options للتعرّف على الخيارات التي يدعمها dhcpd.

نستطيع أن نربط عناوين شبكية معيّنة بأجهزة أو حواسيب محددة تتصل بمنافذ LAN مختلفة. هذا الأمر ضروري إذا أردنا تمرير أي حركة بيانات (Traffic) قادمة من الإنترنت إلى خادم شابكة مثلاً. ويمكننا ربط عنوان شبكي محدد بجهاز معيّن عبر عنوان الMAC الخاص ببطاقة الشبكة في ذلك الجهاز.

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

عدّل ملف /etc/dhcpd.conf بمحررك المفضل واضبطه بما يناسبك.

subnet 192.168.1.0 netmask 255.255.255.0 {
    option domain-name-servers 192.168.1.1;
    option routers 192.168.1.1;
    range 192.168.1.10 192.168.1.254;
}
subnet 192.168.2.0 netmask 255.255.255.0 {
    option domain-name-servers 192.168.2.1;
    option routers 192.168.2.1;
    range 192.168.2.10 192.168.2.254;
}
subnet 192.168.3.0 netmask 255.255.255.0 {
    option domain-name-servers 192.168.3.1;
    option routers 192.168.3.1;
    range 192.168.3.10 192.168.3.254;
    host web.example.com {
        fixed-address 191.168.3.2;
        hardware ethernet 61:20:42:39:61:AF;
        option host-name "webserver";
    }
}

السطر option domain-name-servers يحدد خادم نظام أسماء النطاقات الذي سنقوم بتشغيله على موجّهنا.

والحاسب الذي يعمل كخادم للشابكة على الشبكة المحلية العامة قد حصل على عنوان شبكي ثابت، و زُوٍد باسم مضيف (hostname) ثابت.

كذلك، إن كنت لا تريد تقسيم الشبكة إلى أجزاء، بل ترغب في وجود شبكة محلية واحدة فقط، يمكنك حذف الشبكات الفرعية الأخرى، فيبقى لديك هذا:

subnet 192.168.1.0 netmask 255.255.255.0 {
    option domain-name-servers 192.168.1.1;
    option routers 192.168.1.1;
    range 192.168.1.10 192.168.1.254;
}

بعد ذلك نتأكد من تفعيل وتشغيل خدمة dhcpd:

$ doas rcctl enable dhcpd
$ doas rcctl start dhcpd

جدارُ حمايةٍ يُصَفّي الرُزم (A Packet Filtering Firewall)

جدار الحماية الذي يُصَفي الرُزم يقوم بفحص كل رزمةِ بياناتٍ تمرّ عبره، ثم يقرّر قبولها أم لا، بناءً على تفحّص الحقول الموجودة في ترويسة IP و TCP/UDP، وذلك وفقًا للقواعد التي يحددها المستعمل.

تعمل مُصفيات الرُزم بفحص عنواني المصدر والوجهة الشبكيان، كذلك أرقام المنافذ (ports) الموجودة داخل كل رزمة TCP/IP. والمنافذ هي أرقام مخصّصة لخدمات معينة، وتُستعمل لمعرفة الخدمة التي يجب أن تستقبل الرُزمة.

ومن نقاط الضعف الشائعة في جدران الحماية أنها قد تتعامل مع كل رزمة على أنها وحدة مستقلة، من غير نظر إلى كونها جزءًا من اتصال سابق أو من سلسلة رزم متتابعة. ويُسمّى هذا النوع من الجدران الجدارَ عديمَ الحالة (Stateless Firewall)، وهو أسهل تحايُلًا من غيره. أمّا مُصفّي الرزم في «أوبن بي إس دي» فليس عديم الحالة، بل هو جدار ذو حالة (stateful).

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

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

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

ويُعدّ مُصفي الرُزم Packet Filter (PF) جدار الحماية في «أوبن بي إس دي» وهو المسؤول عن تصفية حركة TCP/IP وتنفيذ ترجمة العناوين. كما يوفّر إمكانيات تطبيع الحزم ومعالجتها، فضلًا عن التحكّم في عرض النطاق (Bandwidth) وترتيب أولويات المرور.

ويُطوَّر مُصفّي الرزم ويُصان باستمرار من قِبَل فريق «أوبن بي إس دي».

إعداد مُصفي الرُزم PF

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

وأحب أن أنبّه أن صيغة مُصفي الرُزم واضحة العبارة وسهلة القراءة، غير أن الزلل فيها قريب ، حتى على كبار مديري الأنظمة وأهل الخبرة. فكم من قاعدة كُتبت بحسن نية وأفسدت الأمر كله.

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

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

ولعل أصعب ما في الأمر أن تتصوّر مسار الرُّزم: كيف تدخل من بطاقة شبكة، ثم كيف تُمرَّر إلى جهاز عبر بطاقة أخرى، وكيف تُطابق هذه الرحلة مع المصطلحات: pass in و pass out و block in و block out و from and to. فكثيرًا ما تخالف هذه الألفاظ ما يتبادر إلى الذهن لأول وهلة.

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

إيضاحات

أحب أن أبدأ بتوضيح جملةٍ من الإعدادات الافتراضية والكلمات الشائعة في مصفي الرزم PF، فكثير من اللبس إنما يأتي من سوء فهمها.

حين نتحدث عن تمرير الحركة إلى الداخل pass in أو إلى الخارج pass out ، فأنفع طريقة للفهم أن تتخيّل رُزم البيانات نفسها. فنحن نُمرِّر إلى الداخل pass in الرُزم الآتية من الحواسيب إلى بطاقة الشبكة NIC (أي من الأجهزة المتصلة بذلك المنفذ)، ونُمرِّر إلى الخارج pass out الرُزم الخارجة من بطاقة الشبكة إلى تلك الأجهزة.

وصيغة القاعدة تكون على أحد وجهين:

إمّا تصفية الرُزم بحسب الوجهة:

from source IP to destination IP [on]  port

أو تصفيتها بحسب المصدر:

from source IP [on] port to destination

والجزء [on] هنا للشرح فقط، وليس جزءًا من صيغة مُصفي الرُزم PF.

• quick

  • إذا طابقت الرزمة قاعدة تمرير pass, أو حظر block أو مطابقة match، ومعها الموصوف quick، فإن مُصفي الرزم يقبل القرار فورًا ولا ينظر في القواعد التي بعدها. وتُعدّ هذه القاعدة آخر ما يُحتكم إليه لتلك الرُزمة.

• keep state

  • لا تحتاج غالبًا لكتابة keep state لقاعدة pass أو block، فحين تطابق الرُزمة قاعدة pass أو block يُنشأ لها حالة تلقائيًا.

وإذا لم تطابق الرُزمة أي قاعدة، يكون الإجراء الافتراضي: تمريرها دون إنشاء حالة.

• on interface/any
  • تُقيِّّّّّّّّّد هذه العبارة القاعدة لتُطبَّق فقط على الرُزم الداخلة أو الخارجة من بطاقة شبكة معيّنة أو مجموعة بطاقات.

أما on any فتنطبق على كل الواجهات الموجودة، ما عدا بطاقة الحلقة المحلية (loopback).

• inet/inet6
  • تدل inet و inet6 على أن هذه القاعدة تخص الرُزم الداخلة أو الخارجة ضمن نطاق توجيه بعينه، فإن قيل inet انصرف إلى IPv4، وإن قيل inet6 اختُصّ بـ IPv6.

ولك أن تُجري القواعد على نطاق التوجيه نفسه دون أن تُسمّي بطاقة شبكة بعينها، فتسري القاعدة حينئذٍ على كل حركة من ذلك النوع في جميع البطاقات. فإذا صرّحت بـ inet فقد قصرت النظر على حركة IPv4 وحدها.

• proto

  • ويكون تقييد القواعد بحسب نوع المعيار باستعمال الموصوف proto. فتُطبَّق القاعدة على الرُزم التابعة لذلك المعيار وحده، ولا تمتدّ إلى غيره. ويمكنك الرجوع إلى ملف /etc/protocols لمعرفة المعايير المعتمدة. ومن أشهرها وأكثرها تداولًا: ICMPو TCP و UDP.

• in و out

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

واعلم أن صفتا in و out لا تُستعملان لمعالجة انتقال الحزم من بطاقة شبكة إلى بطاقة أخرى، فإنما يكون ذلك بترجمة العناوين الشبكية (NAT)، وذلك باستعمال خياري nat-to و rdr-to. وصفتا in و out دورهما مقصور على الحركة الداخلة إلى المنفذ الفيزيائي أو الخارجة منه، لا ما جاوزه إلى غيره.

• from و to
  • يُقصد بهذين الوصفين أن تُقيَّد القاعدة بالرُزم التي لها مصدرٌ ووجهة معلومان، من حيث العنوان والمنفذ، ويجوز لك أن تُهمل اسم المضيف أو عنوانه، أو المنفذ، أو حتى توصيف نظام التشغيل، إن لم يكن لك حاجة.

وعند العمل على موجّهٍ ذي بطاقات شبكة متعددة، يسهل على المرء أن يتوهّم الأمر على هذا النحو: أُمرّر الرُزم الداخلة من البطاقة الخارجية المتصلة بالإنترنت، ثم أجعلها تخرج إلى بطاقة الشبكة الداخلية، ومنها إلى حاسب بعينه. فيتبع المرء في ذهنه أثر الرزمة، ثم يكتبه في قاعدة كهذه: pass in on $ext_if from $ext_if to $dmz port 80. غير أن هذه القاعدة لا تجعل حركة HTTP تظهر في المنفذ 80 على الشبكة الـمحلية LAN عند حاسب ذي عنوان معيّن. بل لا بدّ حينئذٍ من قاعدة pass out، ومن تعيين الجهاز المقصود. والحق أن مثل هذه القواعد لا حاجة إليها في عامة الأحوال، إلا إن كنت بصدد مطلب خاصّ نادر. فخاصية Unicast Reverse Path Forwarding (uRPF) في مُصفي الرزم تكفل حماية الشبكة الداخلية على أحسن وجه، ومع إعدادٍ سليم لترجمة العناوين (NAT) باستعمال nat-to، وإعادة التوجيه بـ rdr-to، يتولى مُصفي الرزم تدبير الحزم من الداخل إلى الخارج وبالعكس دون عناء.

أما المعامل all فهو نظير قولك from any to any. بل إن هذا هو الأصل ما لم يصرّح بخلافه. فقولك مثلا: pass in on $dmz proto udp to port dns يؤول في حقيقته إلى: pass in on em3 inet proto udp from any to any port = 53

ولا حاجة الى كتابة to any port dns، لأن any مفهومة ضمناً، غير أن تعيين المنفذ بـ to port dns لا غنى عنه.

• nat-to و rdr-to
  • تُعنى صفتا nat-to و rdr-to بترجمة عناوين الشبكة (NAT)، إذ إذ تُغيّران عنوان المصدر أو الوجهة، أو المنفذ، للرزم المرتبطة باتصال ذي حالة. ويقوم مصفي الرُزم PF عند ذلك بتعديل العنوان أو المنفذ المحدد، ثم يُعيد حساب قيم التحقق الخاصة بـ IP و TCP و UDP كلما اقتضى الأمر.

وتدل nat-to على أن عناوين الرزم تُبدّل وهي تعبر بطاقة بعينها،. وبذلك يُمكِّن عنوانٌ عام واحد — أو عناوين قليلة — على الموجّه من خدمة عدد كبير من الأجهزة الكائنة خلفه في الشبكة الداخلية، أعني شبكة الـ LAN.

وغالب استعمال nat-to يكون للحزم الخارجة، أي تلك المنصرفة من الشبكة الداخلية إلى الإنترنت. ولا يُدعم توجيه nat-to إلى عنوانٍ محلي.

أما rdr-to فموضعها الغالب في الحزم الداخلة، إذ تُعيد توجيه الحركة الواردة من الإنترنت إلى جهازٍ أو خدمة داخل الشبكة المحلية.

• قائمة العناصر ونطاقات العناوين والمنافذ
  • إذا احتجت إلى تعيين أكثر من عنصر — كأن تُحدّد عدة منافذ — جاز لك أن تفصل بينها بمسافة أو بفاصلة، فتقول مثلًا: port { 53 853 } أو port { 53, 853 }

وأما نطاقات العناوين فتُبَيَّن باستعمال الشرطة -، فقولك: 192.168.1.2 - 192.168.1.10 يعني جميع العناوين الـشبكية IP من 192.168.1.2 إلى 192.168.1.10 داخلين في الحكم.

وأما نطاقات المنافذ فلها صيغ متعددة وأحكام متفرعة، يُرجع فيها إلى كتيّب pf.conf، وتنظر تحت العبارة: “Ports and ranges of ports are specified using these operators”، ففيها البيان الشافي.

حلّ أسماء النطاقات وأسماء المضيفين

إذا عزمتَ على استعمال أسماء المضيفين (hostnames) و/أو أسماء النطاقات (domain names) في إعداد مصفي الرزم لديك، فاعلم أن جميع عمليات حلّ الأسماء لا تتم إلا عند تحميل مجموعة القواعد. ومعنى ذلك أنه إذا تغيّر العنوان الشبكي المرتبط بمضيفٍ أو نطاقٍ ما، وجب إعادة تحميل القواعد حتى ينعكس هذا التغيير داخل النواة.

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

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

وفي «أوبن بي إس دي» يبدأ مصفي الرزم عمله قبل تشغيل Unbound أو غيره من خوادم نظام أسماء النطاقات، وهذا هو الترتيب السليم من الناحية الأمنية.

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

القواعد

من الحكمة أن تختبر القواعد على جهازٍ تجريبي قبل اعتمادها نهائيًا؛ فغالبًا ما تتعدد السُّبل المؤدية إلى النتيجة نفسها. وبرأيي المتواضع، خيرُ تلك السبل ما كان أوضح لك فهمًا وأسهل عليك إدراكًا.

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

يمكنك دائمًا تحليل القواعد والتحقّق من خلوّها من الأخطاء دون تفعيلها، وذلك بالأمر: pfctl -nf /etc/pf.conf. فإذا اطمأننتَ إلى سلامتها، أمكنك تحميلها بالأمر: pfctl -f /etc/pf.conf وبعد التحميل، تستطيع الاطّلاع على الصيغة التي حوّل بها مصفي الرزم (PF) القواعد داخليًا باستخدام الأمر: pfctl -s rules وأوصي بالمواظبة على استعماله؛ إذ يُعين على الفهم والمراجعة واكتشاف ما قد يخفى.

وأميل إلى تنظيم القواعد في أقسام واضحة، مع الإكثار من التعليقات، ليظلّ الملف مقروءًا مفهومًا، وسأسير على هذا النهج في هذا المثال كذلك.

افتح الآن الملف /etc/pf.conf باستعمال محرّر النصوص الذي تألفه.

وسنبدأ أولًا بتعريف بعض المُعرِّفات (macros)، لتسهيل تذكّر أيّ بطاقات الشبكة (NICs) نستخدم، ولأي غرض خُصِّصت. كما أنّ اعتماد هذه المعرّفات يجعل تغيير اسم برنامج تشغيل البطاقة أمرًا يسيرًا، إن استُبدلت البطاقة لاحقًا أو أُضيفت بطاقات جديدة.

#---------------------------------#
# المُعرِّفات (Macros) 
#---------------------------------#

ext_if="em0" # كرت الشبكة الخارجي المتصلة بمودِم مزوّد الخدمة (NIC). 
g_lan="em1"  # شبكة البالغين المحلية. 
c_lan="em2"  # شبكة الأطفال المحلية.
dmz="em3"    # الشبكة العامة (المنطقة المعزولة DMZ).

ثم ننتقل بعد ذلك إلى إعداد جدولٍ للعناوين غير القابلة للتوجيه (non-routable IP addresses). نقوم بهذا الإجراء لأنّ من أشيع أخطاء تهيئة الشبكات السماحُ بمرور حركة تحمل عناوين غير قابلة للتوجيه إلى شبكة الإنترنت. وهذه عناوين لا ينبغي لها، من حيث الأصل، أن تظهر خارج الشبكات المحليّة. وسنستعمل هذا الجدول ضمن مجموعة القواعد لحظر أي محاولة لبدء اتصال بعناوين غير قابلة للتوجيه عبر بطاقة الشبكة الخارجيّة للموجّه (external NIC). وبهذا نمنع تسرّب هذا النوع من الحركة إلى الإنترنت، ونغلق بابًا من أبواب الخلل وسوء الضبط قبل وقوعه.

#---------------------------------#
# الجداول (Tables) 
#---------------------------------#

# جدول بالعناوين الخاصة غير القابلة للتوجيه عبر الإنترنت.
table <martians> { 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8 169.254.0.0/16     \
                   172.16.0.0/12 192.0.0.0/24 192.0.2.0/24 224.0.0.0/3 \
                   192.168.0.0/16 198.18.0.0/15 198.51.100.0/24        \
                   203.0.113.0/24 }

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

#---------------------------------#
# الحماية والحظر الافتراضي 
#---------------------------------#

set skip on lo0

# حماية من انتحال العناوين على جميع كروت الشبكة.
block in from no-route
block in quick from urpf-failed

# حظر العناوين الخاصة غير القابلة للتوجيه. 
# نستخدم المعلمة "quick" لجعل هذه القاعدة فاصلة ولا يُنظر لما بعدها. 
block in quick on $ext_if from <martians> to any
block return out quick on $ext_if from any to <martians>

# الحظر الافتراضي لكل حركة البيانات الداخلة عبر كروت الشبكات المحلية،
# من أي حاسب أو جهاز متصل بها.
block return in on { $g_lan $c_lan $dmz }

# الحظر الافتراضي لكل حركة البيانات الداخلة من الإنترنت عبر كروت الشبكة الخارجية،
# مع تسجيلها في السجل.
block drop in log on $ext_if

# السماح بمعيار ICMP.
match in on $ext_if inet proto icmp icmp-type {echoreq } tag ICMP_IN
block drop in on $ext_if proto icmp
pass in proto icmp tagged ICMP_IN max-pkt-rate 100/10

# نحتاج أن يكون للموجّه اتصال بالإنترنت،
# لذا نُجيز افتراضًا مرور الرزم الخارجة من الموجّه
# عبر الكرت الخارجي إلى الإنترنت.
pass out inet from $ext_if

إن العناوين الـشبكية (IP) المندرجة في المعرف martians هي عناوين RFC1918 ، وهذه عناوين خُصِّصت للاستعمال الداخلي، ولا موضع لها على شبكة الإنترنت العامّة. ولما كانت هذه العناوين لا تنتمي إلى الفضاء العام للشبكة، سُمّيت martians، كأنها أتت من المريخ، ويُطلق عليها كذلك اسم bogons. وأيّ حركة مرورٍ صادرةٍ من هذه العناوين أو واردةٍ إليها تُسقَط عند البطاقة الخارجيّة للموجّه، إذ لا خير في استقبالها ولا في تمريرها، وحجبها من صميم الحيطة وسلامة الإعداد.

في الإصدارات السابقة من هذا الدليل -قبل النسخة 1.5.0- كنتُ أُدرج قاعدة scrub ضمن الإعدادات المقَدمَة أعلاه. غير أنّي، بعد مشاورة هننغ براور -له الشكر- من فريق «أوبن بي إس دي»، والاطلاع على مزيدٍ من البحث والتوثيق، آثرتُ حذفها؛ إذ تبيّن لي أنّها تُعالج حالاتٍ نادرة مخصوصة، لا يحتاجها عموم المستخدمين (ومن أراد التفصيل فليراجع الكتيّبات). فأنت لا تحتاج إلى قاعدة scrub إلا إذا كان في شبكتك مضيفٌ يُنشئ حزمًا مُجزّأة مع ضبط راية عدم التجزئة (dont-fragment). أمّا السلوك الافتراضي لـمصفي الرزم عند الاستغناء عن هذه القاعدة، فهو في الجملة أنسب وأقوم للاستعمال العام.

وتجدر الإشارة إلى أنّ أسئلة «أوبن بي إس دي» الشائعة تورد مثالًا لإعداد موجّهٍ بسيط، وفيه قيم معيّنة لقاعدة scrub. غير أنّ نصيحتي — عن تجربة — ألا تُدخل هذه القاعدة إلا إذا كنتَ على يقينٍ تامٍّ من حاجتك إليها. فإن دعتك الضرورة لاستعمالها، فموضعها الصحيح أن تُدرج بعد قاعدة set skip الخاصة ببطاقة loopback، على هذا النحو.

set skip on lo0
match in all scrub

ثم بعد ذلك أضِف إلى قاعدة scrub ما تحتاجه من معاملات وضوابط، بحسب حال شبكتك ومتطلباتها.

و كنتُ فيما مضى أُدرج القاعدة الآتية من قواعد antispoof ضمن قسم الحماية من الانتحال (spoofing protection)، قبل أن أُعيد النظر في موضعها واستعمالها.

antispoof quick for { $g_lan $c_lan $dmz }

ثم إني عدلتُ عن استعمال قاعدة antispoof إذ تبيّن أن خاصية Unicast Reverse Path Forwarding (uRPF) في مصفي الرزم تؤدي الغرض نفسه ، فلا حاجة لنا بها بعد اليوم. وعليه اكتفينا بالقاعدة: block in quick from urpf-failed فهي أبلغ في المقصود وأوجز في السبك.

ومع ذلك أبقيتُ الحديث عن معامل antispoof هنا لا للعمل به، بل للتعليم والفهم.

والانتحال (Spoofing) هو أن يتزيّا المهاجم بغير زيه، فيزوّر العنوان الـشبكي، فيُظهر الرزمة كأنها صادرة من غير مصدرها. ومعامل antispoof ما هو إلا اختصار يتوسّع به مصفي الرزم إلى مجموعة من قواعد التصفية، غايتها حظر كل حركة يكون عنوان مصدرها من شبكةٍ موصولة مباشرة بواجهةٍ معيّنة، ثم تحاول النفاذ إلى النظام عبر واجهةٍ أخرى غير تلك. ويُسمّى هذا عند أهل الصنعة «تسرّب العناوين» أو «تجاوز الواجهات»، إذ ينزلق العنوان من موضعه المشروع إلى موضعٍ ليس له.

وأما توجيه antispoof المذكور آنفًا، فإن مصفي الرزم (PF) لا يتركه على إجماله، بل يفسّره ويحوّله إلى قواعد صريحة مفصّلة، على النحو التالي:

block drop in quick on ! em1 inet from 192.168.1.0/24 to any
block drop in quick inet from 192.168.1.1 to any
block drop in quick on ! em2 inet from 192.168.2.0/24 to any
block drop in quick inet from 192.168.2.1 to any
block drop in quick on ! em3 inet from 192.168.3.0/24 to any
block drop in quick inet from 192.168.3.1 to any

فلو أخذنا – على سبيل المثال – قاعدة البطاقة em1 الآتية: block drop in quick on ! em1 inet from 192.168.1.0/24 to any فمعناها: حظرُ كلِّ حركةٍ صادرةٍ من شبكة عناوينها من 192.168.1.1 إلى 192.168.1.255، إذا لم تكن واردةً من البطاقة em1 نفسها، أياً كانت وجهتها. ووجه ذلك أن البطاقة em1 هي المسؤولة عن هذا النطاق من العناوين، فلا يُتصوَّر – ولا يُسمَح – أن تصدر حزمٌ تحمل هذه العناوين من واجهةٍ أخرى؛ فإن وقع ذلك كان قرينةً على انتحالٍ أو خلل.

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

ونحن نسمح بمرور ICMP في هذا الإعداد، بالرغم من أن بعض مديري الشبكات يعمدون إلى حجبه حجبًا تامًّا. وإنما يلجأ هؤلاء إلى ذلك خوفًا من ممارساتٍ غير مشروعة، كاستكشاف الشبكات، وإنشاء قنوات اتصالٍ خفيّة، ومسح العناوين بالـ ping sweep, وإغراق الشبكة بالـping flood, وتمرير البيانات عبر أنفاق ICMP tunneling أو ICMP redirecting. غير أن ICMP أوسع شأنًا من الردّ على طلبات ping. فهو ركنٌ أساس في تشخيص الأعطال، وضبط الاعتمادية، وتحسين أداء الشبكة. فإذا حُجب المعيار حجبًا كليًّا تعطّلت آلياتٌ مهمّة يعتمد عليها النظام في الإبلاغ عن الأخطاء، وتحديد المسارات، والتعامل السليم مع حالات الفشل.

ومن جملة الأسباب التي تجعل حجب ICMP حجبًا مطلقًا أمرًا مذموماً:

• يُستعمل (Path MTU Discovery – PMTUD) لمعرفة أكبر حجمٍ للرزمة يمكن أن تعبُر أجهزة الشبكة الواقعة بين المصدر والوجهة دون أن تتجزأ. ويعتمد معيار TCP في ذلك على رسائل ICMP من النوع (3) والرمز (4). فإذا تجاوزت الرزمة حجم الـ MTU لجهازٍ ما في الطريق، أعاد ذلك الجهاز رسالة ICMP تُبيّن الخطأ وتذكر الحجم الأقصى المسموح به. فإذا حُجبت هذه الرسائل، ظلّ النظام الوجهة يطلب الرزم التي لم تصله، وظلّ المصدر يعيد إرسالها عبثًا، لا تبلغ غاية ولا تحلّ عقدة، حتى تنشأ ما يُعرف بالثقب الأسود لـ ICMP، فتختنق الاتصالات وتتعطّل عمليات الإرسال.
• يحدد زمن الحياة (Time to live TTL) العمر الأقصى لرزمة البيانات في الشبكة. فإذا حُجب ICMP، لم تصل رسائل الخطأ من النوع (11) والرمز (0) التي تُفيد بانقضاء زمن الحياة أثناء العبور. وبذلك لا يُخطر المضيفُ المصدرُ بضرورة زيادة قيمة TTL، فتظل الرزم تفشل في بلوغ مقصدها دون علمٍ بسبب الفشل ولا سبيل إلى تصحيحه.
• تدنّي الأداء بسبب حجب (ICMP Redirect). فتُستعمل رسائل إعادة التوجيه ليُعلم الموجّهُ المضيفَ بوجود مسارٍ أقصر وأكفأ إلى الوجهة المقصودة، مما يقلّل عدد القفزات التي تقطعها البيانات. فإذا مُنع ICMP، بقي المضيف جاهلًا بالمسار الأمثل، فسلك طرقًا أطول وأثقل، وانخفض الأداء تبعًا لذلك.

في الإعداد المتقدّم آنفًا أجزنا ICMP، غير أنّا قيّدناه بقيودٍ تردع الإفراط، فجعلنا له حدًّا في المعدّل، حتى لا يُستغل في الإزعاج أو الإغراق. فبالمُعدِّل max-pkt-rate 100/10 لا يجيب الموجّه على طلبات ping إذا جاوز الواردُ مئة طلبٍ في عشر ثوانٍ، فيسكت بعد الحدّ، ويكفّ عن الاستجابة.

وبعد هذا ننتقل إلى الشبكة الخاصة بالبالغين في الدار.

#---------------------------------#
# إعداد شبكة البالغين
#---------------------------------#

# السماح لأي حاسب أو جهاز على شبكة البالغين
# بإدخال الرزم عبر هذا الكرت.
# أي جهاز متصل بهذا الكرت يمكنه إرسال البيانات
# إلى أي وجهة: الإنترنت أو بقية الأجهزة المتصلة بالموجّه.
pass in on $g_lan

# حظر استعلامات «نظام اسماء النطاقات» التي لا تتجه إلى خادم ال«نظام اسماء النطاقات» الخاص بنا.
block return in quick on $g_lan proto { udp tcp } to ! $g_lan port { 53 853 }

# لدي طابعة شبكية لا أريد لها الاتصال بخوادمها الخارجية،
# لذا أقوم بحظرها.
# عنوان الطابعة هو 192.168.1.8.
block in quick on $g_lan from 192.168.1.8

# السماح بمرور الرزم من الموجّه إلى الخارج عبر كرت البالغين
# نحو الأجهزة المتصلة بها.
# من دون هذه القاعدة لا يمكن حتى تنفيذ ping
# من الموجّه إلى أجهزة شبكة البالغين.
pass out on $g_lan inet keep state

في هذا المثال لديَّ طابعةٌ شبكية موصولة بشبكة البالغين، ولا أرغب أن يكون لها أي اتصال بالإنترنت ولا بغيره، احتياطًا لما قد يكون فيها من برمجياتٍ متجسِّسة أو سلوكٍ غير مأمون. ولأجل ذلك أقرِّر حظر كل حركة بياناتٍ تدخل عبر البطاقة em1، إذا كان مصدرها العنوان 192.168.1.8، متجهةً إلى أي عنوانٍ كان._.

وكذلك نحرص على أن تكون جميع طلبات «نظام اسماء النطاقات» على المنفذين 53 (وهو «نظام اسماء النطاقات» التقليدي) و 853 (وهو «نظام اسماء النطاقات» عبر TLS) محظورةً دائمًا، ما لم تكن موجَّهة إلى خادم «نظام اسماء النطاقات» الخاص بنا. وبهذا نمنع الأجهزة من الالتفاف على سياسات الحجب أو استخدام خوادم أسماءٍ خارجية دون علمنا، ونُبقي حلَّ الأسماء تحت سيطرة الموجّه وحده.

جزء شبكة الأطفال من الشبكة المحلية يشبه ما سبق.

#---------------------------------#
# إعداد شبكة الأطفال 
#---------------------------------#

# السماح لأي حاسب أو جهاز على شبكة الأطفال بإدخال رُزم البيانات
# عبر بطاقة الشبكة. أي إن كل جهاز موصول بهذه البطاقة
# يُسمح له بإرسال البيانات إلى أي جهة، سواء إلى الإنترنت
# أو إلى أي جهاز موصول بالموجّه.
pass in on $c_lan

# حظر جميع استعلامات «نظام اسماء النطاقات» التي لا تكون موجَّهة إلى خادم «نظام اسماء النطاقات» الخاص بنا.
block return in quick on $c_lan proto { udp tcp} to ! $c_lan port { 53 853 }

# السماح بمرور رُزم البيانات من الموجّه إلى الخارج عبر بطاقة شبكة الأطفال
# نحو الحواسيب والأجهزة المتصلة بها.
# وبدون هذا الإذن لن نتمكن حتى من تنفيذ أمر ping
# من الموجّه نفسه إلى أجهزة شبكة الأطفال.
pass out on $c_lan inet keep state

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

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

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

#---------------------------------#
# DMZ Setup
#---------------------------------#

# السماح لأي حاسب أو جهاز موصول ببطاقة DMZ بإجراء استعلامات «نظام اسماء النطاقات»
# (أزل التعليق عند الحاجة).
#pass in on $dmz inet proto udp from any port 53

# حظر جميع طلبات «نظام اسماء النطاقات» التي لا تكون موجّهة إلى خادم «نظام اسماء النطاقات» على الراوتر. 
block return in quick on $dmz proto { udp tcp} to ! $dmz port { 53 853 }

# عند الرغبة في تمكين أي حاسب موصول بواجهة DMZ من النفاذ إلى الإنترنت،
# أزل التعليق عن هذا السطر لفتح الوصول.
# وهذا عند ترقية النظام أو تحديثه.
#pass in on $dmz inet

# مهما يكن، لا نريد لقطاع DMZ أن يصل إلى أي من قطاعات الشبكة الأخرى،
# لذا نصرّح بالحظر صراحة في النهاية.
#
# لدينا أكثر من خيار. فلو استعملنا مثلًا:
#
#   block drop in on $dmz to 192.168/16
#
# فإننا نحظر الوصول إلى جميع الشبكات الفرعية،
# غير أن هذا يمنع كذلك الأجهزة الموصولة بـ DMZ
# من إجراء استعلامات «نظام اسماء النطاقات» عند الحاجة إلى التحديث.
#
# وفي تقديري أن التصريح الصريح أدقّ وأحكم،
# فنحظر فقط القطاعات التي نريد منع الوصول إليها.
#
# هذا السطر يمنع الحواسيب الموصولة بواجهة DMZ
# من الوصول إلى أي حاسب أو جهاز في القطاعين الآخرين. 
block drop in on $dmz to { $g_lan:network $c_lan:network }

# أخيرًا، لا بد من السماح بمرور الرزم الصادرة من بطاقة DMZ
# إلى الأجهزة الموصولة بها، وإلا فلن يتمكن أحد من «مخاطبتها».
# وبدون هذا السطر لا يمكن حتى تنفيذ ping من الراوتر
# إلى الأجهزة المتصلة ببطاقة DMZ.
pass out on $dmz inet keep state

والآن نصل إلى ترجمة عناوين الشبكة (NAT)؛ وهي الموضع الذي يتولّى فيه الموجّه نقل الرزم بين مقاطع الشبكة المختلفة — وفي مثالنا هذا من شبكتنا الداخليّة إلى شبكة الإنترنت الخارجية — ثم إعادة توجيه الردود الواردة من الإنترنت إلى صاحب الطلب في الداخل. وأفضّل استعمال الوسيط :network ، إذ يُعبّر عن الشبكة (أو الشبكات) المتصلة بالبطاقة نفسها، كما أفضّل التصريح والتخصيص بقاعدة واحدة لكل مقطع ذي صلة.

#---------------------------------#
# NAT — ترجمة عناوين الشبكة 
#---------------------------------#

pass out on $ext_if inet from $g_lan:network to any nat-to ($ext_if)
pass out on $ext_if inet from $c_lan:network to any nat-to ($ext_if)
pass out on $ext_if inet from $dmz:network to any nat-to ($ext_if)

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

ثم نصل أخيرًا إلى قسم إعادة التوجيه في قواعدنا؛ وفيه نتيح لحركةٍ قادمة من الإنترنت من الخارج أن تُوجَّه إلى خادم الويب العلني الموضوع على بطاقة DMZ. وينبغي — بطبيعة الحال — ترك هذا القسم إن لم تكن لديك خوادم عامة تحتاج إلى إعادة توجيه. وفي هذا المثال لا نتيح إلا حركة IPv4.

#---------------------------------#
# Redirects
#---------------------------------#

# خادم الويب لدينا هو 192.168.3.2 — دع الإنترنت يصل إليه.
pass in on $ext_if inet proto tcp to $ext_if port { 80 443 } rdr-to 192.168.3.2

وبذا نكون قد أنهينا إعدادنا الأساسي لقواعد جدار الحماية.

قائمة السماح الخاصة بالأطفال

إذا أردت حجب الإنترنت كاملًا عن الأطفال مع استثناء عدد محدود من المواقع أو ربما بعض خوادم الألعاب، فعليك أولًا معرفة العناوين الشبكية (IP) الخاصة بهذه الخدمات، ومن ثم إنشاء قائمة سماح (pass list) باستخدام تلك العناوين.

وإذا كان الأمر يتعلق بموقع واحد يملك عنوان شبكي واحدًا، فسهل جدًا، ويمكنك فعل ذلك بهذه القاعدة التي توضع في آخر قسم إعدادات شبكة الأطفال (مع استبدال x.x.x.x بالعنوان الـشبكي المناسب):

#---------------------------------#
# إعداد شبكة الأطفال
#---------------------------------#

# اسمح لأي حاسب أو جهاز متصل بكرت شبكة الأطفال بإرسال
# طلبات «نظام اسماء النطاقات».
pass in on $c_lan inet proto udp from any port 53

# امنع طلبات «نظام اسماء النطاقات» التي لا تكون موجهة إلى خادم «نظام اسماء النطاقات» الخاص بنا.
block return in quick on $c_lan proto { udp tcp} to ! $c_lan port { 53 853 }

# ثم اسمح لأي حاسب أو جهاز على شبكة الأطفال بالوصول
# إلى العنوان الـشبكي IP x.x.x.x فقط.
pass in on $c_lan to x.x.x.x

فإن كان للموقع أكثرُ من عنوانٍ شبكيّ، وجب عليك استقصاء جميع العناوين. فكثيرًا ما يكشفُ طلبُ الاستعلام عن النطاق دفعةً واحدةٍ جميعَ العناوين ذات الصلة، كأن تُجري مثلًا: $ dig example.com ANY أو drill example.com ANY. غيرَ أنّ الأمر لا يكون دومًا بهذا اليسْر؛ ففي أحايين أخرى يلزمك تكرارُ الاستعلام في أوقاتٍ متباينة من اليوم، حتى تستوفي نطاق العناوين كلَّه. ولَكَ أن تُنيب عن نفسك سكربتًا آليًّا ينهض بهذه المهمّة، فيتولّى جمعها على مَهَلٍ بلا عناء.

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

وفي هذا المثال نُضيف جدولًا جديدًا إلى قسم الجداول في القواعد، ثم نُعدِّل إعدادات قسم شبكة الأطفال:

#---------------------------------#
# الجداول
#---------------------------------#

...

# قائمة السماح للأطفال
table <passlist> { x.x.x.x y.y.y.y z.z.z.z }

ثم نغيّر في قسم الأطفال السطر:

pass in on $c_lan to x.x.x.x

إلى:

pass in on $c_lan to <passlist>

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

إستعمال جدول دائم

ومنهجٌ آخر في جمع العناوين الشبكية اللازمة لقائمة السماح أن تُنشئ جدولًا دائمًا (persistent table)، وتستعين به مع الملف /etc/rc.local واستعلامات أسماء النطاقات. ويُنفَّذ الملف /etc/rc.local بعد تشغيل مصفي الرزم، وبذلك لا تؤثر مشكلات حلّ أسماء النطاقات في تحميل القواعد أو استقرار عمل مُصفي الرزم.

فإذا أردتَ استعمال جدولٍ دائم، فأضِفه إلى قسم الجداول في الملف /etc/pf.conf:

table <passlist> persist

وفي قسم شبكة الأطفال، يبقى من اللازم السماح بحركة البيانات المتجهة إلى قائمة السماح، كما في المثال السابق:

pass in on $c_lan to <passlist>

ثم أضف إلى الملف /etc/rc.local الأمر الآتي:

pfctl -t passlist -T add example.com

حيث إن example.com هو اسم النطاق الذي تريد من مصفي الرزم استخراج عناوينه الشبكية وإضافتها إلى الجدول.

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

$ doas pfctl -t passlist -T add examples.com

ولعرض العناوين الشبكية الموجودة في قائمة السماح، استعمل الأمر:

$ doas pfctl -t passlist -T show
74.6.143.25
74.6.143.26
74.6.231.20
74.6.231.21
98.137.11.163
98.137.11.164
216.58.208.110
2001:4998:24:120d::1:0
2001:4998:24:120d::1:1
2001:4998:44:3507::8000
2001:4998:44:3507::8001
2001:4998:124:1507::f000
2001:4998:124:1507::f001
2a00:1450:400e:80e::200e

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

table <passlist> persist file "/etc/pf-passlist.txt"

تحميل القواعد

بعد الفراغ من إعداد القواعد، اختبر سلامتها بالأمر:

$ doas pfctl -nf /etc/pf.conf

فإذا لم تظهر أخطاء، فحمِّل قواعد جدار الحماية بإزالة الخيار -n:

$ doas pfctl -f /etc/pf.conf

وللاطلاع على القواعد بعد أن يفسِّرها مُصفي الرزم ويحوِّلها إلى صيغتها الداخلية، استعمل الأمر:

$ doas pfctl -s rules

لا تُحاوِل حجب «معيار تهيئةُ المُضيف الآلية DHCP»

على سبيل التنبيه، لا يمكنك حجب حركة DHCP المتجهة إلى dhcpd (المنفذ 67) باستعمال مصفي الرزم، ذلك لأن كلًّا من dhcpd وdhclient في نظام «أوبن بي إس دي» يستعملان — افتراضيًّا — bpf في إرسال الرزم واستقبالها. وهذا يعني أنّ الرزم تُرسَل وتُستقبَل قبل أن يباشر مصفي الرزم عمله.

ولأن bpf يوفّر وصولًا مباشرًا إلى طبقة ربط البيانات (Data Link Layer) دون الاعتماد على بروتوكولٍ بعينه، فإنه يستطيع رؤية جميع الرزم المارّة عبر بطاقة الشبكة، حتى تلك الموجَّهة إلى أجهزة أخرى على الشبكة.

ولهذا السبب لا تنطبق قواعد التصفية على حركة DHCP بالطريقة المعتادة التي تنطبق بها على بقية معيارات TCP/IP.

ولمن أراد مزيدًا من التفصيل، فليراجع المناقشة الموسومة ب«allow dhcpd with pf» في قوائم «أوبن بي إس دي» البريدية، ففيها تعليقـات نافعة تشرح هذا السلوك وأسبابه.

الرصد والتسجيل (Logging and monitoring)

وهذا مثالٌ من مخرجات سجلّ مصفي الرزم يُظهِر محاولاتٍ محجوبةً للوصول إلى بطاقة الشبكة الخارجية في أحد إعداداتي. وقد نقّيتُ المخرجات قليلًا وحذفتُ بعض البيانات المحدّدة، كما أنّ العنوان 0.0.0.0 ليس — بطبيعة الحال — عنواني العلني، ولكن لا شكّ أنّك أدركت ذلك آنفًا ;)

$ doas tcpdump -n -e -ttt -r /var/log/pflog
23:11:12 rule 14/(match) block in on em0: 45.129.33.4.45980 > 0.0.0.0.3422: S 1501043655:1501043655(0) win 1024
23:11:12 rule 14/(match) block in on em0: 45.129.33.4.45980 > 0.0.0.0.3481: S 311078394:311078394(0) win 1024
23:11:31 rule 14/(match) block in on em0: 176.214.44.229.25197 > 0.0.0.0.23: S 2084440900:2084440900(0) win 33620
23:11:33 rule 14/(match) block in on em0: 45.129.33.4.45980 > 0.0.0.0.3431: S 2774981044:2774981044(0) win 1024
23:11:43 rule 14/(match) block in on em0: 81.68.114.52.17191 > 0.0.0.0.23: S 1346864438:1346864438(0) win 26375
23:12:08 rule 14/(match) block in on em0: 193.27.229.26.53865 > 0.0.0.0.443: S 1057596009:1057596009(0) win 1024
23:12:31 rule 14/(match) block in on em0: 45.129.33.4.45980 > 0.0.0.0.4186: S 1233742605:1233742605(0) win 1024
23:12:44 rule 14/(match) block in on em0: 74.120.14.70.65509 > 0.0.0.0.9125: S 1836577847:1836577847(0) win 1024 <mss 1460> [tos 0x20]
23:12:44 rule 14/(match) block in on em0: 45.129.33.4.45980 > 0.0.0.0.4128: S 2112968453:2112968453(0) win 1024
23:13:15 rule 14/(match) block in on em0: 45.129.33.4.45980 > 0.0.0.0.3669: S 3627248539:3627248539(0) win 1024
23:13:19 rule 14/(match) block in on em0: 45.129.33.4.45980 > 0.0.0.0.3654: S 3889665614:3889665614(0) win 1024
23:13:29 rule 14/(match) block in on em0: 45.129.33.129.42239 > 0.0.0.0.4997: S 2249816896:2249816896(0) win 1024
23:13:37 rule 14/(match) block in on em0: 45.129.33.4.45980 > 0.0.0.0.3612: S 3797528151:3797528151(0) win 1024
23:14:03 rule 14/(match) block in on em0: 190.207.89.17.64372 > 0.0.0.0.445: S 1097568353:1097568353(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> (DF)
23:14:15 rule 14/(match) block in on em0: 45.129.33.4.45980 > 0.0.0.0.4219: S 2834775769:2834775769(0) win 1024
23:14:39 rule 14/(match) block in on em0: 45.129.33.4.45980 > 0.0.0.0.3702: S 1855726637:1855726637(0) win 1024
23:14:39 rule 14/(match) block in on em0: 45.129.33.4.45980 > 0.0.0.0.4210: S 3052103070:3052103070(0) win 1024

على ما ترى، فالسجل مزدحمٌ بالحركات، مع أنّه لا توجد في ذلك الإعداد أيةُ خدمةٍ مكشوفةٍ إلى الإنترنت.

ويمكنك كذلك مراقبة مصفي الرزم آنيًّا بالأمر التالي:

$ doas tcpdump -n -e -ttt -i pflog0

خدمة أسماء النظاقات (DNS)

خدمةُ أسماء النطاقات (DNS) إنما وُضعت لتكون الترجمانَ بين الأسماء والعناوين؛ فهي تُحوِّل اسمَ النطاق إلى عنوانٍ شبكيٍّ أو تُعيده بالعكس. فحين يكتب المرء في المتصفّح «wikipedia.org» يتولّى خادمُ أسماءٍ مُخَوَّل ترجمةَ هذا الاسم إلى عنوانٍ من عناوين IPv4 — نحو: 91.198.174.192 — أو إلى عنوانٍ من عناوين IPv6 — كـ 2620:0:862:ed1a::1.

ولهذه الخدمة وظائفُ أُخَرُ جمّة، منها — على سبيل المثال — تسجيلُ الخوادم البريدية التي يتبعها نطاقٌ معيّن، إن كان له من خادم بريد.

وإن كنتَ على نظامٍ شبيهِ بيونكس، فافتح الترمينال، وجَرِّب استعلامَ الاسم يدويًّا بأداة host، على نحوٍ كهذا:

$ host wikipedia.org
wikipedia.org has address 91.198.174.192
wikipedia.org has IPv6 address 2620:0:862:ed1a::1
wikipedia.org mail is handled by 10 mx1001.wikimedia.org.
wikipedia.org mail is handled by 50 mx2001.wikimedia.org.

وهذه جملةُ مصطلحاتٍ تُستعمل في عالم DNS:

• Forward DNS

  • وهو إسنادُ أسماءِ الأجهزة والنطاقات إلى العناوين الشبكية.

• Reverse DNS

  • وهو إسنادُ العناوين الشبكية إلى أسماءِ الأجهزة والنطاقات.

• Resolver

  • هو النظام الذي تستفهمُ منه الآلةُ خادمَ الأسماء عن معلومات المنطقة (zone)، أي هو — من وجهٍ آخر — هو المكوّن البرمجي المسؤول عن إجراء استعلامات «نظام أسماء النطاقات» نيابةً عن التطبيقات.

• Root zone

  • وهي مبدأُ شجرةِ نطاقات الإنترنت؛ فجميعُ المناطق تندرج تحتمنطقة الجذر، كما تندرج جميعُ الملفات تحت المسار الجذر / في أنظمة الملفات.

ومثالُ ذلك في تقسيم المناطق:

• الرمز . (النقطة) هو الاسمُ الشائع لمنطقة الجذر في الكتب والوثائق.
• النطاق org. هو نطاقٌ أعلى (TLD) تحت الجذر.
• النطاق wikipedia.org. يقع تحت النطاق org.
• والمنطقة 1.168.192.in-addr.arpa تشير إلى العناوين الشبكية الواقعة ضمن المجال 192.168.1.*.

فإذا احتاج حاسبٌ على الشبكة إلى حلِّ اسمِ نطاق، عمد المُحَلِّل إلى تقسيم الاسم إلى مقاطعه من اليمين إلى اليسار. فيستعلم أولًا عن نطاق المستوى الأعلى (TLD) عبر خادمٍ جذريٍّ ليحصل على الخادم المخوَّل المسؤول عنه؛ ثم يتابع الاستعلامُ طبقةً بعد طبقة، حتى يبلغَ خادمًا يُعيد الجوابَ النهائي المطلوب.

ومع أنّ أيَّ خادمٍ محلِّيٍّ قد يستطيع إنشاء خوادم جذريّةٍ خاصّةٍ به، فإن اصطلاح «خوادم الجذر» يُطلق — في الغالب — على الخوادم الجذرية الثلاثة عشر المنطقية التي تُجَسِّد مساحةَ أسماء الجذر لنظام أسماء النطاقات على الإنترنت. ويستعمل المُحَلِّلون ملفًا صغيرًا يُسمّى root.hints — حجمه قرابة 3 كيلوبايت — تصدره Internicلتهيئة قائمة عناوين تلك الخوادم. وفي برامج كثيرة — مثل Unbound — تكون هذه القائمةُ مضمَّنةً داخل البرنامج نفسه.

وعلى قاعدة بيانات منطقة الجذر (The Root Zone Database) يمكنك الاطلاعُ على تفاصيل تفويض نطاقات المستوى الأعلى، سواءً العامة منها كـ .com و .org، أو نطاقات الدول كـ .uk و .de.

يوجد نوعان أساسيّان من إعدادات خوادم «نظام اسماء النطاقات»:

• Authoritative
  • أولها الخادمُ الـموثوق (Authoritative) هو الذي يتولّى نشر عناوين النطاقات التي هو مسؤول عنها، فيجيب إجابةً واضحة قاطعة، لأنه صاحبُ الأصل والمرجع.

وقد يكون خادماً أساسياً (Master) عنده البيانات الأصلية، وقد يكون خادماً تابعاً (Slave) يملك نسخة من تلك البيانات يحصل عليها بالمزامنة مع الخادم الأساسي.

والخادم الموثوق لا يجيب إلا بما كُتب وضُبط من مصدرٍ صحيح، كمدير النطاق أو المسؤول عنه.

ولكلِّ منطقة «نظام اسماء النطاقات» يجب تعيين مجموعة من الخوادم الموثوقة، وتُسجَّل أسماؤها في النطاق الأعلى عبر سجلات NS. وعندما يجيب الخادم إجابةً نهائية، يضع في ردّه علَماً يسمّى “Authoritative Answer – AA” ليدلّ أنه الجواب الموثوق.

ومن أراد التأكد من كون الخادم موثوقاً أم لا، فله أن يستعمل أدوات الشبكة مثل dig أو drill ، فستبيّن له الأداة إن كان الجواب موثوقاً أم لا.

• Recursive
  • وأما الصنفُ الثاني من خوادم نظام الأسماء فهو الخادمُ الـمُستقصي Recursive، ويُعرف أحياناً بخادمِ الذاكرة المؤقّتة أو “DNS Cache”. ووظيفته أن يتولّى حلَّ الأسماء للتطبيقات، فيحمل سؤالَ المستخدم، ويسير به في سلسلة الخوادم الموثوقة حتى يظفر بالجواب التامّ لاسم الشبكة. ثم يحفظ النتيجة في ذاكرته زمناً محدوداً، ليجيب بها إن تكرّر السؤال.

وأكثرُ مستخدمي الشبكة يعتمدون على خوادم مستقصية عامة، إمّا يوفّرها مزوّد الإنترنت، أو إحدى خدمات «نظام اسماء النطاقات» العامة.

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

والاستعلام المستقصي هو ذاك الذي يتكفّل فيه خادمُ «نظام اسماء النطاقات» بالجواب التام، فيسأل الخوادم الأخرى عند الحاجة حتى يتمّ الجواب.

وقد يكون الخادِم الواحد جامعاً بين الإعتماد والاستقصاء، فيكون موثوقا ومستقصياً سواءً، غير أنّ أهل الخبرة لا يستحسنون جمعَ هاتين الخصلتين في آنٍ واحد. ذلك أنّ الخوادم الموثوقة ينبغي أن تبقى في متناول جميع العملاء على الدوام، تؤدي جوابها سريعاً بلا تعطيل. أمّا الخوادم المستقصية، فاستعلامُها أطولُ مساراً وأبعدُ رحلة، ولذا يُستحبّ أن يُقتصر نفعُها على جماعةٍ محدودة من العملاء؛ إذ إن فتحَها للعامة يعرّضها لسيلٍ من الطلبات قد ينقلب هجوماً مُوزّعاً يحجب الخدمة (DDoS).

وهاكمُ “Unbound”

وهو مُستقصٍ لنظام أسماء النطاقات، يحفظُ المعلومة في ذاكرته، ويُصدِّقها ويصونها، وهو مشروعٌ حرٌّ مفتوحُ المصدر، قد جُمعت فيه خصالٌ شتّى:

• ففيه ذاكرةٌ مُخبِّئة، مع قدرةٍ على استباق الطلب على البنود الشائعة قبل انقضاء أجلها.
• ويدعم ترحيل الاستعلام عبر “DNS over TLS” مع التحقّق من النطاقات.
• وكذلك (DNS over HTTPS-DoH).
• وله خاصية تقليل اسم الاستعلام (Query Name Minimization).
• والاستفادةُ مما ثَبُتَ من ذاكرةٍ مُصدَّقةٍ بمعايير DNSSEC.
• ويتيح مناطقَ الإعتماد لنسخةٍ محليّةٍ من نطاق الجذر.
• DNS64.
• DNSCrypt.
• والتحقّقَ بتوقيعات DNSSEC.
• وامتدادَ عميل EDNS Subnet.

وقد صيغ Unbound ليكون سريعاً وأميناً، ينهل من المعايير المفتوحة وخصائص العصر؛ وقد خضع — في أواخر عام 2019 — لتدقيقٍ صارمٍ محكم.

في إعدادنا مع Unbound، تمرّ استعلامات «نظام اسماء النطاقات» لنطاق مثل “wikipedia.org” بهذه المراحل:

1. يرسل المتصفح طلبًا إلى النظام يسأل فيه: «ما العنوان الشبكي الخاص بـ wikipedia.org؟».
2. يقوم نظام التشغيل — من خلال إجراءات الـ resolver في مكتبة C — بإرسال الطلب إلى خوادم «نظام اسماء النطاقات» الموجودة في الملف /etc/resolv.conf.
3. يستقبل Unbound الطلب، فيفحص أوّلًا ذاكرة التخزين المؤقت لديه، وإن وجد نتيجة سابقة، يعيدها فورًا، وإن لم يجد، يرسل استعلامًا إلى أحد خوادم الجذر المذكورة في ملف Root Hints ليسأل عن نطاق .org.
4. يرد خادم الجذر بإحالة إلى خوادم النطاق العلوي .org.
5. يرسل Unbound استعلامًا إلى أحد خوادم .org ليعرف الخوادم الموثوقة (authoritative) الخاصة بـ wikipedia.org.
6. يرد الخادم بقائمة الخوادم الموثوقة للنطاق.
7. يرسل Unbound استعلامًا إلى أحد هذه الخوادم الموثوقة طالبًا العنوان الشبكي للنطاق wikipedia.org.
8. يجيب الخادم الموثوق بعنوان IPv4 (نوع A) و/أو عنوان IPv6 (نوع AAAA).
9. يعيد Unbound النتيجة إلى العميل (النظام ثم المتصفح).
10. وإذا كانت ميزة التخزين المؤقت مفعلة، يحتفظ Unbound بالنتيجة مدةً زمنية محددة لاستخدامها في الاستعلامات القادمة.

ويمكنك رؤية هذا المسار عمليًا بإجراء تتبّع trace للاستعلام بأداة مثل drill مع خيار التتبّع -T.

$ doas drill -T wikipedia.org
.       518400  IN      NS      l.root-servers.net.
.       518400  IN      NS      k.root-servers.net.
.       518400  IN      NS      e.root-servers.net.
.       518400  IN      NS      a.root-servers.net.
.       518400  IN      NS      m.root-servers.net.
.       518400  IN      NS      h.root-servers.net.
.       518400  IN      NS      i.root-servers.net.
.       518400  IN      NS      f.root-servers.net.
.       518400  IN      NS      c.root-servers.net.
.       518400  IN      NS      b.root-servers.net.
.       518400  IN      NS      g.root-servers.net.
.       518400  IN      NS      d.root-servers.net.
.       518400  IN      NS      j.root-servers.net.
org.    172800  IN      NS      a0.org.afilias-nst.info.
org.    172800  IN      NS      a2.org.afilias-nst.info.
org.    172800  IN      NS      b0.org.afilias-nst.org.
org.    172800  IN      NS      b2.org.afilias-nst.org.
org.    172800  IN      NS      c0.org.afilias-nst.info.
org.    172800  IN      NS      d0.org.afilias-nst.org.
wikipedia.org.  86400   IN      NS      ns0.wikimedia.org.
wikipedia.org.  86400   IN      NS      ns1.wikimedia.org.
wikipedia.org.  86400   IN      NS      ns2.wikimedia.org.
wikipedia.org.  600     IN      A       91.198.174.192

الحجب عبر نظام اسماء النطاقات (DNS)

الحجب عبر «نظام اسماء النطاقات» — ويُعرف كذلك بالتصفية أو تسميم الاستعلامات — هو أن تُزوَّد الجهةُ السائلةُ عن العنوان بإجابةٍ «مزوّرة» مقصودة. فنحن نَحُولُ دون بلوغها العنوانَ الصحيح، إمّا بردٍّ يُصرّح بأنّ النطاق غير موجود (NXDOMAIN)، أو بتحويل الطلب إلى عنوانٍ آخر غير الذي أراده مالكُ النطاق.

وبهذا نستطيع أن نصنع قائمةً — أو قوائم — بالنطاقات المراد حجبها؛ فإذا استفسر المستخدم عن أحدها، لم نُعطه العنوانَ الحقّ، بل نردّ عليه بأنّ «هذا النطاق غير موجود»، فتَنقُطع سُبُلُ التطبيق إلى وجهته المقصودة.

ولِلعِلْمِ، فإنّ طلبات «نظام اسماء النطاقات» تُرسَل — في الأصل — إلى المنفذ 53 عبر بروتوكولَي UDP أو TCP. فإذا أعددنا خادماً للأسماء — كما نفعل مع Unbound — وتأكدنا أن كلَّ حركةٍ متجهةٍ إلى هذا المنفذ إمّا تبلغ خادمَنا وإمّا تُحجَب، ضَمِنّا أن تكون جميعُ الردود الصادرة في شبكتنا آتيةً من خادم Unbound الداخلي القائم على موجّهنا العامل بـ «أوبن بي إس دي».

NXDOMAIN أم إعادة التوجيه

حين نريد حجب نطاقٍ ما بواسطة نظام أسماء النطاقات، فلدينا أكثر من سبيل. ومن أشهرها أن نُعيد توجيه الاستعلام إلى عنوانٍ محلّي، كالعنوان 127.0.0.1 أو 0.0.0.0، أو أن نردّ على الطالب برسالة NXDOMAIN، ومعناها أنّ النطاق المطلوب غير موجود.

وتُعدّ NXDOMAIN استجابةً قياسيةً في نظام أسماء النطاقات، ومعناها أن اسم النطاق المطلوب غير موجود. فإذا عجز خادم «نظام أسماء النطاقات» عن العثور على سجلٍّ للاسم المستعلَم عنه، أعاد هذا الردّ إلى العميل ليُعلمه بأن النطاق غير موجود أصلًا.

ولنجرّب ذلك عمليًّا بالاستعلام عن نطاقٍ غير موجود باستعمال الأمر host:

$ host a1b7c3n9m3b0.com
Host a1b7c3n9m3b0.com not found: 3(NXDOMAIN)

ولأنّ اسم النطاق “a1b7c3n9m3b0.com” غيرُ مسجَّلٍ لدى أحد (على الأقل ساعةَ أكتب هذه السطور)، فإن خادم «نظام أسماء النطاقات» يعيد ردًّا من نوع NXDOMAIN.

ويمكننا كذلك استعمال أداة drill؛ إذ تظهر المعلومة الأهم في الحقل rcode ضمن قسم HEADER، فهو الذي يبيّن نوع الاستجابة وما إذا كان النطاق موجودًا أم غير موجود:

$ drill a1b7c3n9m3b0.com
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 39710
…

وإن كنت تفضّل أداة dig، فستجد المعلومة نفسها في الحقل status ضمن قسم HEADER:

$ dig a1b7c3n9m3b0.com
; <<>> DiG 9.16.8 <<>> +search a1b7c3n9m3b0.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 48858
…

وإجابة NXDOMAIN ليست أوفق من جهة المعايير فحسب، كما بيّنته وثيقة RFC 8020، بل هي كذلك أوضح في التعبير عن المقصود؛ إذ تُخبر العميل صراحةً بأن النطاق المطلوب غير موجود.

أما إرجاع عنوانٍ مثل 127.0.0.1 أو 0.0.0.0 لا تفعلُ أكثرَ من حمل العميلِ السائلِ إلى أن يُحادثَ نفسَه.

وربّما ينبري المتصفّح قائلاً: «لا يستطيع Firefox إنشاء اتصال مع الخادوم عند 0.0.0.0»، غير أنّ هذا العنوان إنما يُترجَم إلى جهازنا المحلي، فنظلُّ — من الوجهة التقنية — قادرين على تنفيذ أمر ping عليه، إذ لا يختلف في معناه عن 127.0.0.1:

$ ping 0.0.0.0
PING 0.0.0.0 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.019 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.049 ms

وعليه، فإنّي أوصيك بأن تجعل جواب NXDOMAIN هو عدّتك الأولى، وهو ما سنجري عليه العمل في هذا الدرس.

مشكلة «نظام اسماء النطاقات» عبر HTTPS (DoH)

ولمّا طلع علينا «نظام اسماء النطاقات» عبر HTTPS (DoH)، تعقّد الأمر، وصار الحجبُ «بنظام اسماء النطاقات» أعسرَ . وإن كنتُ أُقدِّر الدافعَ الأوّل للترويج لـ DoH من جهة الخصوصية، فإنّي أراه — من زاوية الأمن — بناءً سيّئ الأساس، ونهجًا في غير موضعه.

فمع ازدياد عدد خوادم DoH العامة، صار في مقدور أي تطبيق أن يلجأ إليه، فيتجاوز حجب «نظام اسماء النطاقات» المحلي، سواء على مستوى البيوت أو المؤسّسات، تجاوزَ من وجد منفذًا في سور.

وازداد الأمر تعقيدًا حين بدأت بعض التطبيقات والمتصفحات بتضمين إعدادات DoH خاصة بها، أو الاعتماد على مزوّدين محددين لخدمة DoH بصورة مستقلة عن إعدادات نظام التشغيل. ويشتدّ الخطب حين يكون الحديث عن البرمجيات المملوكة (Proprietary Software)، التي لا يُرى مصدرها، ولا تُعدَّل إعداداتها، ولا يُتحكَّم في خيارات DoH فيها.

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

أمّا الاحتفاظ بقائمة بخوادم DoH غير المعروفة — والتي قد تستخدمها برمجيّات مملوكة أو عتاد ذكي (IoT) ببرمجيات خفيّة — فذاك أمرٌ يكاد يكون مستحيلًا.

وزِد على ذلك أنّ DoH كان وبالًا ثقيلًا على كاهل المؤسّسات، إذ أتاح التحايل على إعدادات «نظام اسماء النطاقات» المفروضة مركزيًا. وبذلك صار من العسير، بل من المتعذّر، تصفية وحجب الإعلانات والمحتوى الفاحش -كالذي نبنيه في هذا الدليل-، كما غدا من المستحيل على مديري الأنظمة مراقبة إعدادات «نظام اسماء النطاقات» عبر أنظمة التشغيل المختلفة لمنع هجمات اختطاف «نظام اسماء النطاقات» . ووجودُ عدّة تطبيقات، لكلٍّ منها إعدادات DoH خاصّة به، لكابوسٌ لا يُطاق.

ولم يقف الضرر عند هذا الحدّ؛ إذ عبث DoH بتحليل الشبكة ومراقبة حركة «نظام اسماء النطاقات» لأغراضٍ أمنيّة، فطمس المعالم وغطّى الآثار. وفي عام 2019 ظهر Godlua، وهو برنامج خبيث من فئة بوتات حجب الخدمة (DDoS) على لينكس، كأوّل برمجية خبيثة تُشاهَد وهي تستعمل DoH لإخفاء حركة «نظام اسماء النطاقات» الخاصة بها.

ثم إنّ الأهمّ — وربما الأخطر — أنّ DoH لا يمنع تتبّع المستعملين كما يُروَّج له. فبعض أجزاء اتصال HTTPS ما تزال غير مُعمّاة، مثل حقول SNI (وإن كانت في طريقها إلى التحسين)، واتصالات OCSP، ناهيك عن العناوين الشبكية للوجهة ، وهي — في رأيي المتواضع — جوهر الاتصال وأخطر ما ينبغي ستره وإخفاؤه.

أمّا من كانت الخصوصية عنده ضرورة لا ترفًا — كصحفيٍّ يعيش في بلدٍ تُنتهك فيه الحقوق — فلا ينبغي له أن يطمئن إلى DoH ولا أن يتّكئ عليه. فالعنوان الشبكي للخادم المقصود لا يمكن إخفاؤه بـDoH، مهما أُحكمت تعمية محتوى الحركة نفسها. ومن أراد حقًّا تعمية الاتصال وحمايته، فلا بدّ له من نهجٍ آخر غير هذا النهج.

وهنا يثور العجب في النفس: من ذا الذي رأى في DoH فكرةً سديدة من الأصل؟ أكان غافلًا عن أبجديات الاتصال عبر HTTPS؟ أم لعلّ الدافع كان أجندةً دفعتها شركات «نظام اسماء النطاقات» خاصّة، كـGoogle وCloudflare، ممن ينتفعون بتجميع مزيدٍ من بيانات المستخدمين؟

يزعم بعض مزوّدي «نظام اسماء النطاقات» العموميين أنّ DoH، من زاوية الخصوصية، أرجح من بدائله مثل DNS over TLS (DoT)، إذ تُدفن استعلامات «نظام اسماء النطاقات» داخل السيل الأعظم من حركة HTTPS. وهذا — وإن قلّل من رؤية مديري الشبكات — يمنح المستخدم قدرًا أوفر من الخصوصية.

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

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

إعداد Unbound

الإعدادات الأساسية

إنّ إعداد Unbound من أيسر الأمور؛ إذ جاء محمّلًا بإعدادات افتراضية حسنة، ومسنودًا بتوثيقٍ وافٍ لا يترك لطالب العلم عذرًا. وقبل أن نشرع في العمل، أُشير عليك أن تُطالع كُتيّبات «أوبن بي إس دي» لكلٍّ من: unboundو unbound-checkconf و unbound.conf.

ولمّا كان Unbound يعمل في «أوبن بي إس دي» داخل بيئةٍ معزولة chrooted، فإن ملف الإعداد unbound.conf لا يستقرّ في /etc كما هو الشأن في غيره من الأنظمة، بل مقامه في: /var/unbound/etc/.

فابدأ بنسخ ملف إعداد Unbound الحالي، تمهيدًا للتعديل والبناء عليه.:

$ doas mv /var/unbound/etc/unbound.conf /var/unbound/etc/unbound.conf.backup

ثم استعمل ما تحبه من محررات النصوص وانشئ ملف /var/unbound/etc/unbound.conf جديد، واملأه بالتالي:

server:

    # التسجيل (Logging).
    # جُعلت أسطر التسجيل مُعلّقة،
    # لأنّ تفعيله وإن كان نافعًا في التتبّع والتشخيص، فإنّه يُثقِل الخادم ويُبطِئه.
    # فإن دعت الحاجة، رُفِع الحجاب عن هذه الأسطر، وإلا فتركها أسلم.
    # verbosity: 2
    # log-queries: yes
    # log-replies: yes
    # log-tag-queryreply: yes
    # log-local-actions: yes

    interface: 127.0.0.1
    interface: 192.168.1.1
    interface: 192.168.2.1
    interface: 192.168.3.1

    # وإن أردتَ أن تُغيّر المنفذ، فالسطر المعلّق يبيّن لك السبيل،
    # بأن تُقرَن العنوان برقم المنفذ اقترانًا صريحًا.
    # interface: 127.0.0.1@5353

    # تحكم بمن يريد الوصول.
    access-control: 0.0.0.0/0 refuse
    access-control: ::0/0 refuse
    access-control: 127.0.0.0/8 allow
    access-control: ::1 allow
    access-control: 192.168.1.0/24 allow
    access-control: 192.168.2.0/24 allow
    access-control: 192.168.3.0/24 allow

    # رفض الإستعلام عن "id.server" و "hostname.bind".
    hide-identity: yes

    # رفض الإستعلام عن "version.server" و "version.bind".
    hide-version: yes

    # ميزة حسنة، بها يجدد ما في الذاكرة، فتجاب الطلبات سريعا، ولا ينتظر انقضاء الصلاحية.
    prefetch: yes

    # هذه عناوين داخلية لا يعامها معاملة عناوين الإنترنت العامة.
    private-address: 192.168.0.0/16

    # نتحقق من DNSSEC.
    auto-trust-anchor-file: "/var/unbound/db/root.key"

# نفعل أمر unbound-control.
remote-control:
    control-enable: yes
    control-interface: /var/run/unbound.sock

وقد علّقتُ على الخيارات المتقدّمة آنفًا، فإن احتجتَ إلى مزيد بيان، أو أردتَ الوقوف على سرّ كل توجيهٍ ودقيق معناه، فارجع إلى كُتيّب unbound.conf.

والتسجيل (Logging) في Unbound يكون ـ افتراضًا ـ إلى syslog، حيث تجتمع أخبار النظام وتُدوَّن آثاره. فإن لم يُرضِك ذلك، وأحببتَ أن يكون للخادم سجلٌّ خاص به، مستقلٌّ لا يختلط بغيره، فلك أن تنشئ ملفّ تسجيل داخل بيئة العزل (chroot) الخاصة بـ Unbound، ثم تأمره أن يكتب فيه.:

$ doas mkdir /var/unbound/log
$ doas touch /var/unbound/log/unbound.log
$ doas chown -R root._unbound /var/unbound/log
$ doas chmod -R 774 /var/unbound/log

ثمّ اضف الخيارات التالية في قسم التسجيل (Logging) في ملف unbound.conf:

logfile: "/log/unbound.log"
use-syslog: no
log-time-ascii: yes

ثمّ أعد تشغيل Unbound:

$ doas rcctl restart unbound

وفي الإعدادات آنفًا، قد أذنتُ لـ Unbound أن يُنصت على الواجهة المحلية 127.0.0.1، كي يتيسّر لتطبيقات النظام نفسها أن تسأل وتستفهم إن دعت الحاجة. فليس كل سؤال يُقصد به الجوار، ولا كل طلب يُبعث إلى الخارج. وأمّا في ملفّ /etc/resolv.conf على موجّه «أوبن بي إس دي»، فقد قيّدتُ القلم وكتبتُ اسم خادم Unbound خاصّتنا وحده، إذ لا رغبة لي أن يستجير شيءٌ على هذا الموجّه بخوادم مزوّد الإنترنت. فبهذا، تكون الاستفسارات كلّها مردودةً إلى خادمنا، محفوظةً في نطاقنا، لا تتيه في فضاء المزوّد:

nameserver 127.0.0.1

وإن كنتَ تستعمل «تهيئةُ المُضيف الآلية» للحصول على العنوان الشبكي للكرت الخارجيّ (المتّصل بمودِم المزوّد أو بموجّهه)، فاحذر أن يعبث dhcpleased بملفّ /etc/resolv.conf فيبدّل ما ثبّتناه. فحرّر إذًا ملفّ /etc/dhcpleased.conf، وزِد فيه ما يَحجز هذا الباب ويمنع التغيير، وذلك بإضافة السطر الآتي:

interface em0 { ignore dns }

وبذلك نضمن ألّا يُذكر خادمُنا المحليّ وحده، فلا يندسّ بيننا وبين أسمائنا خادمٌ غريب.

ولتشغيل Unbound وتمكينه:

$ doas rcctl enable unbound

وكلّما بدّلتَ شيئًا من إعدادات Unbound، فلك أحد طريقين، إمّا أن تعيد تشغيله إعادةً كاملة بالأمر:

$ doas rcctl restart unbound

أو تكتفي بأن تعيد تحميل الإعدادات من جديد دون إيقاف الخدمة، مع تنقية الذاكرة المخبّأة في الوقت نفسه، وذلك بالأمر:

$ doas unbound-control reload

وإن أردت أن تطّلع على الإعدادات التي أُطلق بها Unbound عند بدء تشغيله ـ وهذا جارٍ على سائر الخدمات في «أوبن بي إس دي» ـ فلك أن تستعلم عنها بالأمر الآتي:

$ doas rcctl get unbound

وإن أحببتَ أن تستخرج شيئًا من الإحصاءات، فلك أن تُجري الأمر الآتي:

doas unbound-control stats_noreset
thread0.num.queries=2056
thread0.num.queries_ip_ratelimited=0
thread0.num.cachehits=678
thread0.num.cachemiss=1378
thread0.num.prefetch=15
thread0.num.expired=0
…

بوسعك كذلك أن تستخرج تفريغًا كاملًا من الذاكرة المخبأة (الكاش):

$ doas unbound-control dump_cache|less

وإن خطر ببالك أن تعرف أيَّ خَدَمَةِ الأسماء يقصدها Unbound، ولأيِّ نطاقٍ يتوجّه بالسؤال:

$ doas unbound-control lookup wikipedia.org

وإن أدت مسح الذاكرة المخبأة لمجال معين، فعليك بالأمر:

$ doas unbound-control flush example.com

وإن اردت ان تعرف بقية الخيارات فألقِ نظرة على كُتيّب unbound-control.

تجاوز قيم TTL المتدنّية حدّ السخف

واعلم أنّ من أعظم ما أزعج أهل الشبكات في هذا الزمان أن ترى أقوامًا يضعون لقيم TTL أرقامًا هزيلة، لا تكاد تبلغ ستين ثانية! وقد صار هذا، لسببٍ لا يُدرى، كأنه موضة العصر.

ومكمن البلاء في TTL القليل، أنّه يُفرغ التخزين المُخبأ من معناه. فالاستعلام لا يُنتفع بالإجابة المخزّنة إلا ما دامت مدة الـ TTL قائمة، فإذا انقضت، عاد يسأل من جديد، وكأن شيئًا لم يكن. ومع أنّ المعايير (RFCs) توجب احترام قيمة الـ TTL، فإن هذه القيم المتدنية تجعل نظام «نظام اسماء النطاقات» بطيئًا غير كفء، كثير الطلب، قليل النفع. ولهذا أوصي ـ عن تجربة وبصيرة ـ أن تُبطِل هذا العبث، وتفرض حدّك الأدنى بنفسك، فتجعل الـ TTL ساعةً كاملة. وزد على ذلك تحسينًا آخر، وهو أن تُقدِّم الإجابة القديمة للعميل فورًا، ثم تُحدِّثها في الخلفية، بدل أن ينتظر السائل حتى يتم التحديث.

cache-min-ttl: 3600
serve-expired: yes

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

هلمّ بنا نصدّ النطاقات!

والآن نبلغ لبّ الحديث، وموضع المتعة، وميدان الحجب والمنع.

أنشأتُ نصًّا بسيطًا من نصوص القُمرة (Shell Script) سمّيتُه DNSBlockBuster، غايته أن يجوب الشبكة، فيجلب جملةً من ملفات المُضيفين hosts من مصادر شتّى، ثم يضمّ بعضها إلى بعض، ويُنقّيها من الشوائب، ويحوّل حاصلها إلى قائمة نطاقات محجوبة تصلح لكلٍّ من Unbound و dnsmasq. ومعظم ما يحجبه هذا النص: إعلانات، ومواقع فُحش، ومتعقِّباتٍ لا تعرف الحياء (tracking).

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

ولستَ ـ بالطبع ـ مُلزَمًا باستعمال نصّي هذا، لكنني سأعتمده في هذا الدليل.

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

ولكي لا يضيق صدر Unbound ولا يَنفد صبره أثناء تحميل هذه القائمة العظيمة، ينبغي لك أن تُعدّل الملف: /etc/rc.conf.local وتُضيف إليه السطر الآتي:

unbound_timeout=240

ثم أعد تشغيل Unbound:

$ doas rcctl restart unbound

ألقِ نظرةً على قسم Usage في توثيق DNSBlockBuster لتعلم كيف يُستعمل.

فإذا فرغتَ من إنشاء قائمة الحظر الخاصة بـ Unbound، فضعها في المسار: /var/unbound/etc/، ثم افتح ملف إعدادات Unbound، وهو: /var/unbound/etc/unbound.conf وأدرج السطور المطلوبة في قسم server من ملف الإعداد، على أن يكون ذلك قبل قسم remote-control ، إذ ذاك موضعها:

include: "/var/unbound/etc/unbound-blocked-hosts.conf"

# Enable the usage of the unbound-control command.
remote-control:
    control-enable: yes
    control-interface: /var/run/unbound.sock

والآن أعد تشغيل Unbound:

$ doas unbound-control reload

وإذا أجريت أمر top في ترمينال اخرى ، رأيتَ Unbound قد شغل شيئا غير يسير من المعالج، ويستأثر بنصيبٍ غير يسيرٍ من الذاكرة، وذلك في ساعة التحميل الأولى لقائمة الحظر.

والآن اختبر حجب «نظام اسماء النطاقات» بطلب أحد النطاقات المحجوبة في قائمتك:

$ drill 3lift.com
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 55906
…

ثم أَعِدِ الكَرّة، ولكن هذه المرّة مع خادم كلاودفلير «لنظام اسماء النطاقات»:

$ drill 3lift.com @1.1.1.1
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 48771
…

وكما يتبيّن لنا من مخرجات الاستعلامين، فإن خادم «نظام اسماء النطاقات» الخاص بنا قد سدّ الطريق إلى النطاق 3lift.com، فردّ عليه بجواب NXDOMAIN كأنه يقول: لا وجود له ولا سبيل إليه. أمّا خادم Cloudflare، فقد أجاب بالعنوان الشبكي الصحيح، لأنه لا علم له بحجبنا.

أمن نظام اسماء النطاقات

أمن نظام أسماء النطاقات باب واسع، وفي هذا الفصل لا نخوضه كلَّه، بل نقتصر على ما يهمّنا نحن، إذ عزمنا على تشغيل خادم «نظام اسماء النطاقات» بأيدينا وتحت نظرنا.

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

اختطاف نظام اسماء النطاقات

واختطاف «نظام اسماء النطاقات» معناه أن استعلاماتك لا تذهب إلى حيث تظن، بل تُحوَّل قسرًا إلى خادم آخر. وغالبًا ما يتم ذلك بتحويل كلّ الحركة المتجهة إلى المنفذ 53 من مقصدها الأصلي إلى مقصد بديل.

ومن أبسط الطرق لاكتشاف ما إذا كان مزوّد الخدمة يعبث باستعلاماتك، أن تُجري السؤال مباشرة على خادم «نظام اسماء النطاقات» موثوق وصاحب سلطة.

لدينا عدّة أدوات لهذا الغرض. في هذا المثال نستخدم أداة drill، وخياراتها هنا مماثلة لما في dig. وسنعود، كما ألفنا، إلى النطاق wikipedia.org.

أولًا، لا بد أن نعرف الخوادم الموثوقة (Authoritative). وستجدها مذكورة في قسم الإجابة “ANSWER SECTION”:

$ drill NS wikipedia.org
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 28789
;; flags: qr rd ra ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; wikipedia.org.       IN      NS

;; ANSWER SECTION:
wikipedia.org.  85948   IN      NS      ns2.wikimedia.org.
wikipedia.org.  85948   IN      NS      ns0.wikimedia.org.
wikipedia.org.  85948   IN      NS      ns1.wikimedia.org.

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 1 msec
;; SERVER: 127.0.0.1
;; WHEN: Thu Nov  5 07:53:19 2020
;; MSG SIZE  rcvd: 95

ثم بعد ذلك، لا بدّ لنا أن نُوجّه السؤال مباشرةً إلى أحد أولئك الخوادم الموثوقة أنفسهم. والموضع الذي ينبغي أن تُحدّق فيه النظر، هو حقل الرايات (flags) في قسم HEADER من الجواب. فإن كان الردُّ صادرًا عن خادمٍ ذي ثقة، وجب أن ترى الراية aa.

$ drill @ns1.wikimedia.org wikipedia.org
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 57611
;; flags: qr aa rd ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; wikipedia.org.       IN      A

;; ANSWER SECTION:
wikipedia.org.  600     IN      A       91.198.174.192

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 127 msec
;; SERVER: 208.80.153.231
;; WHEN: Thu Nov  5 07:56:10 2020
;; MSG SIZE  rcvd: 47

وهكذا يتبيّن لنا،أنّ الجواب الذي ورد إلينا لم تُمدّ إليه يدُ الاختطاف، إذ جاءنا مشفوعًا براية aa. فلنحرب الحيلة ذاتها مع خادم Cloudflare العمومي:

$ drill @1.1.1.1 wikipedia.org
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 40562
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; wikipedia.org.       IN      A

;; ANSWER SECTION:
wikipedia.org.  555     IN      A       91.198.174.192

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 3 msec
;; SERVER: 1.1.1.1
;; WHEN: Thu Nov  5 08:02:58 2020
;; MSG SIZE  rcvd: 47

وانظر كيف غابت راية aa عن حقل HEADER، فدلّ غيابُها على أنّ الجواب لم يكن جوابا موثوقا، بل ردًّا من ناقلٍ أو وسيط، لا من مصدرٍ مُفوَّض.

وهناك أداةٌ أيسرُ مَأخذًا، وهي nslookup. فنبدأ أوّلًا بالسؤال عن الخوادم الموثوقة:

$ nslookup -querytype=NS wikipedia.org
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
wikipedia.org   nameserver = ns1.wikimedia.org.
wikipedia.org   nameserver = ns2.wikimedia.org.
wikipedia.org   nameserver = ns0.wikimedia.org.

ثم هلم بنا نجعل السؤال عن النطاق المقصود موجهاً الى خادمنا:

$ nslookup wikipedia.org
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
Name:   wikipedia.org
Address: 91.198.174.192

Server:         ns2.wikimedia.org
Address:        91.198.174.239#53

Name:   wikipedia.org
Address: 91.198.174.192

وظهور عبارة Non-authoritative يبيّن بوضوح أن الردّ لم يصدر من خادمٍ موثوق. لا إشكال في ذلك، فدور هذا الخادم هو أن يستعلم بالنيابة عنّا ويعيد الجواب كما وصله. نوجّه الاستعلام مباشرةً إلى أحد الخوادم المُخوَّلة، ونراقب ترويسة الردّ:

$ nslookup wikipedia.org ns0.wikimedia.org
Server:         ns0.wikimedia.org
Address:        208.80.154.238#53

Name:   wikipedia.org
Address: 91.198.174.192

اختفت رسالة Non-authoritative ، والرد الذي حصلنا عليه كان من مصدر موثوق، مما يعني أن استعلام «نظام اسماء النطاقات» الخاص بنا لم يُخططف.

الآن قمت بتفعيل خدمة VPN التي أعرف أنها تعترض استعلامات «نظام اسماء النطاقات» لحماية العملاء من تسريب «نظام اسماء النطاقات»، وسأقوم الآن بالاستعلام من أحد الخوادم الموثوقة مرة أخرى:

$ nslookup wikipedia.org ns0.wikimedia.org
Server:         ns0.wikimedia.org
Address:        208.80.154.238#53

Non-authoritative answer:
Name:   wikipedia.org
Address: 91.198.174.192
Name:   wikipedia.org
Address: 2620:0:862:ed1a::1

كما كان متوقعًا، لم يكن الرد صادراً من الخادم الموثوق، رغم أنني استعلمت مباشرة من الخادم الموثوق. اختطفت حركة «نظام اسماء النطاقات» واعيد توجيه الرد إلى خادم «نظام اسماء النطاقات» غير معروف.

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

الوقاية من اختطاف نظام اسماء النطاقات

إذا تبيّن لك أن حركة «نظام اسماء النطاقات» على المنفذ 53 قد امتدت إليها يد العبث، وتسلّل إليها الاختطاف، فاعلم أن أمامك ثلاثة مسالك، لكلٍّ منها وجهة ومآل:

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

انتحال نظام اسماء النطاقات (DNS spoofing)

أما انتحال «نظام اسماء النطاقات»، ويُعرف كذلك بتسميم الذاكرة المُخبأة، فشأنه غير شأن الاختطاف. ففي الاختطاف تُحوَّل الطريق، وفي الانتحال يُزوَّر الزاد. وغالبًا ما يجتمع الأمران، فيكون الخطر أعظم، والضرر أعم.

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

الوقاية من انتحال نظام اسماء النطاقات

ويمكن دفع هذا البلاء، أو التخفيف من حدّته، على طبقة النقل أو طبقة التطبيق، وذلك بالتحقق التام بين الطرفين بعد قيام الاتصال. ومن أشهر الأمثلة على ذلك استخدام معيار أمان طبقة النقل (TLS) والتواقيع الرقمية.

ويأتي «نظام اسماء النطاقات الآمن» (DNSSEC) درعًا في هذا الميدان، إذ يعتمد على تواقيع رقمية مُمّاه، موثَّقة بمفاتيح عامة موثوقة، للتحقق من صحة البيانات وصيانتها من التزوير. غير أن كثيرًا من مديري أنظمة «اسماء النطاقات» لم يُحسنوا الأخذ به بعد.

وحتى عام 2020، كانت جميع نطاقات المستوى الأعلى الأصلية (TLDs) تدعم DNSSEC، وكذلك نطاقات الدول الكبرى، بينما لا تزال بعض نطاقات الدول الأخرى متأخرة عن هذا الركب.

المُلحق

فحص نظام اسماء النطاقات عبر HTTPS (DoH)

أرغب هنا أن أبيّن أن DoH لا يمنح خصوصية حقيقية كما يُشاع، إذ إن العنوان الشبكي للمصدر والعنوان الشبكي للوجهة يبدوان جليَّين في حركة HTTPS، لا يستتران ولا يختفيان.

بادئ ذي بدء، عطّلتُ DoH في متصفح فايرفوكس على أحد أجهزة شبكة البالغين، ثم أخذت أراقب حركة المرور على بطاقة الشبكة em1 بأداة tcpdump. وفي الوقت نفسه فعّلتُ ملف السجل في Unbound، اتقاءً لضجيج «نظام اسماء النطاقات» أن يملأ syslog، وجعلتُ tail فيقي في متابعة ما يُكتب في السجل لحظة بلحظة.

بعد ذلك قصدتُ موقع wikipedia.org عبر المتصفح، ثم التفتُّ لأنظر: ماذا تكشف عيون المراقبة على الموجّه؟

$ doas tcpdump -n -i em1 src host 192.168.1.5 and not arp
tcpdump: listening on em1, link-type EN10MB
23:30:33.494352 192.168.1.5.55724 > 192.168.1.1.53: 58136+ A? wikipedia.org.(31) (DF)
23:30:33.774439 192.168.1.5.58372 > 192.168.1.1.53: 58448+ A? www.wikipedia.org.(35) (DF)
23:30:34.184287 192.168.1.5.46639 > 192.168.1.1.53: 15167+ A? www.wikipedia.org.(35) (DF)
…

$ doas tail -f /var/unbound/log/unbound.log
Nov 05 23:30:33 unbound[12636:0] query: 192.168.1.5 wikipedia.org. A IN
Nov 05 23:30:33 unbound[12636:0] reply: 192.168.1.5 wikipedia.org. A IN NOERROR 0.097209 0 47
Nov 05 23:30:33 unbound[12636:0] query: 192.168.1.5 www.wikipedia.org. A IN
Nov 05 23:30:33 unbound[12636:0] reply: 192.168.1.5 www.wikipedia.org. A IN NOERROR 0.154989 0 80
Nov 05 23:30:34 unbound[12636:0] query: 192.168.1.5 www.wikipedia.org. A IN
Nov 05 23:30:34 unbound[12636:0] reply: 192.168.1.5 www.wikipedia.org. A IN NOERROR 0.000000 1 80
…

وبداهةً نرى الاستعلام ظاهرًا بوضوح، سواء في حركة المرور على الكرت أو في سجل Unbound.

ثم إني عزمتُ، على تمكين DoH وتعطيل ما سواه من «نظام اسماء النطاقات» العتيق في فايرفوكس، فغيّرت قيمة network.trr.mode إلى 4، وعدّلت Network settings وجعلت Cloudflare موفر DoH.

حيلة: إن اكتفيتَ بتفعيل DoH من نافذة التفضيلات، أبقى فايرفوكس على «نظام اسماء النطاقات» التقليدي ردءًا وملاذًا عند الحاجة. أمّا إن شئتَ الحسم والعزم، وأردتَ DoH وحده بلا شريك، فاضبط network.trr.mode بيدك.

اكتب about:config في شريط العنوان واضرب Enter ، تنفتح لك خزائن الإعدادات المستورة.

الخطوة الثانية: فتّش عن network.trr.mode، فهو زمام الأمر ومقاليد DoH، وله من القيم ما يلي:

1 - DoH معطّل.
2 - DoH مفعّل، ويتداول فايرفوكس بينه وبين «نظام اسماء النطاقات» التقليدي أيّهما أسرع جوابًا.
3 - DoH مفعّل، و«نظام اسماء النطاقات» التقليدي ظهيرٌ عند العثرة.
4 - DoH مفعّل، و«نظام اسماء النطاقات» التقليدي معطل.
5 - DoH معطّل.

الخطوة الثالثة: ثم اطلب network.trr.bootstrapAddressفهو المتحكم بالعنوان الشبكي الرقمي لخادم DoH، وأدخل فيه 1.1.1.1 ثم اضرب Enter.

هذه المرة سأزور “freebsd.org”.

$ doas tcpdump -n -i em1 src 192.168.1.5 and not arp
tcpdump: listening on em1, link-type EN10MB
00:21:10.944243 192.168.1.5.32856 > 1.1.1.1.443: P 2223446146:2223446202(56) ack 157857007 win 501 (DF)
00:21:10.948719 192.168.1.5.46584 > 96.47.72.84.80: S 922508523:922508523(0) win 64240 <mss 1460,sackOK,timestamp 1673624773 0,nop,wscale 7> (DF)
00:21:11.133801 192.168.1.5.33298 > 96.47.72.84.443: S 3275123911:3275123911(0) win 64240 <mss 1460,sackOK,timestamp 1673624958 0,nop,wscale 7> (DF)
…

$ doas tail -f /var/unbound/log/unbound.log
Nov 05 23:30:33 unbound[12636:0] query: 192.168.1.5 wikipedia.org. A IN
Nov 05 23:30:33 unbound[12636:0] reply: 192.168.1.5 wikipedia.org. A IN NOERROR 0.097209 0 47
Nov 05 23:30:33 unbound[12636:0] query: 192.168.1.5 www.wikipedia.org. A IN
Nov 05 23:30:33 unbound[12636:0] reply: 192.168.1.5 www.wikipedia.org. A IN NOERROR 0.154989 0 80
Nov 05 23:30:34 unbound[12636:0] query: 192.168.1.5 www.wikipedia.org. A IN
Nov 05 23:30:34 unbound[12636:0] reply: 192.168.1.5 www.wikipedia.org. A IN NOERROR 0.000000 1 80
…

ويكشف هذا الرصد، أنّ اتصالًا قد انعقد بخادم «نظام اسماء النطاقات» التابع لـ Cloudflare على العنوان 1.1.1.1 عبر المنفذ 443 (HTTPS)، وأنّنا ما لبثنا بعده أن قصدنا عنوان الوجهة 96.47.72.84. وفي الوقت عينه لم يتحرّك سجلّ Unbound. والأمر tail باقٍ كما كان.

وإن نحن أجرينا استعلام «نظام اسماء النطاقات» تقليديًا على الموجّه، تبيّن لنا أنّ العنوان 96.47.72.84 هو حقًّا عنوان موقع freebsd.org.

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

وفي ذلك دلالة بيّنة على أنّ DoH، وإن التفّ على استعلامات «نظام اسماء النطاقات» المعتادة وتجاوزها، لا يملك ستر عنوان الوجهة الشبكي، إذ يظل ظاهرًا مكشوفًا في نسيج حركة الاتصال.

حجب “نظام اسماء النطاقات عبر HTTPS” (DoH)

وكانت أداة DNSBlockBuster، فيما مضى، قد ضمّت بعض نطاقات DoH إلى قوائم الحجب، أدرجتها فيها على عجل ومن غير ترتيب، غير أنّي عدلت عن ذلك، ونزعت حجب DoH من خادم «نظام اسماء النطاقات» نفسه، إذ تبيّن لي أنّ موضع هذا المنع إنما هو جدار الحماية لا غيره.

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

فإن كنتَ لا تستخدم IPv6، فالحيلة أيسر وأوضح: امنع كلّ حركة IPv6 الصادرة، واقتصر على قائمة IPv4 وحدها. عدّل معامل pass out في قسم Default protect and block من الملف /etc/pf.conf، إلى pass out inet. وبذلك لا يُسمح إلا بخروج حركة IPv4، ولا تعود مضطرًا إلى ملاحقة عناوين DoH الخاصة بـ IPv6 واحدًا واحدًا.

نزّل قائمة العناوين من مستودع awesome-lists، وهذّبها بما يلائم حاجتك، وضعها حيث تشاء على القرص.

وقد أنشأتُ لذلك دليلاً فرعيًا باسم /etc/pf-block-lists/ أجمع فيه كل قوائم الحجب التي أحتاجها لمُصفي الرُزم.

ثم، بعد ذلك، أنشئ ملفًا دائمًا لمُصفي الرزم في قسم Tables من الملف /etc/pf.conf:

# Public DoH servers.
table <block_doh> persist file "/etc/pf-block-lists/doh-ipv4.txt"

وإن احتجت العناوين الشبكية من الاصدار السادس، فأضف مايلي:

table <block_doh> persist file "/etc/pf-block-lists/doh-ipv4.txt" file "/etc/pf-block-lists/doh-ipv6.txt"

ثم أضف block لقسم “Protect and block by default” من جدار الحماية:

# Let's block DoH.
block in quick on { $g_lan $c_lan $dmz } to <block_doh>

أعد التحميل بالأمر:

$ doas pfctl -f /etc/pf.conf

تأكد من القائمة بالأمر:

$ doas pfctl -vvt block_doh -T show

وإن أردتَ — بعد حينٍ من الدهر — أن تطّلع على العناوين الشبكية التي استُعملت في الحجب وجرى العمل بها، فلك أن تُصفّي المخرجات وتُنقّيها بالترشيح، فتظهر لك العناوين التي وقع عليها المنع، دون سواها:

$ doas pfctl -vvt block_doh -T show | awk '/\[/ {p+=$4; b+=$6} END {print p, b}'

إضافة خيار domain-name إلى «معيار تهيئةُ المُضيف الآلية» واستعمال الاسم المؤهَّل الكامل FQDN

إذا أقمنا شبكتنا على أن تكون لجميع الحواسيب والأجهزة عناوين شبكية ثابتة وأسماء مضيفين معروفة، فإن كثيرًا من الأدوات لن تُحسن التعامل مع هذه الأسماء كما هي، ما لم نُلحِق بها اسم نطاق في خادم «نظام اسماء النطاقات». وذلك لأن أدوات الشبكة — كالأداة host مثلًا — تتوقّع أن يكون الاسم المطلوب اسمًا مؤهَّلًا كاملًا (FQDN).

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

أما إذا استعملنا اسمًا مؤهَّلًا كاملًا، استقام الأمر هكذا:

$ host foo.example.com
foo.example.com has address 192.168.1.7

وبإمكاننا كتابة العنوان:

$ doas host 192.168.1.7
7.1.168.192.in-addr.arpa domain name pointer foo.example.com

غير أنّ تكرار كتابة اسم النطاق كاملًا في كل مرة أمرٌ مُملّ لا يُحتمل. فإذا أضفنا خيار domain-name إلى الملف /etc/resolv.conf، أُلحق اسم النطاق تلقائيًا بكل اسم نكتبه. وعندئذٍ يكفينا أن نفعل هذا فحسب:

$ host foo
foo.example.com has address 192.168.1.7

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

فلنبدأ بإجراء بعض التعديلات على ملف الإعداد /etc/dhcpd.conf. وللتسهيل، سأكتفي هنا بخادم الشابِكة من مثال الشبكة العامة (Public LAN)، غير أنّ لك أن تُوسّع هذا الإعداد على أي مقطع شبكي تشاء، بل ويمكنك استعماله عبر عدّة مقاطع متى دعت الحاجة.

في إعدادنا الحالي، كان اسم النطاق example.comملحقًا بخادم الشابكة سلفًا، فجاز لنا أن نُبقيه كما هو. أمّا إن لم يكن لديك خادمٌ عامّ يحتاج إلى اسم نطاقٍ حقيقي، فغيّر الاسم إلى home.arpa بلا حرج. وقد بدّلتُ اسم خادم الشابكة عندي إلى lilo — نعم، من Lilo & Stitch — فهو، في نظري، أظرف وأحبّ إلى النفس من Luke أو Yoda، ولكلٍّ ذوقه وميلُه.

subnet 192.168.1.0 netmask 255.255.255.0 {
    option domain-name-servers 192.168.1.1;
    option domain-name "example.com";
    option routers 192.168.1.1;
    range 192.168.1.10 192.168.1.254;
}
subnet 192.168.2.0 netmask 255.255.255.0 {
    option domain-name-servers 192.168.2.1;
    option domain-name "example.com";
    option routers 192.168.2.1;
    range 192.168.2.10 192.168.2.254;
}
subnet 192.168.3.0 netmask 255.255.255.0 {
    option domain-name-servers 192.168.3.1;
    option domain-name "example.com";
    option routers 192.168.3.1;
    range 192.168.3.10 192.168.3.254;
    host lilo.example.com {
        fixed-address 191.168.3.2;
        hardware ethernet 61:20:42:39:61:AF;
        option host-name "lilo";
    }
}

وإن آثرتَ أن تستعمل أكثر من نطاقٍ واحد، كأن تجعل example.com لأعمالك في تطوير مواقع الشابكة، وتخصّ home.arpa بشبكتك الخاصة، وذلك باستعمال البحث عن النطاق بخيار domain-search في ملف /etc/dhcpd.conf بدل خيار domain-name. والفرق بينهما بيّنٌ لمن تدبّر: فخيار domain-name لا يُلحق إلا نطاقًا واحدًا بالاسم المجرّد، أمّا domain-search فيفتح لك باب التعدّد، إذ يسمح بإضافة عدّة نطاقات، فتُفحَص واحدًا بعد واحد،، حتى يُعثَر على المضيف المنشود.

ويأتي خيار domain-search على هذه الهيئة:

option domain-search "example.com", "home.arpa"

ثم لا بدّ بعد ذلك من تهيئة Unbound ليتعامل مع العناوين الشبكية الثابتة في شبكتنا. وفي هذا المثال ليس عندنا سوى خادم الشابكة، غير أنّ الباب مفتوح لإضافة ما شئت من المضيفين. يمكنك التعديل مباشرة في ملف إعدادات Unbound الرئيسي، غير أنّ الأحوط والأرتب — في رأيي — أن تفرد لهذا الغرض ملفًا مستقلًا، ثم تُدرجه ضمن الملف الأصلي. فأنشئ ملفًا جديدًا مثلًا باسم: /var/unbound/etc/unbound-local.conf واضبط فيه تعريفات المضيفين على هذا النحو:

local-data: "lilo.example.com IN A 192.168.3.2"
local-data-ptr: "192.168.3.2 lilo.example.com"

أو إن آثرت استعمال نطاق home.arpa، فاجعلها هكذا:

local-data: "lilo.home.arpa IN A 192.168.3.2"
local-data-ptr: "192.168.3.2 lilo.home.arpa"

ثم أضف إلى ملف Unbound الرئيسي /var/unbound/etc/unbound.conf:

private-address: 192.168.0.0/16
private-domain: example.com # Use home.arpa instead if you need that.
include: "/var/unbound/etc/unbound-local.conf"

أعد تشغيل «معيار تهيئةُ المُضيف الآلية» وUnbound::

$ doas rcctl restart dhcpd
$ doas rcctl restart unbound

وإن أنت نزعت سلك الشبكة من أحد الحواسيب المتصلة بإحدى الشبكات الـمحلية ثم أعدت وصله، رأيت أن ملف /etc/resolv.conf قد زِيد فيه خيار domain:

domain example.com
nameserver 192.168.1.1

وهكذا يتّسع لك المثال، فتُكثِر النطاقات إن شئت، وتعدّد المضيفين عبر جميع الأقسام.

إضافة pf-badhost

إذا فرغتَ من إعداد موجّهك على «أوبن بي إس دي»، فإني أنصحك أن تُلحق به pf-badhost.

فـ pf-badhost نص أمني خفيف، صاغه جوردان جيوغان، غايته كفّ أذى كثير من منغّصات الشبكة ومشاغبيها. وبفضله تُقصم ظهور هجمات التخمين على SSH وSMTP، ويخفّ ضجيجها حتى يكاد يتلاشى.

يقوم هذا النص، على فتراتٍ معلومة، بجمع العناوين الشبكية من قواعد بيانات مشهورة برصد المزعجين ومصادر الشرّ، مثل Spamhaus وFirehol وEmerging Threats وBinary Defense، حيث تُسجَّل العناوين السيئة أولًا بأول. ثم يُدرِج تلك العناوين في جدار الحماية مصفي الرزم ضمن جدولٍ يُحجَب افتراضيًا، فيُغلق الباب قبل أن يُطرق.

unbound-adblock

وأمّا unbound-adblock، فهو سكربت آخر من صنع جوردان جيوغان، يُمكّنك من حجب شبكات الإعلانات على مستوى نظام اسماء النطاقات. فإن شئت، جعلته بديلًا عن DNSBlockBuster، ولك في ذلك سعة واختيار.

قراءات مُستحسنة

• دليل المستعمل لـمصفي الرزم من أسئلة «أوبن بي إس دي» الشائعة.
• Absolute OpenBSD، الطبعة الثانية، لمايكل وارن لوكاس (مع أنّ بعض صياغات مصفي الرزم تغيّرت منذ تأليفه، إلا أنّ نفعه باقٍ)
• Networking for System Administratorsلمايكل وارن لوكاس.
• OpenBSD and You
• Stop using ridiculously low DNS TTLs

وصلات ذات صلة

• قائمة موسّعة بمحلّلات «نظام اسماء النطاقات» العامة الداعمة لـ DNSCrypt وDNS-over-HTTP2
• قائمة cURL بخوادم DoH المتاحة للعامة
• قائمة أخرى بخوادم DoH

هذه المقالة ترجمةٌ للدليل الأصلي «OpenBSD Router Guide»، وهو منشورٌ برخصة المشاع الإبداعي CC BY-NC-SA 4.0.

إن أفادتك هذه الترجمة، فادعُ لصاحبها بخير، أو ساند جهده عبر: Motaz@coinos.io :)

أساس نوستر

الحَدَث ( event )

إن كُل شاردةِ بيانات تجري في شبكة نوستر — سواء كانت ملاحظة (منشور)، أو ملف المؤلف، أو قائمة متابعة — إنما هي “حَدَث” (event)، حوى ستة حقول دلالية. وهي:

• pubkey: هو المفتاح العام لصاحب الحَدَث، ويأتي في اثنين وثلاثين بايتاً بنظام الستة عشر (Hex). وبه تُعرف هوية المؤلف الرقمية.

• created_at: وهو مِيقات الزمان بنظامِ “يونكس” (محسوب بالثواني). ولَـمَّا كان المِعْيار لا يَقْهرُ النَّاسَ على تَدْقيقِه، عُوِّلَ فيه على صِدْقِ المؤلف وتحقيقِه.

• kind: وهو رَقَمٌ صَحيحٌ من الصِّفْرِ إلى الحدِّ الـمَعلوم (0–65535) -أي ما يمكن تمثيله ببايتين من الارقام-، يُميَّزُ به مَغْزى الحدث وكيف يُعمل به. فالنوع (0) يدل على البيانات الوصفية للمؤلف (metadata). أما النوع (1) فللمنشور العابر، والنوع (3) يمثل قائمة المتابعين. وما زادَ عن ذلك فَمَتْروكٌ لِأهلِ التَّوْسِعةِ والإبتكار.

• tags: وهي مصفوفةٌ تَنْطوي على مصفوفاتٍ من النصوص، تُستعمل للإشارات (Mentions)، والردود، والموضوعات، والبيانات الهيكلية الأخرى. فما كُتب فيه الحرف e فإحالةٌ على حَدَثٍ مَضى، مثل:

["e", "<event-id>"]

وما كُتِبَ فيه الحرف p فيشير إلى مستعمل معين. مثل:

["p", "<pubkey>"]

• content: مضمون الحدث. فإن كان الحدث من النوع (1) فالمضمون هو نص الملاحظة؛ وإن كان نوعه (0) فهو كائن JSON يحتوي على الاسم، وترجمة المؤلف، ورابط صورته، وما شابه.

• sig: توقيعٌ رقمي بطريقة “شنور” (Schnorr) يَقَعُ في أربعةٍ وسِتِّينَ بايت، ويُجرى على مجمل القيمة المُبلّدَة (Hash) للحدث.

حساب مُعرف الحدث (event ID)

هذا رَقَمٌ لا تَمُنُّ بِهِ الخَوادِمُ والـمَراكز، بل هو نَبْتُ النَّصِّ وفَيْضُ الحدث ، يُشْتَقُّ مِنْ صَميمِ الحَدَثِ وجَوهره، ويمنعُ أيدي العبثِ أَن تتطرَّقَ إِلى مظهره مما يجعله معنوناً بالمحتوى (Content-addressable).

• المرحلة الأولى — الصياغة المعتمدة (Canonical serialization): تُنشأ مصفوفةُ JSON مَحْبوكَةٌ على هذا المثال:

[0, pubkey, created_at, kind, tags, content]

وقُدِّمَ الصفر (0) في أول المصفوفة ليُميزَ هذا النَسَق عن أي نسق آخر. والأحكام في هذا الباب شديدةٌ صارمة: استعمال ترميز UTF-8 المضغوط، وإزالة الفراغات الزائدة، والالتزام برموز التهريب الستة المعروفة لضبط الحروف (\f ،\b ،\t ،\r ،\n ،\" ،\\).

• المرحلة الثانية — التبليد (Hash): تُؤخذ أقسام تلك المصفوفة المُنقحة، فتُبلّد بSHA-256، فيكون ذلك الرقم الست عشري هو المُعرّف (id).

• المرحلة الثالثة — التوقيع (Sign it): يُحسب توقيع “شنور” على ذلك المعرف بالمفتاح الخاص للمؤلف (secp256k1 private key)، لينتج عن ذلك حقل التوقيع (sig). ولما كانت قيمة المعرف هي عين ما وقع عليه التوقيع (id == sig_input)، فإن التحقق من صحة التوقيع يُثبت سلامة المعرف من التلاعب.

مزايا هذا التصميم

• الاستغناء عن الخوادم الموثوقة: إذ بمقدور كل ذي لُب أن ينظر في المفتاح والتوقيع فيتأكد من صحة الحدث.

• العنونة بالمحتوى: يتغير المعرف إذا تغير أي حقل في الحدث، فيظهر أي تزوير.

• إحكام قواعد الصياغة: لو أن عميلين (Clients) صاغا الحدث ذاته بسلسلتين مختلفتين من البايتات، لأنتجا معرفين مختلفان؛ فجاءت قواعد التهريب لتسد الثغرة وتضمن تطابق المعرفات.

تفصيل القول في الوسوم (Tags in depth)

الوسوم هي الحِبال التي تصل الأحداث بالأشياء الأخرى — سواء كانت أحداثاً أخرى، أو مستعملين، أو محتويات معنونة. وما الوسم إلا مصفوفة من النصوص، تعلو مزيتها من ترتيب مواقعها:

• الموقع 0: هو اسم الوسم، أي مفتاحه (Key). وللأسماء المؤلفة من حرف واحد مثل (e, p, a) مكانة خاصة؛ إذ تُجبَر الـمُرَحِّلات (Relays) على فهرستها لتصير يسيرة الإستعلام. أما ما زاد عن حرف مثل (alt) فلا تُفَهرس.

• الموقع 1: هو قيمة الوسم وجوهره، وعليه وحده تقع الفهرسة في المرحلات.

• الموقع 2 وما زاد عليه: سياق زائد لم يُوضع له اسم، يُستعان به. عادةً لذكر وَصلة مرحل أو تلميحات للمفتاح العام للمؤلف.

الوسوم الثلاثة المعتمدة

الوسمe — للإحالة على حدث معلوم:

["e", <event-id hex>, <relay URL, optional>, <author pubkey, optional>]

يُستعمل هذا في الردود، وإعادة النشر، والتفاعلات، ولكل ما يشير إلى حدث معين عبر مُعرّفه (id). ورابط المُرَحِّل إختياري يُرشد إلى مكان ذلك الحدث، كما أن المفتاح العام تلميحٌ يغني عن البحث عن مفتاح المؤلف.

الوسمp — الإحالة إلى مستعمل:

["p", <pubkey hex>, <relay URL, optional>]

يُستخدم للإشارة إلى مستعمل أو تنبيهه. وتُشير وَصلةُ المُرَحِّل إلى حيث ينشر هذا المستعمل بياناته، وتستعين برامج العملاء بهذا الحقل لإظهار الإشارات (@mentions) وإرسال الإشعارات.

الوسمa — الإحالة إلى حدث معنون أو مُستبدل:

["a", "<kind>:<pubkey>:<d-tag value>", <relay URL, optional>]   // حدث معنون
["a", "<kind>:<pubkey>:",             <relay URL, optional>]   // حدث مُستبدل (النقطتان الإلزاميتان في النهاية)

بخلاف الوسم e الذي يشير إلى حدث واحد لا تتغير قيمته المرمزة، يشير الوسم a إلى حدث منطقي، وهو يُحددُ بـ (النوع + المفتاح العام + قيمة الوسم d). فتقوم الـمُرَحِّلات بتقديم آخر حدث يطابق هذه التجميعة. والنقطتان في المُستَبدَل أمرٌ لازم، إذ بهما يُمَيَّز الحدث المُستَبدَل -بغياب الوسم d- وبين الحدث المُعَنون.

عُرْف الفهرسة

كل وَسمٍ كان اسمه -أي مفتاحه- حرفاً فرديا لاتينياً (a–z, A–Z) وجب على الـمُرَحِّلات فهرستُه. وبهذا تصح التصفية والإستعلام. مثل

{"#e": ["5c83da..."]}

، إذ تطلب من المُرحل كل حدثٍ فيه الوسم e وقيمته مُعرّف ذاك الحدث. واعلم أن الفهرسة لا تقع إلا على الموقع 1 -أي القيمة- دون باقي الحقول.

أما ما كان متعدد الحروف من الوسوم مثل alt وtitle وsummary، فله معنى عند العملاء مفهوم، لكنه عند المرحلات غير مفهرس، ولا يستعمل في التصفية والإستعلام.

مفهوم الفهرسة لدى الـمُرَحِّلات

ما الـمُرَحِّل إلا خادم يجمع الأحداث ويصونها، ويقدمها للعملاء الذين يطلبونها. وأعظم عمل المرحل أن يُجيب عن الإستعلامات بسرعة وعجل.

فإذا فهرس المرحل وسما، جعل له جدول مراجعة فورية (Lookup table) لقيمة ذلك الوسم — يشبه فهارس قواعد البيانات — ليُجيب على عجل عن سؤال: “هات كل الأحداث التي ارتبط وسمها بهذه القيمة”، من غير أن يمر على كل حدث مخزون عنده.

الطريق البطيئة عند غياب الفهرس

لو سأل العميل الـمُرَحِّل: “أوجد لي كل حدث ذُكر فيه المفتاح العام س”، ولم يكن هناك فهرس معلوم، لوجب على المرحل أن:

1. يقرأ كل حدث مخزن عنده.

2. يَفُكَّ مصفوفة الوسوم (tags) لكل حدث.

3. ينظر هل فيها وسم من نوع p يشير إلى المفتاح س.

4. يجمع المُطابق بعد طول العمل.

وهذا لعمري في زمن الملايين من الأحداث بطيءٌ لا يُعمل به.

الطريق السريعة مع وجود الفهارس

يحفظ المرحل جدولاً منفصلاً يجري فيه الأمر على هذا المثال:

فإذا أرسل العميل مصفاة استعلام نصها

{"#p": ["f7234bd4…"]}

نظر المرحل في الجدول نظرة واحدة، فيعيد المعرّفات المطابقة في لمح البصر.

لِـمَ اقتصرت الفهرسة على الحروف الفردية؟

ذلك شرط مقصود لضمان التوسعية (Scalability contract) صِيغَ في المعيار NIP-01. إذ يجب على الـمُرَحِّلات أن لا تفهرس إلا ما كان من حرف لاتيني واحد (a–z ،A–Z). وهذا يجعل حجم الفهرس محدودا معلوما، فلو فُهرس كل وسم كثير الحروف مثل

["title", "…"]

أو

["summary", "…"]

لكبر الفهرس وضاقت المساحة. فكانت القاعدة الحاكمة:

• وسم من حرف واحد (e, p, a, r, t…) ← وجب على المُرَحِّل فهرسة قيمته← ويمكن للعميل التصفية بناءً عليه.

• وسمٌ متعدد الحروف (alt, title, summary…) ← يُخزنه المُرَحِّل داخل الحدث (JSON) لكن لا يفهرسه ← والعميل لا يقدر على التصفية به ، بل يقرؤه بعد جلب الحدث.

الفهرسة للموقع الثاني فقط

حتى في الوسوم الـمُفهرسة، فلا تُفهرس إلا قيمة الوسم (الموقع 1)، وَصلة المُرَحِّل أو تلميح المؤلف الموجود في المواقع اللاحقة. فالوسم ["e", "5c83da…", "wss://relay.example.com"] يُفهرس تحت المفتاح e والقيمة 5c83da… حصراً، ويُهمل رابط المُرَحِّل من الفهرسة.

وخلاصة القول: أن الفهرسة هي التي تحوّل المُرَحِّل من مخزن أعمى للأحداث إلى قاعدة بيانات مرنة ومُستَعلمَه، وأن عُرف الحرف الواحد هو الذي يضمن هذا العمل عند الإتساع.

أنواع الأحداث (Event Kinds)

أما حقل النوع (Kind) فهو إعلان الحدث عن نوعه وصفته، يخبر العملاء بمعنى هذا الحدث وكيف تكون هيئته ، كما يخبر نوع الـ MIME المتصفح كيف يعامل الملف المطروح. ولولا الأنواع لكان كل حدث مبهماً لا يُعرَفُ له عمل.

والحقيقة هنا أن الوسوم تتبع النوع ، فالوسم "r" في حدثٍ من النوع (1) قد يعني “هذا المنشور هو رد على سلسلة المنشورات (thread) س”، لكنه في النوع (10002) يعني “هذا هو المُرَحِّل الذي اُستعمل”. فالنوع هو من يمنح الوسوم معناها ووظيفتها.

النوع 0 — بياناتُ وصفٍ للمؤلف

هو النوع الوحيد الذي يتولى المعيار NIP-01 بيانه. وحقل المحتوى (content) فيه كائن جيسون JSON:

{"name": "alice", "about": "builds on nostr", "picture": "https://…"}

وهو مُستَبدَل -كما سيأتي-، فلا يحفظ المرحل إلا آخر ما كُتب لكل مفتاح عام. فنشر حدث جديد من النوع (0) هو تحديث لوصف حسابك.

سلوكيات التخزين الأربعة

لم يقم المعيار بتعريف كل رقم نوع، بل جعلها في أربعة نطاقات تدل المرحل كيف يكون الخزن والإمتثال. وهذا هو العهد بين ناشر الحدث وصاحب المرحل:

• المنتظم (Regular): يُخزن فيه كل شيء إلى الأبد (ما دام ذلك في سياسة المُرَحِّل). فما كتب فيه فهو سجلٌ دائم. ومثاله: النوع 1 (المنشورات)، والنوع 4 (الرسائل الخاصة).

• المُستَبدَلة (Replaceable): لا يُحفظ إلا آخر حدثٍ اجتمع فيه (المفتاح العام + النوع). وما قدُمَ من النُسَخ فمصيره الحذف والزوال. فليس للمستعمل سوى بيانات وصف واحدة (النوع 0)، وقائمة متابعة واحدة (النوع 3)، فنشر الجديد يقضي على القديم.

• العابر (Ephemeral): لا يُطالب المرحل بخزن هذه الأحداث بتاتاً، فهي رسائل تُرسل للحظتها وتُستعمل للإشارات اللحظية مثل مؤشرات الكتابة أو بيان الحضور الحي، وإن فاتك النظر فيها فقد مضت وانقضت.

• المُعنوَن (Addressable): هو كالمُستَبدَل، غير أن مفتاح التمييز فيه يتألف من تجميعة: النوع + المفتاح العام + قيمة الوسم d بدلاً من النوع والمفتاح العام فقط. فيكون الوسم d بمنزلة المعرّف الخاض، مما يتيح للمفتاح العام الواحد أن يمتلك أحداث متعددة مُعنوَنَه من نفس النوع — ومثاله: المقالات الطويلة (النوع 30023)، حيث لكل مقالة قيمة d مختلفة. ولا يُحفظ إلا آخر نسخة لهذا الثلاثي المذكور (النوع + المفتاح العام + d).

فض النزاع وتساوي الزمان

إذا استوى حدثان من النوع المُعنوَن أو المُستَبدَل في زمن الإنشاء (created_at)، قدّم المرحل ذلك الذي يسبق رقمه في الترتيب المعجمي -أي الرقم الست عشري الأقل-. وهذا حُكمٌ حتمٌ لتجتمع المرحلات كلها على فائز واحد من غير حاجة لمشاورة أو تنسيق.

سلوك الطلب (REQ) في الأحداث المُستَبدَلة

متى طلب العميل مِثلَ:

{"kinds": [0], "authors": ["<pubkey>"]}

فلا يعطيه المرحل إلا آخر نسخة باقية عنده - حتى لو كان يحفظ القديم منه-، وبهذا يسلم العميل من عناء إسقاط المكرر بنفسه.

بيان التواصل بين العميل والمُرَحِّل (Client ↔ Relay communication)

هذا هو باب الطريقة والتعامل لمعيار نوستر - كيف يقع الحديث بين العملاء والمرحلات عبر قنوات “ويب سوكت” (websocket). ما مضى كان في صفة البيانات ونعتها، أما هذا ففي كيفية سوقها ومدها.

وسيلة النقل: قناة ويب سوكت واحدة لكل مُرَحِّل

يفتح العميل قناة واحدة مستمرة مع كل مرحل، ويسوق عبره كل مطالبه من الإشتراكات والنشر. وهذا مقصود للتخفيف، إذ هو أقل كلفة من فتح قناة جديدة مع كل سؤال، وبه يقدر المرحل على ضبط الحدود لكل متصل، مِثل حد السرعة وأعلى رقمٍ للإشتراكات.

من العميل إلى المُرَحِّل: ثلاثة أنواع من الرسائل

EVENT — نشر حدث:

["EVENT", { ...event object... }]

يدفع العميل بالحدث المُوَقَعِ إلى حِمى المرحل، فينظر فيه المرحل ويرد بالقبول والإمتثال OK.

REQ — الطلب والاشتراك:

["REQ", "sub1", { ...filter... }, { ...filter... }]

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

وإذا أُرسل طلبٌ جديد REQ يحمل نفس معرّف الاشتراك القائم، فإنه يحل محله ولا يكون اشتراكا ثانيا.

CLOSE — إغلاق الاشتراك:

["CLOSE", "sub1"]

يقول فيه العميل للمرحل: كفى، واقطع مدد هذا الإشتراك. ويستعمل هذا عند انتقال المرء عن صفحته أو تبديل جلسته.

المصافي: لغة الاستعلام (Filters)

المصفاة هي النعت الذي يصف به العميل ما يطلب من الأحداث. وكل حقل يُذكر فيها يجري مع غيرة بمنطق الجمع والتقييد (AND). أما المصافي المتعددة في طلب واحد REQ فتجري بمنطق التخيير (OR). فطلب

["REQ", "s1", filterA, filterB]

يعني: “هات ما يطابق المصفاة الأولى أو المصفاة الثانية”.

واعلم أن العدد المحدود (limit) إنما يكون للفيض المخزون الأول فقط ، ولا أثر له في الأحداث الحية التالية. وإذا تساوى حدثان في الزمان، قدم الأقل رقما في الترتيب المعجمي كما مضى.

ويشترط في قيم ids وauthors و#e و#p حروفا ست عشرية صغيرة بالغة 64 حرفا بالتمام، لا مجال فيها للنقصان.

من المُرَحِّل إلى العميل: خمسة أنواع من الرسائل

EVENT — سوق الحدث:

["EVENT", "sub1", { ...event object... }]

يرسلها المرحل لكل حدث طابق الإشتراك القائم، سواء كان من الماضي أو من الحاضر. وتكون موسومة بمعرّف الاشتراك (subscription_id) ليعرف العميل صاحبها.

EOSE — نهاية الأحداث المخزنة (End of Stored Events):

["EOSE", "sub1"]

إشارة برمجية له شأن جليل، فإذا أفاض المرحل كل ما لديه من الماضي، بعث هذه الإشارة EOSE. فما كان قبلها فهي بيانات الماضي، وما كان بعدها فهي بيانات الحاضر. وبها يعلم العميل متى يوقف دوارة الإنتظار (Loading spinner) ليفتح المعاينة الحية.

OK — صك القبول أو الرفض:

["OK", "<event_id>", true|false, "<message>"]

تأتي جوابا على كل حدث رفعه العميل. فإما القيمة المنطقية (Boolean) فتقول: قُبِلَ أو رُفضَ. فإذا كان رفضاً، بدأت الرسالة بلفظٍ مفهوم للآلة مثل (blocked: أو rate-limited: أو pow: أو invalid: أو restricted: أو duplicate: أو mute: أو error:) يليه بيان يفهمه الإنسان. وإن كان قبولاً، فقد تأتي الرسالة فارغة أو فيها نُصحٌ مخصوص (مثل: القيمة true مع نص "duplicate: already have this event"، فيعني أنه مقبول لكنه معلوم من قبل).

CLOSED — قطع الإشتراك من قِبل المُرَحِّل:

["CLOSED", "sub1", "<message>"]

وفيها يقوم المرحل بإماتة الإشتراك - إما لرفضه الطلب REQ أول الأمر، أو لأن الإشتراك أمسى خاملا بلا حراك، أو لأن المرحل نفسه يهم بالإغلاق. ويجري فيها لفظ البدء كما جرى في رسالة الـ OK. وحينها لا ينتظر العميل أي حدث آخر لذا الإشتراك.

NOTICE — إشعار نصي عام:

["NOTICE", "welcome to relay.example.com"]

نصٌ مُطلقٌ حُرّ؛ لا تنسيقا قياسيا له أو معالجة برمجية محددة. تأخذ به المرحلات لنشر التحايا، أو التحذير من الخطايا، أو بيان العلل (Debug info). وللعميل أن يعرضه للناس أو يطويه فلا يذكره.

حدّثني قلبي بحديثٍ طريف، وذكّرني بأمرٍ قديمٍ لطيف؛ وذلك أنّي كنتُ يومًا في معمل الحواسيب زمنَ الإبتدائية، في حصّةٍ تُدعى «الكمبيوتر»، ونحن صِبيةٌ بين لعبٍ ولهوٍ وسُرور. فهذا قد أطرق رأسه إلى كانسة الألغام (Minesweeper) ينقّب عن الألغام ، وذاك قد ألقى أوراقه في بسوليتير — وكنا نسميها «البطّة» — وثالثٌ يضرب الكُرات في لعبة ”بين بوول”. وأمّا أنا فكنتُ جالسًا أتفرّج كعادتي، لأن في المعمل اثني عشر جهازًا لا يعمل منها إلا أربعة! وربما كانت تعمل كلّها، غير أنّها — كعادة مدارسنا وجامعاتنا — تُركن في الزوايا حتى يفسدها الزمان، فلا تُمسّ ولا تُستعمل حتى إذا خربت قالوا: قد خربت! وكان الصبية يتسابقون إلى الأجهزة تسابق الخيل إلى الميدان، وأما أنا فعادتي كراهية السباق، فأقعد حيث أقعد، وأرقب ما يجري وإذا سنحت فرصة العب.

وبينما المعلمة تشرح لنا كيف نفتح البرامج من قائمة «إبدأ» في ويندوز إكس بي، التفتت إلينا وقالت: أتدرون كيف كنّا نشغّل التطبيقات قديمًا؟ أتدرون كيف كانت الحواسيب؟ قلنا: وكيف كانت؟ قالت: كانت مجرّد شاشةٍ ومفاتيح! قلنا: وما الغريب في هذا؟ فنحن لا نرى غير شاشةٍ ومفاتيح! قالت: بل كانت الشاشة سوداءَ، لا ألوان فيها ولا نوافذ، ولا قائمة «إبدأ» تُعين وتُرشد. فقلنا — وقد اتسعت أعيننا دُهشًا —: وكيف تُشغّلون التطبيقات والألعاب بلا قائمة «إبدأ»؟ قالت: كنّا نكتب اسم التطبيق أو اللعبة بالإنجليزية، فتعمل. وكان لازم حفظ أسماء البرامج كلّها عن ظهر قلب! فعندها بُهتُّ دُهشًا، ووقفتُ حائرًا بين العجب والاستغراب، وقلت في نفسي: كيف يُشغَّل تطبيقٌ بلا «إبدأ»؟ وكيف يحفظ البشر أسماء كلّ تلك التطبيقات والألعاب؟ وبالإنجليزية أيضًا! فلبثتُ أعوامًا وأنا أذكر قولها ذكرَ المتعجّب، حتى دخلتُ الجامعة، فعرفتُ جنو/لينكس، وصاحبتُ الترمينال، وألِفتُ باش وسطر الأوامر.

وها أنا ذا اليوم أقضي أكثر أوقاتي في تلك الشاشة السوداء التي كنتُ أستغربها! وعندها فقط فهمتُ سرّ كلام المعلمة، وعلمتُ أنّها كانت تقصد نظاما قديما يُدعى مايركوسوفت دوز MS-DOS وسطر الأوامر فيه. 😄

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

التجارة في المُراقبة والتجسس

صُمِّم نوستر في بداياته ليقاوم الرقابة. غير أنّ هذه الغاية ليست إلا شُعبةً من شُعبه. فـنوستر إنما وُضع ليزيد الحريات الرقمية للمستعملين: كالخصوصية، وحقّ الوصول إلى المعلومات، و«الخروج الموثوق» — أي القدرة على المغادرة دون أن تُحتجز رهينة منصةٍ بعينها. ولمّا اعتُنِق علم التعمية في أول أيامه اعتناقًا مؤسسيًا في الغالب، اختلّ ميزان الشبكة، فلم تعد مع مصالح مستعمليها، بل استحوذت عليها «المنصّات»، فأضحت هي الحَكَمَ والقيّمَ والمالكَ للمفاتيح. ومن ثَمَّ نشأ حالٌ من اقتناص الريع، حيث يُستغلّ المستعملون — وهم صانعو القيمة كلّها — ويُنتقَص منهم، ويُوجَّه سلوكهم، ويُضلَّل وعيهم، وتُباع بياناتهم، على أيدي أوصياء تلك القيمة وحُرّاسها. وذلك بونٌ بعيدٌ عن الحلم الإنساني الذي راود روّاد الإنترنت الأوائل كما عبّر عنه «تِم برنارد لي»:

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

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

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

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

وأصحاب رؤوس الأموال إنما يبتغون الربح. وقد ذهب «بيتر ثيل» في كتابه «Zero to One» إلى أن أصوب سبيلٍ للربح في السوق هو إقامة احتكار. وبما أنّ احتفاظ المستعملين مرتبط بتأثير الشبكة، فإن بلوغ حالة الإشباع السوقي غايةٌ دائمة، وترتفع «تكلفة الانتقال» إلى منافسٍ آخر، إذ ينبغي للشركات أن «تستحوذ» على مستعمليها، فلا يسهل عليهم الفكاك.

وقد بلغتا جوجل وفيسبوك مبلغ الإتقان في هذا الأمر، فهما حاضرتان منذ زمنٍ طويل، بخلاف شركات الجيل الأول من الإنترنت مثل «MySpace» و«Yahoo» و«AOL». لقد تعلّم عمالقة الجيل الثاني كيف يجمعون بين أمرين معًا: الاحتفاظ بالمستعملين وتعظيم العائد منهم في آنٍ واحد. والحقّ أنّ يسيرًا من إيرادات هذه الشركات يأتي من بيعٍ مباشرٍ لخدمةٍ أو اشتراك. إنما تُحوِّل هذه المنصّات المستخدمَ نفسَه إلى سلعة. فلدى المستعمل شيآن يبيعهما: انتباهه وبياناته. ولا تستطيع هذه المنصّات الاتّجار بهذين الموردين إلا لأنها تتوسّط العلاقة، فتملك منفذ الوصول إليهما بحكم موقعها الوسيط. فهي تعيش بإقحام نفسها في العلاقات الخاصة أو العامة، لتستخلص من خلالها تلك الخيرات غير الملموسة.

وينجح هذا النموذج لأن أكثر مستعملي الإنترنت إمّا لا يعتقدون أن لإنتباههم أو بياناتهم قيمة تُذكر (فيقول احدهم: «ولِمَ أحتاج إلى الخصوصية؟ ليس لديّ ما أخفيه»)، وإمّا يشعرون بالعجز عن الانفكاك من اقتصاد الانتباه. فمرورك بلوحةٍ إعلانية في طرف بصرك، أو تسجيل المُصوِّرات لرقم مركبتك، لا يبدو — في نظر كثيرين — مماثلًا لدفع رسمٍ شهري لاستعمال الطريق. وسواء أكنت تبالي بتسجيل تحرّكاتك أم لا، فإنك — في الغالب — ستسلك الطريق على أي حال.

صحيحٌ أنّ البيانات والانتباه — كلٌّ على حدة — لا يبدوان ذوي قيمةٍ تُذكر. غير أنّ قوّتهما في الاجتماع والتراكم. فـ«البيانات الضخمة» ليست معلوماتٍ متناثرة، بل هي قدرةٌ على استنباط أنماط السلوك والتنبّؤ بها، ثم استعمال ذلك للتأثير في الناس: ماذا يشترون، وبماذا يؤمنون، وكيف يتصرّفون، ولمن يُصوتون.

وليس الإعلان محضَ إخبارٍ لمشترٍ راغبٍ بسلعةٍ أو خدمة، بل هو — في جوهره — تكييفٌ للسلوك ليصير قابلًا للتوقّع والقياس. والهندسة الاجتماعية — كسائر ضروب الهندسة — نزّاعةٌ إلى التوسّع والإحاطة ما لم تُكبَح بضابط. وثمنُ التخلّي عن انتباهنا وبياناتنا لهؤلاء الوسطاء الرقميين هو انتقاصُ حريّتنا في الاختيار. ويشتدّ هذا الخطر لأن المستعملين يتلقّون — مع مرور الزمن — خدمةً أقلّ جودةً مقابل زمنهم وانتباههم. فشركات الإنترنت الكبرى، بما لها من وفورات الحجم، تملك القدرة على أن تفرض — على نحوٍ غير متكافئ — كُلفًا من التعقيد على من يخرج عن «ملفّ العميل المثالي» (ideal customer profile) الذي صمّمت أعمالها حوله. فهي تُيسّر الطريق لمن يوافق النموذج، وتُعسّرها على سواه.

وكما جاء في هذه التدوينة:

لقد نال اللاعبون الكبار — من شركاتٍ وحكومات — ميزةً نظاميةً عظيمة على الأفراد، فهم يضعون القواعد، لكنهم لا يتحمّلون كلفة انكسار تلك القواعد. يزيدون تعقيد الحياة اليومية، ولا يُعاقَبون على ذلك، بل يُكافَأون.

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

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

وعلاج علل الإنترنت لا يكون إلا بالناس أنفسهم. «فنوستر» ليس نظامًا شاملًا لكبح «الشرّ الرقمي» — إذ إن نظامًا كهذا قد ينزلق هو ذاته إلى الشمولية — بل هو سبيلٌ للفاعلية الفردية والجماعية، كي تُعالَج المشكلات وفق خصوصيات الأفراد والمجتمعات وسياقاتهم المتنوّعة.

معيارٌ يسير وسهل

إنّ «نوستر» — في وجوهٍ كثيرة — حلٌّ «ساذج» لمسألةٍ معقّدة. فالحوافز، وبُنى السلطة، والنُّظم التقنية، عوالمُ متشابكة لا تُدرَك تفاصيلُها إدراكًا تامًّا. غير أنّ ثمّة أنماطًا هيكلية أساسية يقوم عليها الإنترنت الحديث، وهي التي تُمكّن اختلالاته وتُغذّيها.

يقوم «نوستر» على فكرةٍ بالغة اليُسر: يُنشئ المستعمل «حدثًا» (event)، وهو بنيةُ بياناتٍ تتضمّن المحتوى، ومفتاحه العام، وتوقيعه الرقمي، وبصمة الحدث (hash)، وبعض المعلومات الأخرى. وما إن يُنشأ الحدث حتى يُرسَل إلى الآخرين عبر «المُرحلات» (relays)، وهي — في أصلها — خوادم «مقابس الشابكة» (WebSocket)، وإن كان يمكن أيضًا نقل الأحداث عبر البلوتوث، أو إرفاقها برسالة بريد رقمي، بل حتى تدوينها وإرسالها بوسيطٍ كيفما اتُفق. ومعيار المُرحلات شديد اليسر. إذ يقتصر غالبًا على إرسال الأحداث واستقبالها ورفضها وطلبها.

أما أنواع المحتوى أو «الأنواع» (kinds) التي يصفها المعيار فهي ضعيفةُ الارتباط بعضها ببعض، مما يسمح ببناء طيفٍ واسع من التطبيقات «العملاء» (clients) القادرة على التخاطب فيما بينها. وليس لزامًا على كل تطبيق أن يُنفّذ المعيار كاملًا. «فنوستر» بيئةٌ مثلى لتشييد تطبيقاتٍ صغيرة تؤدّي وظيفةً واحدة، من غير أن تفرض على المستعمل كلفةَ انتقالٍ مُرهِقة. تخيّل — مثلًا — أنك تتابع شخصًا في منصّة تدوينٍ مصغّر، ثم تفتح قارئ المدوّنات لديك، فتجد منشوراته قد ظهرت تلقائيًا. تُظلّل فقرةً وتكتب تعليقًا. ثم تعود إلى منصّة التدوين الأولى، فتجد ردودًا على تعليقك كتبها أناسٌ يتابعونك عبر عشرات التطبيقات الأخرى. تلك ثمرةُ الهيكل المفتوح. وفي وجوهٍ كثيرة، يملك «نوستر» قابليةَ أن يكون ترقيةً لبنية الإنترنت برمّتها. إذ يفصل بين تخزين البيانات (المرحلات)، والهوية (المفاتيح)، والوظيفة (العملاء). وبذلك يسهل تركيب الأجزاء بطرائق جديدة وخلاّقة. وهذه دعوى كبيرة، ولا ريب أنّ ثمّة أمورًا لا يُحسن «نوستر» أداءها.

وفي اصطلاح الأنظمة الموزعة، فإن «نوستر» لا يضمن الاتساق (consistency)، لكنه يوفّر قدرًا عاليًا من الإتاحة (availability) وتَحَمّل الانقسام (partition tolerance). هو — في جوهره — ما يشبه قاعدة بيانات موزّعة، تعمل عُقدُها باستقلالٍ تامّ من غير حاجةٍ إلى مُنَسقٍ مركزي. وبنسخ البيانات الموقَّعة ذاتها إلى مرحلات متعدّدة، تبقى متاحةً ولو تعطّلت بعض العقد أو حظرت كاتبها.

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

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

هذه قائمةٌ متجدّدة بالبرامج التي أستعملها وأرشّحها. أُحدّثها كلّما غيّرت برنامجًا، أو وقفتُ على برنامجٍ جديدٍ أراه جديرًا بالتجربة.

برامج الحاسب

نظام التشغيل

• Arch Linux
• MangoWC
• Dank Material Shell
• Foot

محررات النصوص

• Neovim

متصفحات الشابكة

• Brave
• GNU IceCat
• Zen Browser

التدوين والأعمال الأكاديمية

• TreeSheets
• LibreOffice

قراءة الكتب والوثائق

• Zathura
• Papers

التعمية وإدارة كلمات المرور

• GnuPG
• Tomb
• KeePassXC

إدارة الملفات

• PCManFM
• nnn

العملات الرقمية

• Bitcoin
• Monero
• Electrum

مشغلات الوسائط

• mpv
• uosc
• imv

برامج الجوال

نظام التشغيل

• Evolution X

القرآن الكريم

• سورة

مشغلات الوسائط

• mpvKt
• Gramophone

الصور

• Fossify Gallery

إدارة الملفات

• Material Files

الكتب والوثائق

• Librera

تدوين الملاحظات

• EasyNotes
• BeauTyXT

التنزيلات

• Aria2App
• Seal

متصفح الشابكة

• Brave

الخصوصية والأمان

• Orbot
• Exif Eraser
• DNSNet

حدثنا معتزٌ قَالَ: كنتُ في مَقيلٍ مِن أهلِ الدِرَايةِ، وأربابِ الصناعةِ والرِوايَةِ، ممن يبنونَ القُصُورَ منَ الأكْوَادِ، وَيَسبِكُونَ التَّطْبِيقَاتِ سَبكَ الجِيَادِ. فبينما نحنُ فِي بحثٍ عميقٍ، وجِدالٍ ونهيقٍ، إذ برزَ فتًى يُقالُ لهُ بَهيم بنُ فَهِيمُ، يمشي مِشيَةَ التَّائِه الغَريمِ، قد تَمَنْطَقَ “برَستَ” تَمَنطُقاً، وصارَ بذكرِهَا مُتفدِّقاً، يرى أن ما سواها هباء منثُورٌ، وَ كُلَّ كُودٍ بغيرها مَبتُور. فقامَ إليهِ عمرُ ابنُ عِمرَانَ، وهو شابٌّ رزينٌ، من حُمَاةِ “السِّيِّ” وَالمتمكِّنينَ، قائلاً له: “رُويدَكَ يا بهيم، فَمَا كلُ بريقٍ ذهباً، ولا كل حديثٍ طَرَباً! أَتَرُومُ هَدمَ أركانٍ شُيدت من عقودٍ، ومحوَ لغاتٍ هِيَ للعلمِ جنودٌ؟” فثارَ بهيمٌ وزبَدَ، وَصَاحَ وارتعدَ، وقالَ: “يَا بَنِي العرب! أيكمْ أعرفُ بصيانةِ الذاكرةِ، وَأَشْحَذُ فِي قَوْلَبَةِ المُعَاصَرَةِ؟ أَنَا الرستِيُّ الغالبُ، وأنتَ فِي بحرِ أوهامكَ راكبٌ! لغتُكَ ثُقبٌ فِي سفينةٍ، وعِلةٌ في مدينة!” فقال عمر: “بل أنت بل أنتَ قِردُ جدالٍ، وأسيرُ ضلالٍ، تُكثرُ الصياحَ وتُقلُّ الصلاح. غِرٌّ غرَّتكَ القشورُ، وأعمتكَ المالِكِيَّةُ (Ownership) عن المقدورِ! ليشتُم كلٌّ منا صاحبهُ، فمن غَلَبَ سَلَبَ!”

قالَ بَهيم:“يا ثِقَلَ الدَّيْنِ يَا سِمَةَ الشَّيْنِ، يَا بَريدَ الشُّومِ يَا طَريدَ اللُّومِ! يا جامعَ القمامةِ بيدهِ، يا من يفيضُ كُودُهُ سُماً في كبدهِ! يا خادمَ المؤشرِ الفارغِ (Null Pointer) اللعينِ، يا مضيِّعَ عمركَ بين المجانينِ! يا ثُقبَ الأمْنِ، يا عدوَّ الفنِّ، يا من يسيرُ في حقلِ ألغامٍ، ويظنُّ نفسهُ مَلِكَ الأيام!”

فقالَ عمر:“يا قَرَّادَ القُرُودِ، يا لَبُودَ اليهودِ، يا عدماً في وُجوُدٍ! يا من حَبَسَه فاحِصُ الإستعارةِ (Borrow Checker) كالمسجونِ، ورضيَ بقيودِه كالمجنونِ! أتَعِيرُني بالسِّيِّ وهي أمُّ القواعدِ، وأنتَ تتسكعُ بين الشواهدِ؟ يا ساعةَ الحَيْنِ، يا ثِقَلَ الدَّينِ، يا من لا يكتُبُ سطراً إِلا بموافقةِ الرقيبِ، ولا ينطِقُ حرفاً إلا كالغريبِ! يَا أفضحَ من عَبْرَةٍ، يا أَبغَى من إبرةٍ، واللهِ لو صنعتَ من ‘رَسْتَ’ طيارةً لما بلغتْ مطارةً، ولو نسجتَ من خيوطها نعلاً لما جاوزتَ بقلاً! تريدُ أن تكونَ فهيمةً، وما أنت إلا بهيمة”. ثم هدأ عمرُ وأقبلَ برزَانَتهِ، وأدلى بحجّتهِ وأمانتهِ، فقالَ: “يَا فهيم، إنما اللغاتُ أدواتٌ، لا عقائدُ وخرافاتٌ. أتعِيبُ عَلَيَّ لغةً بُنِيَت عليها النُّظُمُ، وسارت بها الأممُ؟ لولا ‘السِّيُّ’ لما عرفتَ لحاسبِكَ نِظاماً، ولا ‘لِـرَسْتِكَ’ قِوَاماً، فهيَ الأصلُ وصاحبتك الفرعُ، وهيَ الأرضُ وصاحبتك الزرعُ. أنتَ تُنفِقُ الساعَاتِ في إرضاءِ المُصَرّف (Compiler)، وأنَا أَبْنِي المَعَالِمَ واتَصَرفُ. أنتَ مقبوضٌ بالقيودِ، وأنا حرٌّ أتجاوزُ الحدودَ، فإن أسأتُ فمن نفسي، وإن أحسنتُ فبغَرْسي.” فَسَكَتَ بهيم وأُطْرِقَ رأسُهُ، وذهبَ بأسُهُ، وعلِمَ أن التَّسَرُّعَ مطِيَّةُ الفشلِ، وأنّ الحكمةَ في طولِ الأمَل.

قال معتز: فلما رأيتُ الغلبةَ لعُمرَ، وكيفَ قَمَعَ هذا الشَّرَرَ، قلتُ لهُ: “للهِ دَركَ من حكِيمٍ! لقد داويتَ سقيمًا بنَسِيمٍ.” ثم انصرفنا ونحنُ نعجَبُ من حالِ الزمانِ، كيفَ صارَ العلمُ فيهِ ميداناً للهذيانِ!

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

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

ثم لمّا أقبل الإصدار الثالث، انقسم باكمان شطرين: شطرٌ يتولى الأعمال الخفية في الخلفية، وسُمّي libalpm، وشطرٌ ظاهرٌ يواجه المستعمل ويخاطبه بالأوامر المعتادة. ثم توالت عليه التحسينات والإصلاحات في الإصدارات اللاحقة، حتى غدا من أمهر مديري الحزم وأسرعهم.

ومن أراد الوقوف على تفاصيل تاريخه وتطوراته فدونه هذا السجل: history.

حيلٌ وفِطنٌ في استعمال باكمان

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

البحث عن كلمة في قواعد بيانات الحزم:

pacman -Ss <any-word>

فهذا الأمر يفتش في أسماء الحزم ووصفها عن الكلمة المطلوبة.

الأستعلام عن حزمة بعينها:

pacman -Si libcaca

وفي هذا الاستعلام تظهر تفاصيل الحزمة كلها: من وصفها، وإصدارها، وحجمها، وموقعها، وتاريخ تحديثها.

البحث عن ملف تابع لحزمة:

pacman -F <file-name>

وقد يحتاج المرء أحيانًا إلى برنامجٍ صغير أو أداةٍ لا يعرف الحزمة التي تحتويها، فيبحث عنها على أنها ملف. وهذا من أنفع أوامر باكمان؛ إذ كل شيءٍ في أنظمة يونكس ملف.

تثبيت حزمة:

doas pacman -S <pkg-name>

تحديث جميع الحزم:

doas pacman -Syu

تحديث قواعد بيانات الحزم:

وقد يحتاج المستعمل أحيانًا إلى تحديث قواعد البيانات قبل التثبيت أو البحث، ويتم ذلك بالأمر:

doas pacman -Syy

ولباكمان ثلاث قواعد بيانات مشهورة:

• core:وتضم الحزم الأساسية للنظام.
• extra: وهي أوسع القواعد وأكثرها احتواءً للبرامج.
• multilib: وتضم الحزم الداعمة لمعمارية x86 وما يتصل بها.

ويمكن تفعيل هذه القواعد أو تعطيلها عبر ملف التخصيص:/etc/pacman.conf

ملف التخصيص pacman.conf

وفي هذا الملف يهيّئ المستخدم باكمان على ما يلائم ذوقه وحاجته. ومن الخيارات الحسنة فيه:

• Color: لتلوين المخرجات
• CheckSpace: للتحقق من مساحة القرص قبل التثبيت
• VerbosePkgLists: لعرض الحزم وإصداراتها وأحجامها في صورةٍ مرتبة.
• ParallelDownloads = n: للتنزيل المتوازي، ويُستبدل الحرف n بعدد الأنوية في المعالج.
• ILoveCandy: اكتشفه بنفسك

AUR

ومن أعجب ما في أرتش قاعدةُ Arch User Repository، وتُعرف اختصارًا بـ AUR.

وهذه القاعدة ليست رسمية، بل يرفع المجتمع إليها الحزم، ولا يتولى مطورو أرتش مراجعتها أو ضمان سلامتها، ولذا قد يوجد فيها ما لا يؤمَن جانبه. غير أنّ فضلها عظيم، إذ تكاد تضم كل برنامجٍ يخطر بالبال.

ولا يُستعمل الـ AUR بباكمان وحده، بل يحتاج إلى برنامجٍ مساعد، ومن أشهرها yay وparu، وأميلهما عند كثير من الناس yay.

yay -S <pkg-name>

وأكثر الحزم في الـ AUR تُبنى من المصدر، ولذلك يعمد بعض الناس إلى تسريع التصريف بتعديل الخيار: MAKEFLAGS="-j4" في ملف /etc/makepkg.conf ومعنى -j4 استعمال أربعة أنوية في أثناء التصريف.

ومن جميل ما في yay الأمر:

yay -P --stats

فإنه يعرض إحصاءات نافعة عن الحزم المثبتة في النظام.

حذف الحزم

حذف حزمة:

doas pacman -R <pkg-name>

حذف حزمة مع مستلزماتها:

doas pacman -Rsn <pkg-name>

حذف حزمة دون الاكتراث بالتبعيات

doas pacman -Rdd <pkg-name>

كيف تعرف عدد الحزم في نظامك?

pacman -Qe           عرض الحزم المثبته
pacman -Qeq          عرض الأسماء دون رقم الاصدار
pacman -Qe | wc -l   عدد الحزم المثبته في نظامك
pacman -Qm           عرض الحزم المثبته من aur
pacman -Qm | wc -l   عرض عدد الحزم المثبته من aur

حذف الحزم المهجورة

pacman -Qdtq | pacman -Rns -

أدوات pacman-contrib

وقد وفر مطورو باكمان حزمةً اسمها pacman-contrib، تضم أدواتٍ نافعة تُحسّن التجربة وتيسّر بعض الأعمال.

ومنها:

• checkupdatesيعرض التحديثات المتاحة دون مزامنة قواعد البيانات.
• paccache أداةٌ لتنظيف الكاش وترتيبه.
• paclist تطبع قائمة الحزم المثبتة.

وفي الحزمة غير ذلك من الأدوات النافعة، وتفاصيلها هنا: pacman-contrib

البشر يكتبون المعادلات الحسابية على الصورة المألوفة بينهم، فيجعلون العدد ثم يتبعونه بعلامة العملية ثم بالعدد الآخر. فنقول: «أربعة زائد سبعة»، وتُكتب هكذا:

4 + 7

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

ولهذا ابتكر “ادزخر ديكسترا” خوارزمية «المُفترق» المعروفة باسم Shunting Yard، وهي خوارزميةٌ تُحوِّل العمليات الحسابية من صيغة «توسيط العلامات» (Infix Notation)، التي يكتب بها الناس حسابهم، إلى صيغةٍ أخرى تُسمّى «تلحيق العلامات» (Postfix Notation)، وتُعرف أيضًا باسم “Reverce Polish Notation”. وهذه الصيغة الأخيرة أيسر على الحاسوب وأقرب إلى طرائق معالجته للعمليات الحسابية.

تلحيق العلامات Postfix Notation

وقبل الخوض في خوارزمية «المُفترق» ينبغي فهمُ كيفية تحويل العمليات من «توسيط العلامات» إلى «تلحيق العلامات». ففي هذه الصيغة تُؤخَّر العلامة الحسابية حتى تأتي بعد الأعداد بدل أن تتوسطها.

فإن قلنا: «أربعة زائد خمسة» كانت الصيغة:

4 5 +

بدلًا من:

4 + 5

وإن قلنا: «أربعة زائد خمسة ناقص ثلاثة» صارت:

4 5 + 3 -

أي نجمع الأربعة والخمسة أولًا، ثم نطرح من الناتج ثلاثة.

وهنا يظهر شأن «المكدس» القائم على قاعدة «الداخل أخيرًا الخارج أولًا»، إذ هو عماد هذه الصيغة وأصل عملها. ففي المثال:

3 4 -

يُدفع العدد 3 إلى المكدس أولًا، ثم يوضع العدد 4 فوقه، فإذا جاءت علامة الطرح أُخرج العددان، وأُجريت العملية، ثم أُعيد الناتج -1 إلى المكدس. وقد تتوالى الأعداد والعلامات بعد ذلك، فتُعامل المعاملة نفسها.

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

فالمعادلة:

(3 + 4) * (2 + 2)

تصير:

3 4 + 2 2 + *

فنضع الثلاثة ثم الأربعة في المكدس، فتأتي علامة الجمع فتخرجهما وتعيد الناتج 7. ثم نضيف العددين 2 و2، فتأتي علامة الجمع الثانية فتجعل الناتج 4. ثم تأتي علامة الضرب فتأخذ 7 و4 وتضربهما، فيكون الناتج 28.

وقد استُعملت هذه الصيغة في بعض الآلات الحاسبة القديمة، ولا سيما آلات HP

خوارزمية المُفترق Shunting Yard Algorithm

وهذه الخوارزمية هي الأداة التي تُحوِّل العمليات الحسابية من صيغة «توسيط العلامات» إلى صيغة «تلحيق العلامات» داخل الحاسوب. وتقوم على ثلاثة أركان:

• المدخلات
• طابور المخرجات
• مكدس العلامات

ولنشرح ذلك بمثالٍ سهل:

الخطوات:

1. المدخلات:

3 + 4

2. يُرسل العدد 3 إلى طابور المخرجات، إذ الأعداد تُرسل إليه دائمًا.
3. توضع علامة الجمع + في مكدس العلامات.
4. يُرسل العدد 4 إلى طابور المخرجات.
5. بعد انتهاء القراءة تُخرج العلامات الباقية في المكدس وتُلحق بطابور المخرجات.
6. فتكون النتيجة:

3 4 +

ومن هذا المثال تُستخلص قاعدتان:

• كل عددٍ يُدفع مباشرةً إلى طابور المخرجات.
• كل علامةٍ تبقى في المكدس تُخرج عند انتهاء القراءة وتُلحق بالمخرجات.

مثال آخر

وقبل الشروع في المثال ينبغي ترتيب العلامات الحسابية بحسب أولويتها واتجاهها:

المدخلات:

3 + 4 × 2 ÷ ( 1 − 5 ) ^ 2 ^ 3

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

1. ضع الرقم 3 في طابور المخرجات

2. ضع علامة الجمع في مكدس العلامات

3. ضع الرقم 4 في طابور المخرجات

4. ضع علامة الضرب في مكدس العلامات

5. ضع الرقم 2 في طابور المخرجات

6. اخرج علامة الضرب من مكدس العلامات وضعها في طابور المخرجات ثم ضع علامة القسمة في مكدس العلامات

7. ضع القوس في مكدس العلامات

8. ضع الرقم 1 في طابور المخرجات

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

10. ضع الرقم 5 في طابور المخرجات

11. وهنا وردَ إغلاقُ القوس، فنُخرجُ علامةَ الطرح من المكدس ونُلحقها بطابور المخرجات، ثم نُخرجُ فتحةَ القوس من المكدس ونطرحها، إذ لا موضعَ لها في الصيغة النهائية

12. ضع علامة القوة ^ في مكدس العلامات

13. ضع الرقم 2 في طابور المخرجات

14. ضع علامة القوة ^ في مكدس العلامات

15. ضع الرقم 3 في طابور المخرجات

16. وأخيرًا، نُخرج جميع العلامات الباقية في المكدس، ونُلحقها — على ترتيب خروجها — بطابور المخرجات.

فإذا انتهت القراءة أُخرجت جميع العلامات من المكدس، فكانت النتيجة النهائية:

3 4 2 * 1 5 - 2 3 ^ ^ / +

وهذه هي الصيغة التي يستطيع الحاسوب معالجتها بيسرٍ ومن غير حاجةٍ إلى تتبع الأقواس أو إعادة النظر في ترتيب العمليات.

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

هنا تطبيق للخوارزمية بلغة C

وَصْلاتٌ للإستزادة

• ورقة ديكسترا الأصلية عن الخوارزمية
• شرح مرئي للخوارزمية من قناة بيكوما

بدأت لغة الماركدون سنة 2004 على يد جون جروبر (John Gruber)، إذ ابتكرها لتكون لغةً لتنسيق النصوص يسهل على عامة الناس كتابتُها وقراءتُها. غير أنّ الحديث عن الماركدون لا يستقيم إلا بتمهيدٍ في ذكر لغات الهيكلة وماهيتها.

ما لغات هيكلة النصوص؟

لغات هيكلة النصوص — أو «لغات الوسم» (Markup languages) — هي جملةٌ من القواعد تُعنى بكيفية عرض النصوص وتنسيقها؛ فتجعل العنوان عظيمَ الخط، والاستطرادَ مائلَ الحروف، وتُبيّن مراتب العناوين: أهي أصولٌ أم فروع؟ وتُنشئ القوائم المرتبة وغير المرتبة، والجداول المنسقة، والوَصلات المشيرة، والصور المدرجة، وما إلى ذلك من ضروب التنسيق.

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

ومن أمثلة هذه اللغات: HTML، وDocBook، وtroff، وLaTeX، وXML، وصاحبتنا الماركدون.

ولكل واحدةٍ من هذه اللغات غرضٌ تؤمّه؛ فالـ troff تُكتب بها كتيبات لينكس المعروفة بصفحات man، والـ LaTeX تُصاغ بها الأوراق والبحوث العلمية، والـ HTML تُشاد بها صفحات الشابكة، وأما الماركدون فشأنها أوسع وألين؛ إذ تصلح للمدونات، وصفحات التوثيق، والمقالات، بل ولإنشاء صفحات الشابكة نفسها، إذ يمكن تحويلها إلى HTML بيسرٍ وسهولة.

كيف تُكتب الماركدون؟

العناوين

تُكتب العناوين بجعل علامة # قبل النص، وتختلف رتبتها باختلاف عدد العلامات؛ فكلما ازداد العدد نزلت رتبة العنوان.

# عنوان 1
## عنوان 2
### عنوان 3
#### عنوان 4
##### عنوان 5

التوكيد

إن أردتَ توكيد كلمةٍ أو جملة، جعلتَها بين نجمتين *، وإن أردتَ الميلان فبين نجمةٍ واحدة، وقد تجمع بين التوكيد والميلان في موضعٍ واحد. وأما الشطب على الكلام فيكون بعلامتي ~~.

*بسم الله الرحمن الرحيم*
**بسم الله الرحمن الرحيم**
**بسم الله الرحمن *الرحيم***
~~بسم الله الرحمن الرحيم~~

القوائم

تُنشأ القوائم غير المرتبة بجعل شرطة - في أول السطر، ثم فراغٍ فالنص. وأما القوائم المرتبة فتكون بالأرقام.

- السطر الأول
- السطر الثاني
- السطر الثالث
- السطر الرابع

1. السطر الأول
2. السطر الثاني
3. السطر الثالث
4. السطر الرابع

الوَصلات

تُكتب الوصلة بجعل الوصف بين معقوفين []، والرابط بين قوسين ().

[وصف الوصلة](https://motaz.cc)

الصور

والصور كالوصلات، غير أنّك تزيد قبلها علامة التعجب !.

![وصف الصورة](وصلة_الصورة)

الترميز البرمجي

إن أردتَ إدراج كلمةٍ أو سطرٍ يسير من الترميز جعلته بين علامتي `، وأما إن كان المقتبس طويلًا فاجعله بين ثلاثة أسطر من العلامات.

#include <iostream>

int main() {
    // Todo
    return 0;
}

الجداول

تُنشأ الجداول بكتابة رؤوس الأعمدة أولًا، ثم الفصل بينها وبين بقية الصفوف بخطوطٍ من الشرطات.

| الرأس 1 | الرأس 2 | الرأس 3 |
| -------- | -------- | -------- |
| العمود 1 | العمود 2 | العمود 3 |
| العمود 1 | العمود 2 | العمود 3 |

خاتمة

فإن أردتَ الاستزادة والتعمق في الماركدون، فدونك هذه المصادر النافعة:

• https://www.markdownguide.org/
• https://daringfireball.net/projects/markdown/syntax