تمارين Kata في الشبكات بثلاثة مستويات مع الحلول

بقي للأجهزة 32 ناقص 26 أي 6 بتات، فحجم الشبكة 2⁶ = 64 عنواناً، والبايت الأخير في القناع فيه أول بتين فقط مضاءين، أي 128 + 64 = 192، فالقناع 255.255.255.192. والشبكة تبدأ من 192.168.10.0 وتنتهي عند 192.168.10.63، والأول هو عنوان الشبكة والأخير هو عنوان البث، فيبقى 62 عنواناً للأجهزة من .1 إلى .62. وتحققنا من ذلك بالمكتبة ipaddress في Python، وتستطيع تشغيلها على جهازك أو داخل الكلاينت ب docker exec -it kata-client python3، ونفس الجلسة تخدم التمارين 2 و3 و7 و8:

import ipaddress as ip
n = ip.ip_network('192.168.10.0/26')
print(n.netmask, n.network_address, n.broadcast_address, n.num_addresses, n.num_addresses - 2, n[1], n[-2])

والمخرج سوف يكون كما يلي:

255.255.255.192 192.168.10.0 192.168.10.63 64 62 192.168.10.1 192.168.10.62

لاحظ أن ال Router نفسه يأخذ عادة واحداً من الاثنين والستين، فإذا كان لديك 62 سيرفراً بالضبط فأنت تحتاج شبكة أكبر. وطريقة الحساب في RFC 4632 الذي يعرف كتابة CIDR.

للتفصيل: العناوين الخاصة وأقنعة الشبكات في مقال NAT.

القناع /22 يترك 10 بتات للأجهزة، أي 2 بت من البايت الثالث و8 بتات من الرابع، فكل شبكة /22 تأخذ أربع قيم متتالية في البايت الثالث، والقيمة 32 تقبل القسمة على 4، فالشبكة من 10.20.32.0 إلى 10.20.35.255 والقناع 255.255.252.0. وبالتالي 10.20.33.200 و10.20.35.255 داخلها، والعنوانان 10.20.36.5 و10.20.31.250 خارجها، وهؤلاء من يحتاج قاعدة أخرى. والتحقق:

net = ip.ip_network('10.20.32.0/22')
print(net, net.netmask, net[0], net[-1])
for a in ['10.20.33.200', '10.20.35.255', '10.20.36.5', '10.20.31.250']:
    print(a, ip.ip_address(a) in net)

والمخرج سوف يكون كما يلي:

10.20.32.0/22 255.255.252.0 10.20.32.0 10.20.35.255
10.20.33.200 True
10.20.35.255 True
10.20.36.5 False
10.20.31.250 False

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

للتفصيل: العناوين الخاصة في مقال NAT، ومرجع الكتابة RFC 4632.

النطاق 172.16.0.0/12 يمتد من 172.16 إلى 172.31 فقط، لذلك 172.32.5.4 عنوان عام رغم أنه «يشبه» الخاص، وهذا خطأ شائع في قواعد الجدار. والنطاق 100.64.0.0/10 يمتد من 100.64 إلى 100.127، فالعنوان 100.72.3.9 من مساحة CGNAT المشتركة Shared Address Space حسب RFC 6598، و100.128.0.1 عام. والعنوان 169.254.10.20 عنوان محلي على الرابط Link-Local حسب RFC 3927، ويظهر عادة عندما يفشل الجهاز في الحصول على عنوان من DHCP. وتحققنا بالمكتبة نفسها:

cg = ip.ip_network('100.64.0.0/10')
for a in ['10.8.0.1', '172.16.5.4', '172.32.5.4', '192.168.1.10', '100.72.3.9', '100.128.0.1', '169.254.10.20', '8.8.8.8']:
    x = ip.ip_address(a)
    print(f"{a:15} private={x.is_private!s:5} global={x.is_global!s:5} cgnat={x in cg!s:5} link_local={x.is_link_local}")

والمخرج سوف يكون كما يلي:

10.8.0.1        private=True  global=False cgnat=False link_local=False
172.16.5.4      private=True  global=False cgnat=False link_local=False
172.32.5.4      private=False global=True  cgnat=False link_local=False
192.168.1.10    private=True  global=False cgnat=False link_local=False
100.72.3.9      private=False global=False cgnat=True  link_local=False
100.128.0.1     private=False global=True  cgnat=False link_local=False
169.254.10.20   private=True  global=False cgnat=False link_local=True
8.8.8.8         private=False global=True  cgnat=False link_local=False

في المخرج أعلاه لاحظ التالي:

• عنوان CGNAT ليس خاصاً ولا عاماً في نظر المكتبة، فلا هو من RFC 1918 ولا يصل من الإنترنت، وإذا رأيته على واجهة WAN في ال Router الخاص بك فأنت خلف NAT ثان عند المزود، وتوجيه المنافذ عندك لن يكفي.
• المكتبة تعتبر 169.254.10.20 خاصاً لأنها تتبع سجل IANA للعناوين الخاصة الاستخدام وليس RFC 1918 وحده، وهو في الواقع عنوان لا يخرج من الشبكة المحلية أصلاً.

للتفصيل: CGNAT في مقال NAT واكتشاف CGNAT في دليل الاستضافة من إنترنت المنزل.

الحالة NOERROR تعني أن الاسم موجود وأن هناك إجابة، ولو كان الاسم غير موجود لظهرت NXDOMAIN. والسؤال كان عن سجل A للاسم www.shop.lab.test، فأجاب السيرفر بأن هذا الاسم هو سجل CNAME أي اسم بديل يشير إلى shop.lab.test، ثم أضاف من نفسه سجل A للاسم الذي يشير إليه حتى لا تحتاج سؤالاً ثانياً، لذلك يوجد في الإجابة سجلان. والعنوان الذي سوف يتصل به المتصفح هو 10.77.0.10.

والرقم 300 هو مدة البقاء TTL بالثواني، أي أن من استلم هذه الإجابة يحق له أن يحفظها خمس دقائق ويجيب منها دون أن يسأل من جديد، وهذا ما سوف تراه في التمرين 9. والسيرفر الذي أجاب هو 10.77.0.54 على المنفذ 53 عبر UDP، أي الذاكرة المؤقتة وليس السيرفر الذي يحمل السجلات. وفي المختبر أعطانا هذا المخرج الأمر:

docker exec kata-client dig www.shop.lab.test

وإذا أردت السطور المهمة فقط فأضف +noall +answer، وإذا أردت سؤال سيرفر بعينه فاكتبه بعد @، كما سوف نفعل في التمرين 9.

للتفصيل: سجل CNAME والتخزين المؤقت ومدة TTL وأدوات الفحص في مقال DNS.

السطور التي تبدأ ب > هي الطلب: الطريقة GET والمسار / والترويسة Host التي يختار بها Nginx الموقع. والسطور التي تبدأ ب < هي الرد: الحالة 200 OK، والسيرفر nginx/1.29.8، والجسم 57 بايتاً من نوع text/html، وConnection: keep-alive مع السطر الأخير left intact يعنيان أن الاتصال بقي مفتوحاً ليستخدم مرة أخرى. والسطور التي تبدأ ب * تخبرك أن الاسم حل إلى 10.77.0.10 وأن اتصال TCP نجح على المنفذ 80 قبل أن يرسل أي شيء.

وإذا أرسلت البصمة نفسها في If-None-Match فأنت تقول للسيرفر «عندي هذه النسخة، أرسلها فقط إذا تغيرت»، فيرد بالحالة 304 دون جسم:

docker exec kata-client curl -s -o /dev/null -w "%{http_code}\n" -H 'If-None-Match: "6ac5f832-39"' http://shop.lab.test/

والمخرج سوف يكون كما يلي:

304

لاحظ أن البصمة عندك سوف تختلف لأنها مبنية على وقت تعديل الملف وحجمه، فخذها من مخرج curl -v عندك.

للتفصيل: مم يتكون الطلب والرد ورموز 3xx ومنها 304 في مقال HTTP.

شغلنا الخدمات الثلاث في الكلاينت بخادم HTTP الموجود في Python، كل واحدة على عنوان مختلف:

docker exec -d kata-client python3 -m http.server 3000 --bind 127.0.0.1
docker exec -d kata-client python3 -m http.server 9090 --bind 0.0.0.0
docker exec -d kata-client python3 -m http.server 8080 --bind ::
docker exec kata-client ss -tlnp

المنفذ 9090 يستمع على 0.0.0.0 أي كل عناوين IPv4، والمنفذ 8080 يستمع على * أي كل العناوين في IPv4 وIPv6، فكلاهما يصل إليه أي جهاز يرى السيرفر ما لم يمنعه جدار حماية. أما 3000 فيستمع على 127.0.0.1 وحده، فلا يصل إليه إلا برنامج على السيرفر نفسه، وهذا هو الإعداد الصحيح لتطبيق يقف خلف Reverse Proxy. وجربنا ذلك من Container آخر على الشبكة:

for p in 3000 9090 8080; do
  docker exec kata-web sh -c "curl -s -o /dev/null -w 'port $p: %{http_code}\n' --connect-timeout 3 http://10.77.0.100:$p/ || echo 'port $p: exit '\$?"
done
docker exec kata-client curl -s -o /dev/null -w 'from inside, port 3000: %{http_code}\n' http://127.0.0.1:3000/

والمخرج سوف يكون كما يلي:

port 3000: 000
port 3000: exit 7
port 9090: 200
port 8080: 200
from inside, port 3000: 200

والرمز 7 في curl يعني أنه لم يستطع الاتصال. والسطر الأول 127.0.0.11:43973 هو سيرفر ال DNS الداخلي الذي يضعه Docker في كل Container على شبكة خاصة، ولا يظهر له اسم برنامج لأنه ليس عملية داخل ال Container، وتجده موثقاً في توثيق شبكات Docker. وعلى سيرفر Ubuntu عادي سوف ترى في مكانه غالباً 127.0.0.53:53 الخاص ب systemd-resolved. وأعمدة المخرج موثقة في صفحة ss.

للتفصيل: المنافذ المنشورة وغير المنشورة في دليل شبكات Docker، وحالات الوصول الجزئي في دليل التشخيص.

أربع شبكات تساوي 2²، فنأخذ بتين من جزء الأجهزة ويصبح القناع /26، وكل شبكة فيها 64 عنواناً منها 62 للأجهزة، وتبدأ الشبكات عند 0 و64 و128 و192:

for s in ip.ip_network('192.168.50.0/24').subnets(new_prefix=26):
    print(s, s[1], s[-2], s.broadcast_address, s.num_addresses - 2)

والمخرج سوف يكون كما يلي:

192.168.50.0/26 192.168.50.1 192.168.50.62 192.168.50.63 62
192.168.50.64/26 192.168.50.65 192.168.50.126 192.168.50.127 62
192.168.50.128/26 192.168.50.129 192.168.50.190 192.168.50.191 62
192.168.50.192/26 192.168.50.193 192.168.50.254 192.168.50.255 62

وقد يتساءل البعض: لماذا لا نعطي كل فريق ما يكفيه بالضبط، فالضيوف مثلاً يحتاجون 120 والإدارة 10؟ والإجابة أن هذا ممكن بأقنعة مختلفة الطول Variable Length Subnet Mask، فتأخذ الضيوف /25 والبقية /26 و/27، ولكن ابدأ دائماً بالأكبر حتى لا تقع الشبكة الكبيرة في منتصف حدود لا تقبل القسمة على حجمها.

للتفصيل: العناوين الخاصة في مقال NAT وتوثيق ipaddress.

القناع /23 يأخذ قيمتين في البايت الثالث تبدآن من رقم زوجي، فالسيرفر app1 في الشبكة 10.0.0.0/23 أي من 10.0.0.0 إلى 10.0.1.255، بينما app2 وdb1 في 10.0.2.0/23 أي من 10.0.2.0 إلى 10.0.3.255:

for a in ['10.0.1.10/23', '10.0.2.20/23', '10.0.3.30/23']:
    print(a, '->', ip.ip_interface(a).network)

والمخرج سوف يكون كما يلي:

10.0.1.10/23 -> 10.0.0.0/23
10.0.2.20/23 -> 10.0.2.0/23
10.0.3.30/23 -> 10.0.2.0/23

فعندما يريد app1 الوصول إلى 10.0.3.30 يرى أنه خارج شبكته فيبحث عن بوابة ولا يجدها، رغم أن الكابل نفسه يصل إليه. وأقل تغيير هو نقل app1 إلى عنوان داخل 10.0.2.0/23 مثل 10.0.2.10، أو توسيع القناع على الأجهزة الثلاثة إلى /22 فتصبح كلها في 10.0.0.0/22. ولا تقم بتغيير القناع على جهاز واحد فقط، والسبب أن الاتصال يحتاج طرفين، فالرد من db1 سوف يفشل بنفس الطريقة.

للتفصيل: ماذا يفعل ال Router فعلاً في مقال وصول الإنترنت.

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

وفي المختبر أنتجنا هذا المخرج بتغيير السجل في سيرفر kata-dns بعد أن سألنا عنه مرة:

docker exec kata-client dig +noall +answer shop.lab.test
docker rm -f kata-dns
docker run -d --name kata-dns --network kata-net --ip 10.77.0.53 alpine:3.22 sh -c "apk add -q dnsmasq && exec dnsmasq -k --no-resolv --no-hosts --local=/lab.test/ --local-ttl=300 --host-record=shop.lab.test,10.77.0.11 --cname=www.shop.lab.test,shop.lab.test"
docker exec kata-client dig +noall +answer shop.lab.test
docker exec kata-client dig +noall +answer @10.77.0.53 shop.lab.test

والمخرج سوف يكون كما يلي:

shop.lab.test.		286	IN	A	10.77.0.10
shop.lab.test.		262	IN	A	10.77.0.10
shop.lab.test.		300	IN	A	10.77.0.11

وما كان يجب فعله هو أن تخفض TTL إلى 60 أو 300 ثانية قبل النقل بمدة لا تقل عن قيمته القديمة، فإذا كانت يوماً كاملاً فخفضها قبل يوم، ثم تنقل، ثم تبقي السيرفر القديم يعمل حتى تنتهي المدة، ثم ترجع القيمة إلى ما كانت. ولا تقم بإيقاف السيرفر القديم لحظة تغيير السجل، والسبب أن بعض المستخدمين سوف يذهبون إليه حتى تنتهي مدة النسخة المحفوظة عندهم. وأرجع السجل إلى 10.77.0.10 بنفس الأمر قبل أن تكمل بقية التمارين.

للتفصيل: «انتشار» DNS: الحقيقة أنه تخزين مؤقت في مقال DNS، وحالة الاسم الذي لا يحل أو التغيير الذي لم يصل في دليل التشخيص.

الطلب بالطريقة HEAD عبر curl -sI يظهر لك الحالة والترويسات فقط:

docker exec kata-client curl -sI http://shop.lab.test/old-price-list
docker exec kata-client curl -sI http://shop.lab.test/offers
docker exec kata-client curl -sL -o /dev/null -w '%{http_code} %{url_effective} redirects=%{num_redirects}\n' http://shop.lab.test/old-price-list

والمخرج سوف يكون كما يلي:

HTTP/1.1 301 Moved Permanently
Server: nginx/1.29.8
Date: Wed, 07 Oct 2026 07:54:35 GMT
Content-Type: text/html
Content-Length: 169
Location: http://shop.lab.test/price-list
Connection: keep-alive

HTTP/1.1 302 Moved Temporarily
Server: nginx/1.29.8
Date: Wed, 07 Oct 2026 07:54:38 GMT
Content-Type: text/html
Content-Length: 145
Location: http://shop.lab.test/ramadan-offers
Connection: keep-alive

200 http://shop.lab.test/price-list redirects=1

في المخرج أعلاه لاحظ التالي:

• Nginx حول المسار النسبي في return إلى رابط كامل في Location.
• Nginx يكتب للرمز 302 العبارة القديمة Moved Temporarily بينما اسمه في RFC 9110 هو Found، والمهم هو الرقم وليس العبارة.
• الخيار -L جعل curl يتبع التوجيه، فانتهى عند /price-list بالحالة 200 بعد توجيه واحد.

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

للتفصيل: إعادة التوجيه 301 و302 و307 و308 في مقال HTTP.

الأرقام تراكمية بالثواني من لحظة البداية كما في دليل curl، فمدة كل مرحلة هي الفرق بين رقمين:

DNS          namelookup                    0.0012 s  (1.2 ms)
TCP          connect - namelookup          0.0002 s  (0.2 ms)
TLS          appconnect - connect          0.0761 s  (76 ms)
server wait  starttransfer - appconnect    2.0477 s  (2048 ms)
body         total - starttransfer         0.0001 s

فالشبكة كلها أخذت أقل من 80 ملي ثانية، وأكثر من ثانيتين ضاعت بين إرسال الطلب ووصول أول بايت من الرد، أي داخل السيرفر. والطلب يمر عبر Nginx إلى التطبيق، فتبحث في التطبيق وليس في الشبكة، وفي المختبر السبب معروف لأن السكربت report ينام ثانيتين قبل أن يرد. وقارن ذلك بالعنوان السريع:

docker exec kata-client curl -s -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} ttfb=%{time_starttransfer} total=%{time_total} code=%{http_code}\n' http://shop.lab.test/api/orders

والمخرج سوف يكون كما يلي:

dns=0.045843 connect=0.046078 ttfb=0.203511 total=0.207435 code=200

ولاحظ أن ال DNS هنا أخذ 45 ملي ثانية لأن الذاكرة المؤقتة لم تكن تحمل الاسم في تلك اللحظة فسألت السيرفر الآخر، وفي الطلب التالي نزل إلى أقل من 2 ملي ثانية، لذلك لا تحكم من طلب واحد وكرر القياس.

للتفصيل: ال curl -w: خمسة أرقام تقسم الطلب في دليل الطلب البطيء، وأين تذهب المللي ثانية في مقال وصول الإنترنت.

كل أمر curl هو برنامج مستقل يفتح اتصالاً واحداً وينهيه عند الخروج، فهو الطرف الذي يغلق أولاً Active Close، بينما Nginx كان مستعداً لإبقاء الاتصال مفتوحاً، لذلك بقيت الاتصالات العشرون في TIME-WAIT عند الكلاينت ولا يوجد شيء منها عند السيرفر. والأوامر التي أنتجت المخرج:

docker exec kata-client sh -c 'for i in $(seq 1 20); do curl -s -o /dev/null http://shop.lab.test/; done; sleep 1; ss -tan state time-wait | head -4; echo "client TIME-WAIT: $(ss -Htan state time-wait | wc -l)"'
docker exec kata-web sh -c 'echo "server TIME-WAIT: $(netstat -tan | grep -c TIME_WAIT)"'

وفائدة الحالة أن الطرف الذي أغلق ينتظر مدة تساوي ضعف أطول عمر للحزمة 2MSL حسب RFC 9293، حتى لا تصل حزمة متأخرة من هذا الاتصال فتختلط باتصال جديد يستخدم نفس المنفذ، وحتى يعيد إرسال آخر ACK إذا ضاع. وهي لا تستهلك شيئاً يذكر، ولكنها تصبح مشكلة عندما يفتح تطبيقك آلاف الاتصالات القصيرة في الثانية إلى نفس السيرفر، كتطبيق ينشئ كلاينت HTTP جديداً لكل طلب، فتنفد المنافذ المحلية Ephemeral Ports وتظهر أخطاء مثل Cannot assign requested address. والحل ليس تعديل إعدادات النواة Kernel، وإنما إعادة استخدام الاتصال عبر مجمع اتصالات Connection Pool، وأعدنا التجربة بعد أن انتهت الحالات السابقة، ولكن بأمر curl واحد يطلب الرابط عشرين مرة، والمتغير num_connects يطبع عدد الاتصالات الجديدة التي فتحها لكل طلب:

docker exec kata-client sh -c 'curl -s $(for i in $(seq 1 20); do printf -- "-o /dev/null "; done) "http://shop.lab.test/?[1-20]" -w "%{num_connects} "; sleep 1; echo; echo "client TIME-WAIT: $(ss -Htan state time-wait | wc -l)"'

والمخرج سوف يكون كما يلي:

1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
client TIME-WAIT: 1

فالطلب الأول فتح اتصالاً والتسعة عشر الباقية استخدمته، وبقي اتصال واحد في TIME-WAIT بدل عشرين.

للتفصيل: إعادة استخدام الاتصال في مقال HTTP، وإعادة استخدام اتصالات HTTP في مقال تجميع الاتصالات، وصفحة tcp في Linux.

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

docker network create --subnet 192.168.77.0/24 -o com.docker.network.bridge.enable_ip_masquerade=false kata-lan
docker network create --subnet 203.0.113.0/24 -o com.docker.network.bridge.enable_ip_masquerade=false kata-wan
docker run -d --name kata-router --cap-add NET_ADMIN --sysctl net.ipv4.ip_forward=1 alpine:3.22 sleep infinity
docker run -d --name kata-homesrv --cap-add NET_ADMIN nginx:1.29-alpine
docker run -d --name kata-ext --cap-add NET_ADMIN nginx:1.29-alpine
docker exec kata-router apk add -q iptables conntrack-tools iproute2
for c in router homesrv ext; do docker network disconnect bridge kata-$c; done
docker network connect --ip 192.168.77.2 kata-lan kata-router
docker network connect --ip 203.0.113.2 kata-wan kata-router
docker network connect --ip 192.168.77.20 kata-lan kata-homesrv
docker network connect --ip 203.0.113.50 kata-wan kata-ext
docker exec kata-homesrv ip route replace default via 192.168.77.2
docker exec kata-router ip route del default
docker exec kata-ext ip route del default
docker exec kata-router sh -c 'iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 8443 -j DNAT --to-destination 192.168.77.20:80; iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE'

ثم جربنا الاتجاهين وقرأنا جدول تتبع الاتصالات Connection Tracking في ال Router وسجل Nginx في كل طرف:

docker exec kata-ext curl -s -m 4 -o /dev/null -w '%{http_code}\n' http://203.0.113.2:8443/
docker exec kata-router conntrack -L -p tcp | grep 8443
docker logs kata-homesrv 2>/dev/null | grep 'GET /' | tail -1
docker exec kata-homesrv curl -s -m 4 -o /dev/null -w '%{http_code}\n' http://203.0.113.50/
docker exec kata-router conntrack -L -p tcp | grep 'src=192.168.77.20 dst=203.0.113.50'
docker logs kata-ext 2>/dev/null | grep 'GET /' | tail -1

والمخرج سوف يكون كما يلي:

200
tcp      6 118 TIME_WAIT src=203.0.113.50 dst=203.0.113.2 sport=42598 dport=8443 src=192.168.77.20 dst=203.0.113.50 sport=80 dport=42598 [ASSURED] mark=0 use=1
203.0.113.50 - - [07/Oct/2026:08:13:41 +0000] "GET / HTTP/1.1" 200 896 "-" "curl/8.17.0" "-"
200
tcp      6 118 TIME_WAIT src=192.168.77.20 dst=203.0.113.50 sport=43846 dport=80 src=203.0.113.50 dst=203.0.113.2 sport=80 dport=43846 [ASSURED] mark=0 use=1
203.0.113.2 - - [07/Oct/2026:08:13:46 +0000] "GET / HTTP/1.1" 200 896 "-" "curl/8.17.0" "-"

في المخرج أعلاه لاحظ التالي:

• (1) سجل السيرفر المنزلي يكتب 203.0.113.50، أي العنوان الحقيقي للعميل، لأن DNAT غير الوجهة فقط. وفي سطر conntrack الأول ترى الاتجاهين: الطلب كما وصل إلى 203.0.113.2:8443، والرد المتوقع من 192.168.77.20:80.
• (2) الجهاز الخارجي يرى 203.0.113.2، أي عنوان ال Router العام، لأن MASQUERADE يغير المصدر عند الخروج من eth1، والعنوان الخاص لا يظهر خارج البيت أبداً.

(3) وعندما غيرنا البوابة الافتراضية للسيرفر المنزلي إلى 192.168.77.1 فشل الطلب نفسه:

docker exec kata-homesrv ip route replace default via 192.168.77.1
docker exec kata-ext curl -sS -m 4 -o /dev/null -w '%{http_code}\n' http://203.0.113.2:8443/
docker exec kata-router conntrack -L -p tcp | grep SYN
docker exec kata-homesrv ip route replace default via 192.168.77.2

والمخرج سوف يكون كما يلي:

curl: (28) Connection timed out after 4001 milliseconds
000
tcp      6 112 SYN_SENT src=203.0.113.50 dst=203.0.113.2 sport=36704 dport=8443 [UNREPLIED] src=192.168.77.20 dst=203.0.113.50 sport=80 dport=36704 mark=0 use=1

والحالة [UNREPLIED] تقول إن الطلب ترجم ووصل، ولكن الرد لم يمر بال Router، لأن السيرفر أرسله إلى بوابة أخرى بعنوانه الخاص، فوصل إلى الجهاز الخارجي من عنوان لم يكلمه فرماه. وهذا سبب شائع لعبارة «وجهت المنفذ ولا يصل أحد».

(4) العنوان 100.72.3.9 من مساحة CGNAT كما في التمرين 3، فال Router عندك خلف NAT آخر عند المزود، والطلبات من الإنترنت لا تصل إلى ال Router أصلاً، لذلك لا يكفي توجيه المنفذ، والحل أن تطلب عنواناً عاماً من المزود أو تستخدم نفقاً Tunnel أو IPv6.

للتفصيل: توجيه المنافذ DNAT ووجهت المنفذ ولا يصل أحد في مقال NAT، وكل الطرق الممكنة في دليل الاستضافة من المنزل، وتوثيق DNAT وMASQUERADE.

الاسم @ عليه SOA وسجلا NS وسجل MX، وهذه إجبارية للنطاق الرئيسي Root Domain، وحسب RFC 1034 وRFC 2181 إذا كان للاسم سجل CNAME فلا يجوز أن يكون له أي سجل آخر، والسبب أن CNAME يقول «كل ما تسأل عنه لهذا الاسم موجود عند الاسم الآخر»، فلو سمح به هنا لضاع سجل MX والبريد معه. وتحققنا بالأداة named-checkzone من BIND بعد أن حفظنا الملف أعلاه باسم shop.example.zone ونسخناه إلى الكلاينت:

docker exec -i kata-client sh -c 'cat > /tmp/shop.example.zone' < shop.example.zone
docker exec kata-client named-checkzone shop.example /tmp/shop.example.zone; echo "exit=$?"

والمخرج سوف يكون كما يلي:

dns_master_load: /tmp/shop.example.zone:6: shop.example: CNAME and other data
dns_master_load: /tmp/shop.example.zone:6: shop.example: CNAME and other data
dns_master_load: /tmp/shop.example.zone:6: shop.example: CNAME and other data
zone shop.example/IN: loading from master file /tmp/shop.example.zone failed: CNAME and other data
zone shop.example/IN: not loaded due to errors.
exit=1

والحلول الصحيحة ثلاثة: أن تضع سجل A بالعنوان الذي تعطيك إياه المنصة للنطاق الرئيسي، أو أن تستخدم ميزة ALIAS أو CNAME Flattening إذا كان مزود ال DNS يدعمها، وهي ليست سجلاً في المعيار وإنما يحل المزود الاسم بنفسه ويجيب بسجل A، أو أن تجعل النطاق الرئيسي يعيد التوجيه إلى www وتترك CNAME على www وحده. وعندما استبدلنا السطر السادس بسجل A قبل السيرفر الملف:

@      IN A     203.0.113.80

zone shop.example/IN: loaded serial 2026100701
OK
exit=0

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

للتفصيل: سجل CNAME وأخطاء شائعة في مقال DNS.

الشهادة تنتهي في Jan 5 07:44:16 2027 GMT كما في السطر v، أي بعد 90 يوماً من إصدارها. والسيرفر أرسل شهادة واحدة فقط برقم 0، وهي شهادة الموقع التي أصدرتها الجهة الوسيطة Lab Kata Intermediate CA، والأداة لا تملك إلا الشهادة الرئيسية، فلا تستطيع أن تبني السلسلة من شهادة الموقع إلى الرئيسية لأن الحلقة التي في الوسط ناقصة، وهذا معنى الخطأ 20 unable to get local issuer certificate ثم 21. والمتصفح يعمل غالباً لأنه حفظ الشهادة الوسيطة من موقع آخر زاره، أو لأنه يجلبها بنفسه، بينما الأدوات وتطبيقات الموبايل لا تفعل ذلك، والحل الوحيد الصحيح أن يرسل السيرفر السلسلة كاملة، أي الملف fullchain وليس الشهادة وحدها.

والمنفذ 8443 في المختبر يستخدم fullchain.crt، فقارن:

docker exec kata-client sh -c 'echo | openssl s_client -connect shop.lab.test:8443 -servername shop.lab.test -CAfile /certs/root.crt 2>/dev/null | sed -n "/Certificate chain/,/^---/p;/Verify return code/p"'

والمخرج سوف يكون كما يلي:

Certificate chain
 0 s:CN=shop.lab.test
   i:O=Lab Kata, CN=Lab Kata Intermediate CA
   a:PKEY: EC, (prime256v1); sigalg: ecdsa-with-SHA256
   v:NotBefore: Oct  7 07:44:16 2026 GMT; NotAfter: Jan  5 07:44:16 2027 GMT
 1 s:O=Lab Kata, CN=Lab Kata Intermediate CA
   i:O=Lab Kata, CN=Lab Kata Root CA
   a:PKEY: EC, (prime256v1); sigalg: ecdsa-with-SHA256
   v:NotBefore: Oct  7 07:44:15 2026 GMT; NotAfter: Oct  6 07:44:15 2031 GMT
---
Verify return code: 0 (ok)

والأسماء التي تغطيها الشهادة في الامتداد Subject Alternative Name وليس في CN، ومعها التواريخ وسؤال «هل تنتهي خلال 30 يوماً؟» الذي تضعه في المراقبة:

docker exec kata-client sh -c 'echo | openssl s_client -connect shop.lab.test:443 -servername shop.lab.test 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName'
docker exec kata-client sh -c 'echo | openssl s_client -connect shop.lab.test:443 -servername shop.lab.test 2>/dev/null | openssl x509 -noout -checkend 2592000; echo exit=$?'
docker exec kata-client sh -c 'echo | openssl s_client -connect shop.lab.test:443 -servername shop.lab.test 2>/dev/null | openssl x509 -noout -checkend 8640000; echo exit=$?'

والمخرج سوف يكون كما يلي:

subject=CN=shop.lab.test
issuer=O=Lab Kata, CN=Lab Kata Intermediate CA
notBefore=Oct  7 07:44:16 2026 GMT
notAfter=Jan  5 07:44:16 2027 GMT
X509v3 Subject Alternative Name:
    DNS:shop.lab.test, DNS:www.shop.lab.test
Certificate will not expire
exit=0
Certificate will expire
exit=1

والرقم 2592000 هو 30 يوماً بالثواني فالشهادة لن تنتهي خلالها، و8640000 هو 100 يوم فهي سوف تنتهي خلالها. وأرقام أخطاء التحقق موثقة في خيارات التحقق في OpenSSL.

للتفصيل: لماذا يجب أن يرسل السيرفر الشهادة الوسيطة ومتى تنتهي الشهادة في مقال الشهادات.

أنتجنا الحالات الثلاث في المختبر وقسنا ما يراه المستخدم:

docker exec kata-app pkill httpd
docker exec kata-client curl -s -o /dev/null -w 'code=%{http_code} total=%{time_total}\n' http://shop.lab.test/api/orders
docker exec kata-app httpd -p 8080 -h /www
docker exec kata-client curl -s -o /dev/null -w 'code=%{http_code} total=%{time_total}\n' http://shop.lab.test/api/export
docker stop kata-app
docker exec kata-client curl -s -o /dev/null -w 'code=%{http_code} total=%{time_total}\n' http://shop.lab.test/api/orders
docker start kata-app

والمخرج سوف يكون كما يلي:

code=502 total=0.003244
code=504 total=3.004797
code=504 total=2.010858

في المخرج أعلاه لاحظ التالي:

• (A) التطبيق متوقف ولكن الجهاز موجود، فنظام التشغيل رد فوراً برفض الاتصال Connection Refused، وNginx أرجع 502 Bad Gateway خلال 3 ملي ثانية. وهذا ما تراه عندما ينهار التطبيق أو يعاد تشغيله أو يستمع على منفذ آخر.
• (B) التطبيق قبل الاتصال ولكنه لم يرسل ترويسات الرد خلال proxy_read_timeout، فأرجع Nginx 504 Gateway Time-out بعد 3 ثوان بالضبط، والتطبيق في الحقيقة ما زال يعمل على الطلب، وهذا هو الاستعلام البطيء أو الخدمة الخارجية التي لا ترد.
• (C) هنا الحالة المفاجئة: أوقفنا ال Container كله فاختفى العنوان من الشبكة، فلم يرد أحد لا بالقبول ولا بالرفض، وانتهت مهلة الاتصال proxy_connect_timeout بعد ثانيتين فأرجع Nginx الرمز 504 وليس 502. فالقاعدة الصحيحة ليست «502 يعني التطبيق متوقف»، وإنما: 502 جواب سيئ أو رفض سريع، و504 لا جواب خلال المهلة، واقرأ السطر في error.log لتعرف أي مرحلة.

وتعريف الرمزين في RFC 9110، والمهلتان في توثيق ngx_http_proxy_module.

للتفصيل: من أين يأتي 502 و503 و504 في مقال HTTP، وحالة الخطأ 502 أو 504 في دليل التشخيص، ومن الذي أغلق الطلب في دليل الطلب البطيء.

الصورة التالية تبين السلم الذي تمشي عليه، وكل رسالة في الصورة خرجت فعلاً من المختبر:

والأوامر التي أنتجت الرسائل في المختبر:

docker exec kata-client curl -sS http://shpo.lab.test/
docker exec kata-client curl -sS http://shop.lab.test:8081/
docker exec kata-client curl -sS --connect-timeout 3 http://10.77.0.99/
docker exec kata-client curl -sS --cacert /certs/root.crt https://shop.lab.test/
docker exec kata-client curl -sS --cacert /certs/root.crt https://10.77.0.10:8443/
docker exec kata-client curl -sv http://shop.lab.test:8081/ 2>&1 | grep -iE "trying|refused|failed"

والسطر الأخير يظهر السبب الحقيقي خلف الرسالة 2، لأن curl 8.14 يكتب «Could not connect to server» في الرسالة المختصرة:

*   Trying 10.77.0.10:8081...
* connect to 10.77.0.10 port 8081 from 10.77.0.100 port 55696 failed: Connection refused
* Failed to connect to shop.lab.test port 8081 after 1 ms: Could not connect to server

وبالترتيب:

1. الرمز 6 من درجة DNS: الاسم مكتوب خطأ shpo، وتتحقق ب dig shpo.lab.test فترى status: NXDOMAIN. وإذا كان الاسم صحيحاً فابحث عن سجل لم يضف أو تغيير لم يصل كما في التمرين 9.
2. الرمز 7 من درجة TCP مع رفض فوري خلال ملي ثوان: الجهاز موجود ولا يستمع أحد على المنفذ 8081، وتتحقق ب ss -tlnp على السيرفر كما في التمرين 6، والسبب الأرجح منفذ خاطئ أو خدمة متوقفة.
3. الرمز 28 من درجة TCP أيضاً ولكن دون أي رد: العنوان لا يجيب أصلاً، إما لأنه لا يوجد جهاز عليه، أو لأن جدار حماية يرمي الحزم بصمت، أو لأن الرد يذهب في طريق آخر كما في التمرين 13. وتتحقق ب nc -zv -w 3 من داخل الشبكة ومن خارجها.
4. الرمز 60 مع unable to get local issuer certificate من درجة TLS: السلسلة ناقصة كما في التمرين 15، أو الشهادة من جهة لا يثق بها الكلاينت، وتتحقق ب openssl s_client.
5. الرمز 60 مع no alternative certificate subject name matches من درجة TLS: المستخدم فتح الموقع بالعنوان 10.77.0.10 أو باسم لا تغطيه الشهادة، والأسماء المقبولة في SAN فقط.
6. 504 من درجة HTTP: كل ما تحت هذه الدرجة يعمل، وال Reverse Proxy لم يصله رد من التطبيق في المهلة، فاقرأ error.log كما في التمرين 16.

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

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