الفصل : 7
الجزء : 1
العنوان : الشبكات في Windows Server 2022
كما ناقشنا حتى الآن في هذا الكتاب، تعتبر الخوادم الجذوع لشبكاتنا. إنها العمود الفقري للبنية التحتية التي تمكننا من إنجاز العمل. إذا كانت الخوادم هي الجذوع، فإن الشبكات نفسها يجب أن تكون الجذور. شبكتك هي المنصة التي تدعم بنية الشركة؛ فهي تشكل القنوات التي تستخدمها جميع الأجهزة داخل شركتك للتواصل مع بعضها البعض. تقليديًا، كان هناك مديرو خوادم ومديرو شبكات في صناعة تكنولوجيا المعلومات، أدوار منفصلة، وفي العديد من الأماكن لا يزال هذا هو الحال. المدير الذي يعمل بشكل رئيسي على الخوادم لا يملك عادة الوقت الكافي لدعم البنية التحتية للشبكة في مؤسسة من أي حجم، والعكس صحيح أيضًا. عادة ما يلتزم مديرو الشبكات بمعداتهم وأدوات الإدارة الخاصة بهم ولا يهتمون بالغوص بعمق في عالم Windows Server. ومع ذلك، فإن العديد منا يعملون في شركات صغيرة حيث يجب ارتداء العديد من القبعات. في بعض الأيام، يجلس قبعتي المدير الخادم والمدير الشبكي فوق بعضها البعض، لذلك يجب أن نفهم على الأقل الأساسيات في الشبكات والأدوات التي يمكننا استخدامها لاستكشاف اتصالات لا تعمل.
بالإضافة إلى ذلك، يجلب Windows Server 2022 منظورًا جديدًا للشبكات: الافتراضية لشبكاتك. سيكون هناك دائمًا بعض الشبه بالشبكة الفيزيائية، باستخدام مفاتيح (Switches) وموجهات (Routers) فيزيائية لتحريك الحزم بين الغرف والمباني المختلفة. لكننا الآن ندمج أيضًا فكرة الشبكة المعرفة بالبرمجيات software-defined networking (SDN) في خوادم Windows لدينا، مما يمنحنا القدرة على افتراض بعض من تلك التكوينات. ليس فقط التكوين نفسه؛ نحن أيضًا نقوم فعليًا بإفتراض حركة المرور الشبكية وبناء شبكاتنا من داخل وحدة تحكم الخادم، بدلاً من استخدام واجهات سطر الأوامر لتكوين موجهاتنا ومفاتيحنا، وهو ما كان مطلوبًا دائمًا في الماضي.
انتظر لحظة، أعتقد أنني أسبق نفسي. أولاً، دعونا نتحدث عن بعض الأشياء الجديدة والمفيدة داخل Windows Server 2022 التي تتعلق بالعمل مع الشبكات الفيزيائية (أو أي شبكات) لأن هذه ستكون مهمة لأي مدير في عالم الشبكات اليوم. لاحقًا، سنأخذ بضع لحظات لاستكشاف هذه الفكرة الجديدة عن افتراض الشبكة.
المواضيع التي نخطط لمناقشتها في هذا الفصل هي:
- مقدمة إلى IPv6
- صندوق أدوات الشبكة الخاص بك
- بناء جدول توجيه
- تجميع NIC
- الشبكة المعرفة بالبرمجيات (Software-defined networking)
مقدمة إلى IPv6
مرحبًا بك في الجانب المظلم! للأسف، هذا هو كيف يفكر الكثير من الناس في IPv6 في الوقت الحالي. بينما IPv6 ليست شيئًا جديدًا بأي حال من الأحوال، إلا أنها لا تزال شيئًا لم ينشر تقريبًا في الشبكات. أثناء العمل مع مئات الشركات المختلفة حول العالم في السنوات القليلة الماضية، صادفت فقط منظمتين كانتا تشغلان IPv6 على شبكتهما الإنتاجية بأكملها، ولم تكن واحدة منهما حتى IPv6 أصلي حقيقي. بدلاً من ذلك، كانوا يستخدمون تكنولوجيا النفق، تسمى ISATAP، عبر شبكتهم بالكامل لجعل جميع الخوادم والعملاء يتحدثون مع بعضهم البعض باستخدام حزم IPv6، لكن هذه الحزم كانت لا تزال تمر عبر شبكة فيزيائية IPv4.
لا تفهموني خطأ؛ وجدت الكثير من الحالات التي كانت الشركات تلعب فيها مع IPv6 وكان لديها بعض منها مكونة في جزء معزول من شبكاتها، لكن استخدامه للشبكة الإنتاجية الكاملة؟ معظمنا لم يكن مستعدًا لذلك التغيير الكبير بعد. لماذا من الصعب جدًا إدخال IPv6 في مكانه؟ لأننا استخدمنا IPv4 منذ بداية الزمن تقريبًا، إنه ما نعرفه ونفهمه جميعًا، وليس هناك حاجة كبيرة للانتقال إلى IPv6 داخل شبكاتنا.
انتظر لحظة؛ اعتقدت أنه كان هناك بعض الفزع الكبير حول نفاد عناوين IPv4. نعم، هذا صحيح بالنسبة لعناوين IP على الإنترنت العام، لكن هذا ليس له علاقة بشبكاتنا الداخلية. ترى، حتى لو نفدت عناوين IPv4 العامة غدًا، فإن الشبكات الداخلية لشركاتنا لن تتأثر. يمكننا الاستمرار في تشغيل IPv4 داخل الشبكة لفترة طويلة قادمة، ربما إلى الأبد ودائمًا، طالما نحن مرتاحون لاستخدام تقنيات NAT لترجمة الحركة إلى IPv4 كما تدخل شبكتنا من الإنترنت. لقد استخدمنا جميعًا NAT في شكل أو آخر تقريبًا لطالما كان IPv4 موجودًا، لذلك من الواضح أنه شيء الناس مرتاحون معه للغاية.
أريد أن أوضح: أنا لا أحاول إقناعك بأن التمسك بـ IPv4 هو طريق المستقبل. أنا فقط أطرح الحقيقة أنه بالنسبة لمعظم المنظمات على مدى السنوات القليلة القادمة، سيكون هذا ببساطة هو الحقيقة. السبب في أنني أريد مناقشة IPv6 هنا هو أنه، في النهاية، ستضطر إلى التعامل معه. وبمجرد أن تفعل، ستتحمس بشأنه! هناك بعض الفوائد الضخمة التي يتمتع بها IPv6 على IPv4، وهي العدد الهائل من عناوين IP التي يمكنك احتواؤها داخل شبكة واحدة. فرق الشبكات في الشركات حول العالم تكافح كل يوم مع الحاجة إلى بناء المزيد والمزيد من شبكات IPv4 وربطها معًا. فكر في الأمر: هناك العديد من الشركات الآن التي لديها عدد موظفين يزيد عن 10,000. البعض لديهم أعداد كثيرة أكثر من ذلك بكثير. في عالم اليوم، يحتاج الجميع تقريبًا إلى الوصول المستمر إلى بياناتهم. البيانات هي العملة الجديدة. معظم المستخدمين لديهم الآن على الأقل جهازين فيزيائيين يستخدمونها للعمل، وأحيانًا أكثر من ذلك: كمبيوتر محمول وجهاز لوحي، كمبيوتر محمول وهاتف ذكي، أو سطح مكتب وكمبيوتر محمول وجهاز لوحي وهاتف ذكي؛ تحصل على الفكرة. في عالم IPv4، حيث تتعامل مع نطاقات عناوين IP صغيرة نسبيًا، عليك أن تكون مبدعًا للغاية في إنشاء الشبكات الفرعية (Subnets) لاستيعاب جميع هذه الأجهزة الفيزيائية. كل جهاز يحتاج إلى عنوان IP فريد للتواصل على الشبكة.
الميزة الأكبر لـ IPv6 هي أنها تحل جميع هذه المشاكل فورًا وبشكل افتراضي، من خلال توفير القدرة على امتلاك عدد هائل من عناوين IP داخل شبكة واحدة. كم عدد العناوين أكثر؟ التالية هي بعض بيانات المقارنة لإعطائك بعض المنظور:
- عنوان IPv4 هو عنوان بطول 32 بت يبدو هكذا: 192.168.1.5
- عنوان IPv6 هو عنوان بطول 128 بت يبدو هكذا:
2001:AABB:CCDD:AB00:0123:4567:8901:ABCD
كما ترى، عنوان IPv4 أقصر بكثير، مما يعني بوضوح أن هناك احتمالات أقل لعناوين IP فريدة. ما لا تراه هو كم أطول بكثير عناوين IPv6 حقًا. هذه الأمثلة تصور عناوين IPv4 وIPv6 كما اعتدنا على رؤيتها، في أشكالها النهائية. في الواقع، يتم عرض عنوان IPv4 في شكل عشري، وIPv6 في شكل سداسي عشري. يتم عرض عناوين IPv6 واستخدامها عبر السداسي عشري حتى يتم ضغط العناوين بقدر الإمكان. في الواقع، إذا كنت تبحث تحت الغطاء، فإن عنوان IPv6 في شكله الأصلي بطول 128 بت قد يبدو شيئًا مثل هذا (وبالفعل، هذا هو كيف يبدو داخل الحزمة الفعلية):
00010000010000010000110110011000000000000000000100000000000000000001000000000000000000000000100000000000000000000000000000000001
هذا مجموعة مذهلة من الأرقام، ولكن ليس شيئًا قابلًا للاستخدام أو مريحًا للعين البشرية. لذلك، بدلاً من عرض البتات، ماذا عن عرض عنوان IPv6 في الشكل العشري بنفس الطريقة التي تم عرض عناوين IPv4 دائمًا؟ في هذه الحالة، قد يبدو عنوان IPv6 شيئًا مثل هذا:
192.16.1.2.34.0.0.1.0.0.0.0.0.0.0.1
الآن نفهم تمامًا لماذا يتم استخدام وعرض عناوين IPv6 دائمًا في الشكل السداسي عشري؛ العناوين طويلة حتى في هذا الشكل المضغوط!
عندما نقوم بإعداد شبكات IPv4، فإن التقسيم الشبكي مهم للغاية لأنه هو ما يمكننا من امتلاك أكثر من مجموعة واحدة من عناوين IP داخل نفس الشبكة. في الشكل الأساسي جدًا للشبكات، حيث تقوم بإعداد بعض عناوين IP وتدير شبكة فرعية /24 (قناع الشبكة الفرعية 255.255.255.0)، وهو شائع جدًا في الشبكات الصغيرة مثل داخل منزل أو مكتب أعمال صغير، تكون محدودًا بـ 254 عنوان IP فريدًا. مؤلم! بعض الشركات لديها الآلاف من الخوادم المختلفة، دون احتساب جميع أجهزة العميل التي تحتاج أيضًا إلى الاتصال بالشبكة. لحسن الحظ، يمكننا بناء العديد من الشبكات الفرعية المختلفة داخل شبكة IPv4 واحدة من أجل زيادة نطاق عناوين IP القابلة للاستخدام لدينا، ولكن هذا يتطلب تخطيطًا دقيقًا ورعاية. في بعض الحالات، ما زال ليس كافيًا لتلبية احتياجاتنا.
الشبكات الفرعية لا تزال موجودة في IPv6، ولكنها لا تعمل تمامًا بنفس الطريقة. بدلاً من ذلك، تحتوي جميع عناوين IPv6 على أقسام مدمجة محددة مسبقًا تستخدم لتحديد مدى الحزمة. يمكنك تقسيمها حسب حاجتك لتجهيز جميع أجهزة الشبكة المختلفة، ولكنك لن تتعثر أبدًا لأن هناك كمية غير محدودة تقريبًا من عناوين IP لتعمل معها.
عندما نتحدث عن عناوين IPv6، يبدو أن السماء هي الحد الأقصى. إذا قمت بحساب جميع عناوين IPv6 الفريدة المتاحة في الفضاء 128-بت، ستجد أن هناك أكثر من 340 تريليون، تريليون، تريليون عنوان يمكن إنشاؤها. هذا هو الرقم الذي يتم الترويج له حول عدد العناوين المتاحة على الإنترنت باستخدام IPv6، ولكن ماذا يعني ذلك لشبكاتنا الداخلية؟
لمناقشة عدد العناوين التي يمكن أن تكون لدينا داخل شبكة داخلية نموذجية تعمل على IPv6، دعونا نتراجع أولاً وننظر إلى العنوان نفسه. العنوان الذي أظهرته سابقًا هو مجرد مثال قمت بإنشائه، ولكننا سنفكك أجزائه هنا:
2001:AABB:CCDD:AB00:0123:4567:8901:ABCD
بالمقارنة مع 192.168.1.5، يبدو هذا العنوان ضخمًا. ذلك لأننا عمومًا غير معتادين على التعامل مع الصيغة السداسية العشرية؛ إنها مجرد طريقة مختلفة للنظر إلى البيانات. كما ذكرنا، هذا عنوان 128-بت. يتم تقسيمه إلى 8 أقسام مختلفة، كل قسم مفصول بنقطتين ويتألف من 16 بت. النصف الأول من العنوان (الأول 64 بت) هو معلومات التوجيه، والنصف الأخير 64 بت هو معرف الجهاز الفريد على الشبكة. ضمن الجزء الأول، لدينا مكونان مختلفان. الأول 48 بت (3 مجموعات من السداسي العشري) هي بادئة تنظيمية ستكون نفسها على جميع أجهزتنا في الشبكة. ثم المجموعة الرابعة من المعلومات، التالية 16 بت، يمكن أن تكون معرف الشبكة الفرعية (Subnet ID). هذا يعطينا المرونة في وجود العديد من الشبكات الفرعية المختلفة إذا رغبنا في المستقبل باستخدام أرقام متعددة هنا كمعرف الشبكة الفرعية. بعد تخصيص النصف الأول من العنوان، لدينا الآن النصف الأخير للعمل معه، الأخير 64 بت. يمكننا تركها لمعرفات الأجهزة. هذا الجزء من العنوان سيكون مختلفًا لكل جهاز على الشبكة ويحدد عناوين IPv6 الثابتة الفريدة التي سيتم استخدامها للاتصال. دعونا نقسم مثال العنوان إلى الأجزاء التالية:
- العنوان الكامل:
2001:AABB:CCDD:AB00:0123:4567:8901:ABCD
- البادئة التنظيمية:
2001:AABB:CCDD
- معرف الشبكة الفرعية:
AB00
- معرف الجهاز:هو معرف جهاز فريد واحد
0123:4567:8901:ABCD
كم عدد الأجهزة التي يمكن أن تكون لدينا في شبكتنا باستخدام نظام عناوين كهذا؟ حسنًا، حتى في مثالنا، حيث خصصنا قسم واحد 16-بت فقط للشبكات الفرعية و64 بت لعناوين IP الفعلية، سيتيح لنا ذلك القدرة على امتلاك أكثر من 65,000 شبكة فرعية وكوينتيليون من معرفات الأجهزة الفريدة في نطاق IP لدينا. هذا مذهل، أليس كذلك؟
إذا تمسكنا بهذا واستخدمنا شبكة فرعية واحدة فقط لاحتواء جميع أجهزتنا، فسيكون النصف الأول من عناويننا دائمًا هو نفسه، مما يجعل هذه العناوين الطويلة أسهل في التذكر والتعامل معها. من المدهش كم ستعتاد بسرعة على رؤية هذه الأرقام السداسية العشرية الكبيرة في بيئتك، ولكن حتى إذا بدأت في التعرف عليها، فإنك ربما لن تقفز بسرعة إلى الخوادم أو أجهزة الكمبيوتر في شبكتك باستخدام عناوين IP الثابتة بعد الآن. أعلم أن الكثير منا لا يزال لديه عادة القول: "أحتاج إلى الدخول إلى خادم الويب الخاص بي؛ سأقوم بالاتصال عبر RDP إلى 192.168.1.5." مجرد الوقت الذي يستغرقه كتابة هذه العناوين IPv6، حتى إذا كنت تتذكرها، عادة ما يكون غير مجدي. IPv6 سيجلب معه اعتمادًا أكبر على DNS لجعله أكثر قابلية للاستخدام.
الآن بعد أن فهمنا ما هي الأقسام التي سيتم استخدامها لأي أغراض، كيف يمكننا تعيين أرقام معرف الجهاز الفردية لجميع أجهزة الكمبيوتر والخوادم والأجهزة الأخرى في شبكتنا؟ يمكنك البدء من الرقم 1 والصعود من هناك. فكرة أخرى هي حساب عناوين IPv4 القديمة إلى سداسي عشري واستخدام هذا كالأخير 32 بت من العنوان—افتح Windows Calculator على جهاز الكمبيوتر الخاص بك، انزل القائمة، وغيّرها إلى وضع المبرمج. هذه أداة سريعة وسهلة يمكنك استخدامها لتحويل العشري إلى سداسي عشري، والعكس بالعكس. دعونا نأخذ مثال خادم الويب الخاص بي الذي يعمل على 192.168.1.5. أريد تنفيذ IPv6 داخل شبكتي، وأريد أن تعكس عناوين IPv6 الخاصة بخادمي العنوان IPv4 الأصلي في قسم معرف الجهاز من العنوان الجديد. في حاسبتي، إذا كتبت 192 ثم ضغطت على HEX، سيظهر لي السداسي العشري المقابل للعشري 192، كما هو موضح في الشكل 7.1:
إذا قمنا بذلك مع كل واحد من الأكتات في عنوان IPv4 الخاص بنا، سنرى ما يلي:
192 = C0
168 = A8
1 = 01
5 = 05
لذا، عنوان 192.168.1.5 يتحول إلى C0A8:0105. يمكنني الآن استخدام ذلك مع البادئة التنظيمية ومعرف الشبكة الفرعية لإنشاء عنوان IPv6 ثابت لخادم الويب الخاص بي:
2001:AABB:CCDD:0001:0000:0000:C0A8:0105
ستلاحظ في عنوان IPv6 السابق أنني أدخلت السداسي العشري لمعرف الجهاز في النهاية، لكنني أجريت بعض التغييرات الأخرى أيضًا. بما أننا نترك آخر 64 بت متاحًا لمعرف الجهاز، لكن عنوان IPv4 القديم الخاص بي يستخدم فقط 32 بت، يتبقى لي 32 بت في المنتصف. سيكون من الغريب أن يكون لدينا بيانات هناك لا تعني شيئًا لنا، لذلك سنجعلها كلها أصفار لتبسيط نظام العناوين. بالإضافة إلى ذلك، قمت أيضًا بضبط معرف الشبكة الفرعية إلى الرقم 1، لأن هذه هي الشبكة الفرعية الأولى في شبكتي.
بدأت عناويننا الجديدة تبدو أكثر نظافة وتوضح المزيد من المعنى. الآن بعد أن رأينا هذا العنوان الجديد لخادم الويب الخاص بنا، أرى أن هناك بعض المهام الإضافية لتنظيف العنوان لجعله يبدو أفضل. في الوقت الحالي، العنوان المذكور أعلاه دقيق بنسبة 100%. يمكنني إدخال هذا العنوان في خصائص NIC لخادم الويب الخاص بي وسيعمل. ومع ذلك، هناك الكثير من الأصفار في عنواني، ولا أحتاج إلى الاحتفاظ بها جميعًا. في أي وقت تكون لديك أصفار غير ضرورية ضمن قسم 16-بت تسبق الرقم الفعلي، يمكن ببساطة إزالتها. على سبيل المثال، معرف الشبكة الفرعية والأول 32 بت من معرف الجهاز لدينا العديد من الأصفار غير الضرورية، لذلك يمكنني تبسيط العنوان إلى:
2001:AABB:CCDD:1:0:0:C0A8:0105
ثم، لأخذها خطوة أخرى، في أي وقت تكون لديك أقسام 16-بت كاملة تتألف بالكامل من الأصفار، يمكن تجميعها بالكامل في نقطتين مزدوجتين. لذا، أول 32 بت من معرف الجهاز التي تتكون كلها من أصفار، يمكنني استبدالها بـ :: . التالية هي العنوان الكامل والعنوان المجمع. تبدو هذه الأرقام مختلفة جدًا. عنواني المجمع أسهل بكثير للعين، لكن من الناحية التكنولوجية، هما نفس الرقم:
2001:AABB:CCDD:0001:0000:0000:C0A8:0105
2001:AABB:CCDD:1::C0A8:0105
في الواقع، إذا قمت بإعداد مختبر أو أردت اختبار IPv6 بسرعة، يمكنك استخدام عناوين بسيطة مثل المثال التالي. العنوانان الذين سأعرضهما هنا هما بالضبط نفس الشيء:
2001:0000:0000:0000:0000:0000:0000:0001
2001::1
من المهم ملاحظة أنه يمكنك استخدام نقطتين مزدوجتين مرة واحدة فقط داخل عنوان IP. إذا كان لديك مكانان حيث يكون ذلك ممكنًا داخل نفس العنوان، يمكنك فقط تنفيذها في واحد من تلك الأماكن، وستحتاج إلى توضيح الأصفار في المكان الآخر. على سبيل المثال، تغيير
2001:AABB:0000:0000:0001:0000:0000:0123
الى
2001:AABB::1::123
سيسبب مشكلة لجهاز الكمبيوتر الخاص بك، لأنه لن يعرف ماذا يفعل مع النقطتين المزدوجتين الثانية.
بالمعلومات المقدمة هنا، يجب أن تكون قادرًا على تكوين فهمك الخاص لـ IPv6 والبدء في إصدار بعض عناوين IPv6 لأجهزة الكمبيوتر أو الخوادم في شبكتك. هناك الكثير لتتعلمه في هذا الموضوع بحيث يمكن كتابة كتاب كامل عنه، وفي الواقع، هناك العديد من الكتب للاختيار من بينها. أجهزة الكمبيوتر والخوادم الحديثة من Windows مجهزة جيدًا لبدء استخدام IPv6 الآن داخل خصائص NIC ولكن تذكر أن أنواع الأجهزة الأخرى على شبكتك، خاصة القديمة منها، قد لا تكون على علم بـ IPv6 ولا تحتوي حتى على حقل لإدخال عنوان IPv6. يمكن أن تكون الأجهزة القديمة عاملاً حاسمًا أو عقبة رئيسية في رحلتك نحو IPv6.
صندوق أدوات الشبكات الخاص بك (Your networking toolbox)
سواء كنت مسؤول خادم أو مسؤول شبكة أو مزيج من الاثنين، هناك عدد من الأدوات المفيدة لاختبار ومراقبة اتصالات الشبكة في عالم Windows Server. بعض هذه الأدوات مدمجة في نظام التشغيل ويمكن استخدامها من Command Prompt أو PowerShell، وبعضها الآخر واجهات رسومية أكثر توسعًا تتطلب التثبيت قبل التشغيل. الأدوات المدمجة في Windows والتي سننظر فيها هي:
- ping
- tracert
- pathping
- Test-Connection
- telnet
- Test-NetConnection
- netstat
كل هذه الأدوات مجانية ومضمنة في النظام، لذا ليس لديك عذر لتأجيل التعرف على هذه الأدوات المفيدة.
اداة ping
حتى المحترفين الجدد في تكنولوجيا المعلومات عادةً ما يكونون على دراية بهذه الأداة. ping هي أمر يمكنك استخدامه من Command Prompt أو PowerShell، ويتم استخدامه ببساطة لاستعلام عن اسم DNS و/أو عنوان IP لمعرفة ما إذا كان يستجيب. ping كان دائمًا أداة للاعتماد عليها لاختبار الاتصال بالشبكة بين جهازين على الشبكة. من جهاز Windows 10 الخاص بي على الشبكة المحلية (LAN)، يمكنني فتح موجه الأوامر واستخدام ping <IP_ADDRESS>. بدلاً من ذلك، نظرًا لأنني أستخدم DNS في بيئتي، والذي سيحل الأسماء إلى عناوين IP، يمكنني أيضًا استخدام ping <SERVERNAME>، كما هو موضح في الشكل 7.2. يمكنك رؤية أن الخادم الخاص بي يرد على الـ ping، مما يخبرني بأنه متصل ويستجيب.
حركة مرور ping تُعرف تقنيًا بأنها حركة مرور ICMP. هذا مهم لأن بروتوكول ICMP يتم حظره افتراضيًا بشكل متزايد هذه الأيام، مع تشغيل جدران الحماية افتراضيًا في العديد من أنظمتنا وأجهزتنا. تاريخيًا، كان ping دائمًا أداة يمكننا الاعتماد عليها لإخبارنا بدرجة كبيرة من اليقين ما إذا كان الاتصال يتدفق بين جهازين، لكن هذا لم يعد الحال. إذا قمت ببناء جهاز Windows جديد وقمت بتوصيله بشبكتك، فقد يتواصل هذا الكمبيوتر مع الإنترنت وجميع الخوادم على شبكتك بشكل جيد، ولكن إذا حاولت ping هذا الكمبيوتر الجديد من جهاز آخر على شبكتك، فمن المحتمل أن يفشل الـ ping. لماذا يحدث ذلك؟ لأن Windows لديه بعض التدابير الأمنية المدمجة افتراضيًا، بما في ذلك حظر حركة مرور ICMP في جدار حماية Windows Defender. في هذه الحالة، ستحتاج إما إلى إيقاف جدار حماية Windows أو توفير قاعدة وصول تسمح بحركة مرور ICMP. بمجرد تفعيل قاعدة كهذه، ستبدأ استجابات ping من هذا الكمبيوتر الجديد. تذكر دائمًا عند بناء أنظمة أو خوادم جديدة في شبكتك أن ping ليس دائمًا الأداة الأكثر موثوقية للاعتماد عليها في عالم الشبكات اليوم.
من السهل السماح باستجابات ICMP عن طريق إضافة قاعدة في جدار حماية Windows Defender مع الأمان المتقدم، ومع ذلك، لا يزال لا ترغب في تذكر القيام بذلك يدويًا على كل نظام جديد تقوم بإدخاله في الشبكة. لحسن الحظ، تعرف بالفعل كيفية استخدام Group Policy لبناء GPO ودفعها إلى جميع الأجهزة على شبكتك، ونعم، يمكنك تمامًا وضع قواعد جدار الحماية داخل ذلك GPO. في الواقع، سنفعل ذلك بالضبط في الفصل 9، Hardening and Security. هذه طريقة شائعة للسماح أو حظر ICMP في جميع أنحاء المؤسسة عن طريق إصدار قاعدة جدار حماية عبر Group Policy.
اداة tracert
ال tracert، والذي يُنطق Trace Route، هي أداة تُستخدم لتتبع حزمة الشبكة أثناء عبورها شبكتك. ما تفعله بالفعل هو مراقبة جميع الأماكن التي تصطدم بها الحزمة قبل وصولها إلى وجهتها. هذه الاصطدامات في الطريق التي يجب على حزمة الشبكة المرور بها تُسمى hops. يُظهر لك tracert جميع الـ hops التي تمر بها حركة المرور الخاصة بك أثناء انتقالها نحو خادم الوجهة أو أي شيء تحاول الاتصال به. شبكتي الاختبارية مسطحة ومملة للغاية، لذا لن يُظهر لنا إجراء tracert هناك الكثير. ومع ذلك، إذا فتحت موجه PowerShell من جهاز متصل بالإنترنت واستخدمت tracert لخدمة ويب، مثل Bing، نحصل على بعض النتائج المثيرة للاهتمام:
إذا استخدمت tracert لكنك غير مهتم برؤية كل معلومات DNS المقدمة في المخرجات، استخدم tracert -d للتركيز فقط على عناوين IP.
يمكن أن تكون هذه المعلومات مفيدة للغاية عند محاولة تشخيص اتصال لا يعمل. إذا كانت حركة المرور الخاصة بك تمر عبر عدة hops، مثل أجهزة التوجيه وجدران الحماية، قبل وصولها إلى الوجهة، يمكن أن يكون tracert ضروريًا لمعرفة أين في سلسلة الاتصال تحدث المشكلة. بالنظر إلى لقطة الشاشة السابقة التي تُظهر tracert ناجحًا إلى Bing، دعونا الآن نرى كيف يبدو الأمر عندما تكون هناك مشكلة. سأقوم بفصل مودم الإنترنت الخاص بي وأقوم بتشغيل tracert www.bing.com مرة أخرى، والآن يمكننا أن نرى أنني لا أزال قادرًا على التواصل مع جهاز التوجيه المحلي الخاص بي، ولكن ليس بعده:
من المهم ملاحظة أن tracert يعتمد على ICMP لتلقي استجابات من أجهزة الشبكة التي يتصل بها. إذا كانت هذه الأجهزة لا تسمح باستجابة ICMP، فلن تتلقى معلومات من تلك hops.
اداة Pathping
يعتبر الأمر tracert مفيداً ويبدو أنه المعيار الفعلي لتتبع حزم البيانات حول شبكتك، ولكن الأمر التالي أكثر قوة في رأيي. يقوم الأمر pathping بشكل أساسي بنفس وظيفة tracert، ولكنه يوفر معلومات إضافية حاسمة. في معظم الأحيان، مع أي من هذين الأمرين، تكون مهتماً فقط بمعرفة المكان في سلسلة النقاط الذي يحدث فيه الانقطاع. ولكن غالباً، عندما أقوم بإعداد الخوادم لأغراض الشبكات، أتعامل مع خوادم وأجهزة تحتوي على العديد من بطاقات الشبكة (NICs). عند التعامل مع عدة NICs في النظام، تكون جداول التوجيه المحلية مهمة مثل أجهزة التوجيه والمبدلات الخارجية، وغالباً ما أرغب في التحقق من مسار حزمة البيانات لمعرفة أي NIC محلي يمر من خلالها. هنا يأتي دور pathping ليكون أكثر قوة من tracert. أول قطعة من المعلومات التي يعرضها tracert هي النقطة الأولى بعيداً عن الخادم المحلي الذي تتنقل عبره. ولكن pathping يظهر لك أيضاً أي واجهة شبكة محلية تخرج منها حزم البيانات.
مثال على الاستخدام:
عادةً ما أقوم بإعداد خوادم الوصول عن بعد مع عدة NICs، وأثناء هذه العملية، أنشئ العديد من المسارات على الخادم المحلي حتى يعرف أي حركة مرور يجب أن يتم إرسالها في أي اتجاه، مثل ما إذا كانت حركة المرور يجب أن تخرج من الـ NIC الداخلي أو الخارجي. بعد إكمال جميع بيانات التوجيه الخاصة بنا لـ NIC الداخلي، نختبرها عن طريق ping لخادم داخل الشبكة. ربما يفشل هذا الـ ping، ولا نعرف السبب. يمكنني محاولة استخدام الأمر tracert، لكنه لن يوفر لي أي شيء مفيد لأنه ببساطة لا يمكنه رؤية النقطة الأولى؛ بل فقط ينتهي بوقت انتهاء المهلة. ومع ذلك، إذا استخدمت الأمر pathping بدلاً من ذلك، ستظل النقطة الأولى تنتهي بوقت انتهاء المهلة، ولكن يمكنني الآن رؤية أن حركة المرور الخاصة بي تحاول الخروج من NIC الخارجي. أوه! لابد أننا قمنا بتكوين شيء بشكل غير صحيح مع مسارنا الثابت على هذا الخادم. لذا، أعرف أنني بحاجة إلى حذف هذا المسار وإعادة إنشائه لجعل هذه الحركة تمر عبر الـ NIC الداخلي بدلاً من ذلك.
في المثال التالي، يمكنك رؤية موجه PowerShell من نفس الكمبيوتر الذي استخدمته في لقطة شاشة tracert. يمكنك أن ترى أن الأمر pathping يظهر لي عنوان IP المحلي على جهاز الكمبيوتر المحمول الخاص بي حيث تحاول حركة المرور مغادرة النظام، في حين أن الأمر tracert لم يظهر هذه المعلومات.
اداة Test-Connection
الأوامر التي ناقشناها حتى الآن يمكن تشغيلها من Command Prompt أو PowerShell، ولكن الآن حان الوقت للغوص في أمر أحدث يمكن تشغيله فقط من PowerShell: أمر يسمى Test-Connection؛ إنه يشبه إلى حد ما الـ ping لكن بقدرات معززة. إذا فتحنا موجه PowerShell في المختبر ونفذنا أمر Test-Connection WEB1، سنرى نتائج مشابهة لما نحصل عليه مع ping العادي، لكن المعلومات تكون مرتبة بطريقة أعتقد أنها أسهل قليلاً على العين. هناك أيضاً عمود بيانات غير متوقع هنا يسمى Source:
هذا مثير للاهتمام. كنت مسجلاً الدخول إلى خادم DC1 عندما نفذت هذا الأمر، لذا كان جهاز المصدر لهذا الأمر هو DC1. لكن هل هذا يعني أنني يمكنني تعديل جهاز المصدر لأمر Test-Connection؟ نعم، هذا بالضبط ما يعنيه.
كما هو الحال مع كل شيء في إدارة Windows Server 2022، الحاجة إلى تسجيل الدخول إلى خادم محلي منفصلة. بالنسبة لأمر Test-Connection، هذا يعني أنه يمكنك فتح موجه PowerShell في أي مكان على شبكتك واختبار الاتصالات بين نقطتي نهاية مختلفتين، حتى إذا لم تكن مسجلاً الدخول إلى أي منهما. دعونا نختبر ذلك.
ما زلت مسجلاً الدخول إلى خادم DC1، ولكن سأستخدم أمر Test-Connection لاختبار الاتصالات بين عدد من خوادمي في الشبكة. يمكنك أن ترى أنه ليس فقط يمكن تحديد جهاز مصدر غير الذي تكون مسجلاً الدخول إليه، بل يمكنك أيضاً أخذ خطوة إضافية وتحديد مصادر متعددة ووجهات متعددة مع هذا الأمر القوي. لذا، إذا أردت اختبار الاتصالات من عدة أجهزة مصدر إلى عدة وجهات، يمكن القيام بذلك بسهولة باستخدام الأمر التالي:
Test-Connection -Source DC1, DC2 -ComputerName WEB1, BACK1
يمكنك أن ترى في الصورة أن لدي إحصائيات ping من DC1 و DC2 إلى كل من الخوادم WEB1 و BACK1 في شبكتي. يعد Test-Connection أداة مراقبة قوية:
هناك وظيفة مفيدة أخرى يجب الإشارة إليها وهي أنه يمكنك تنظيف ناتج الأمر بسهولة باستخدام مفتاح -Quiet. بإضافة -Quiet إلى أمر Test-Connection، يتم تبسيط الناتج ويعرض لك ببساطة True أو False فقط للإشارة إلى ما إذا كانت الاتصال ناجحاً بدلاً من عرض كل حزمة ICMP التي تم إرسالها. للأسف، لا يمكنك دمج كل من مفتاح -Source ومفتاح -Quiet، ولكن إذا استخدمت Test-Connection من جهاز المصدر الأصلي الذي تكون مسجلاً الدخول إليه، مثلما يفعل معظمنا، فإن مفتاح -Quiet يعمل بشكل رائع. في معظم الأحيان، كل ما نهتم به هو نعم أو لا فيما إذا كانت هذه الاتصالات تعمل، ولا نرغب بالضرورة في رؤية جميع المحاولات الأربع. باستخدام -Quiet، نحصل على ذلك بالضبط:
Test-Connection -Quiet -ComputerName WEB1, BACK1, DC2, CA1
إذا كنت سأستخدم Test-Connection بالطريقة التقليدية لمحاولة الاتصال بجميع الخوادم في شبكتي، سيكون الناتج طويلاً جداً. ولكن باستخدام مفتاح -Quiet، أحصل على True أو False بسيطة لكل خادم فردي فيما إذا كان يمكن الاتصال به.
اداة Telnet
يوفر telnet قدراً كبيراً من قدرات الإدارة عن بعد؛ حيث يتيح بشكل أساسي القدرة على إنشاء اتصال بين جهازين للتحكم في الجهاز البعيد عبر اتصال terminal افتراضي. من المدهش أننا لسنا هنا لمناقشة أي من الوظائف الفعلية التي يوفرها telnet، لأنه بالنسبة للشبكات، أجد أنه مفيد للغاية كأداة بسيطة لاختبار الاتصال، دون الحاجة إلى معرفة أي شيء عن وظائف telnet بحد ذاتها.
عندما ناقشنا ping، تحدثنا عن عيوب ICMP: فهو يتم حظره بسهولة، وأصبح من الشائع في الشبكات اليوم عدم نجاح pings. هذا أمر مؤسف لأن ping كان دائماً الشكل الأكثر شيوعاً لاختبار الاتصال بالشبكة، ولكن الحقيقة هي أنه إذا جعل ping حياتنا أسهل، فإنه يجعل حياة المخترقين أيضاً أسهل. إذا لم نتمكن من الاعتماد على ping لإخبارنا بشكل قاطع ما إذا كان بإمكاننا الاتصال بنظام بعيد، فما الذي يمكننا استخدامه بدلاً من ذلك؟ حالة أخرى أراها غالباً هي أن الخادم نفسه قد يستجيب بشكل صحيح، ولكن خدمة معينة تعمل على ذلك الخادم لديها مشكلة ولا تستجيب. قد يُظهر ping بسيط أن الخادم متصل بالإنترنت، ولكنه لا يمكنه إخبارنا بأي شيء عن الخدمة بالتحديد. باستخدام أوامر Telnet Client، يمكننا بسهولة استعلام خادم عن بعد. والأهم من ذلك، يمكننا اختيار استعلام خدمة معينة على ذلك الخادم للتأكد من أنها تستمع كما ينبغي.
دعني أعطيك مثالاً أستخدمه طوال الوقت. غالباً ما أقوم بإعداد خوادم ويب جديدة تواجه الإنترنت. بعد تثبيت خادم ويب جديد، من المنطقي أنني سأرغب في اختبار الوصول إليه من الإنترنت للتأكد من أنه يستجيب، أليس كذلك؟ ولكن ربما الموقع نفسه ليس متصلاً بعد وغير جاهز للاستخدام، لذا لا أستطيع تصفحه باستخدام Edge أو أي متصفح آخر. من المحتمل جداً أننا قمنا بتعطيل pings على هذا الخادم أو على مستوى جدار الحماية لأن حظر ICMP عبر الإنترنت شائع جداً لتقليل المخاطر الأمنية على الويب. لذا، فإن خادمي الجديد يعمل، ونعتقد أننا قمنا بإعداد الشبكة بشكل صحيح، ولكن لا يمكنني اختبار الاتصال بخادمي الجديد باستخدام ping لأنه، حسب التصميم، يفشل في الرد. ماذا يمكنني استخدام للاختبار في هذه الحالة؟ telnet. بإصدار أمر telnet بسيط، يمكنني إخبار جهازي باستعلام منفذ معين على خادم الويب الجديد الخاص بي ومعرفة ما إذا كان يتصل بذلك المنفذ. القيام بذلك ينشئ اتصال TCP socket مع المنفذ على ذلك الخادم، وهو يشبه كثيراً حركة المرور الحقيقية للمستخدم مقارنةً بـ ping.
إذا نجح أمر telnet في الاتصال، فأنت تعرف أن حركة المرور الخاصة بك تصل إلى الخادم، وخدمة الخادم التي تعمل على المنفذ الذي استعلمنا عنه تبدو وكأنها تستجيب بشكل صحيح.
إمكانية استخدام telnet ليست مثبتة بشكل افتراضي في Windows Server 2022 أو أي نظام تشغيل Windows آخر، لذا نحتاج أولاً إلى الدخول إلى Server Manager ثم Add Roles and Features لتثبيت الميزة المسماة Telnet Client:
تحتاج فقط إلى تثبيت Telnet Client على الجهاز الذي تريد القيام بالاختبار من خلاله. لا تحتاج إلى فعل أي شيء على الخادم البعيد الذي تتصل به.
الآن بعد تثبيت ميزة Telnet Client، يمكننا استخدامها من Command Prompt أو PowerShell للقيام بالعمل من خلال محاولة إنشاء اتصالات socket من جهازنا إلى الخدمة البعيدة. كل ما نحتاجه هو إخبارها باسم الخادم والمنفذ الذي نريد استعلامه. بعد ذلك، سيقوم telnet ببساطة بالاتصال أو انتهاء المهلة، وبناءً على تلك النتيجة، يمكننا رؤية ما إذا كانت تلك الخدمة المعينة على الخادم تستجيب. دعونا نجرب ذلك مع خادم الويب الخاص بنا. في مثالنا، قمت بإيقاف تشغيل الموقع داخل IIS، لذا نحن الآن في موقف يكون فيه الخادم متصلاً بالإنترنت ولكن الموقع ميت. إذا قمت بإجراء ping إلى WEB1، يمكنني أن أرى أنه يستجيب بسعادة. يمكنك أن ترى أين يمكن أن تظهر أدوات مراقبة الخادم التي تعتمد على ICMP إيجابيات كاذبة، مما يشير إلى أن الخادم متصل بالإنترنت ويعمل حتى وإن كان موقعنا غير متاح. أسفل ping الناجح، يمكنك أن ترى أنني حاولت أيضاً استعلام المنفذ 80 على خادم WEB1. الأمر الذي استخدمته لهذا كان telnet web1 80. انتهت المهلة. هذا يظهر لنا أن الموقع الذي يعمل على المنفذ 80 لا يستجيب:
إذا قمت بتشغيل الموقع مرة أخرى، يمكننا تجربة telnet web1 80 مرة أخرى، وهذه المرة، لا أحصل على رسالة انتهاء المهلة. هذه المرة، يقوم موجه PowerShell بمسح نفسه ويجلس في انتظار المؤشر الوامض في الأعلى. بينما لا يخبرني "نعم، لقد اتصلت!" فإن هذا المؤشر الوامض يشير إلى أن اتصال socket ناجح قد تم إلى المنفذ 80 على خادم الويب الخاص بي، مما يشير إلى أن الموقع متصل ويستجيب:
بعد إنشاء اتصال telnet socket ناجح، قد تتساءل عن كيفية العودة إلى واجهة PowerShell العادية. اضغط على مفاتيح Ctrl + ] معاً (المفتاح الثاني هو مفتاح القوس المغلق، عادةً بجوار مفتاح الشرطة المائلة العكسية على لوحة المفاتيح)، اكتب كلمة quit، ثم اضغط على Enter. يجب أن يعيدك هذا إلى الموجه العادي. أو ببساطة أغلق موجه PowerShell وافتح واحداً جديداً.
اداة Test-NetConnection
إذا كان هناك مكافئ ومحسن لأمر ping في PowerShell يسمى Test-Connection، فهل يحتوي PowerShell أيضاً على أداة محسنة تعمل بشكل مشابه لـ telnet لاختبار اتصالات socket بالموارد؟ بالتأكيد. Test-NetConnection هي طريقة أخرى لاستعلام منافذ أو خدمات معينة على نظام بعيد، والناتج المعروض يكون أكثر ودية من telnet.
دعونا نستعرض نفس الاختبارات، مرة أخرى باستعلام المنفذ 80 على WEB1. يمكنك أن ترى في لقطة الشاشة التالية أنني قمت بتنفيذ الأمر مرتين. في المرة الأولى كان الموقع على WEB1 معطلاً، وفشل الاتصال بالمنفذ 80. في المرة الثانية، قمت بإعادة تمكين الموقع، والآن أرى اتصالاً ناجحاً:
Test-NetConnection WEB1 -Port 80
تتبع الحزم مع Wireshark
في النهاية، قد تحتاج إلى النظر بشكل أعمق في حزم البيانات الخاصة بشبكتك. الآن ندخل في مجال يمكن أن يكون فريق الشبكة الخاص بك متورطاً فيه، ولكن إذا كنت على دراية بهذه الأدوات، فقد تتمكن من حل المشكلة قبل الحاجة إلى طلب المساعدة. استخدام أدوات سطر الأوامر للتحقق من حالة الخوادم والخدمات مفيد للغاية، ولكن في بعض الأحيان قد لا يكون ذلك كافياً. على سبيل المثال، لديك تطبيق عميل لا يتصل بخادم التطبيق، ولكنك لا تعرف السبب. الأدوات مثل ping وحتى telnet قد تتمكن من الاتصال بنجاح، مما يشير إلى أن التوجيه الشبكي مضبوط بشكل صحيح، ومع ذلك يفشل التطبيق في الاتصال عند فتحه. إذا لم تساعدك سجلات الأحداث الخاصة بالتطبيق في استكشاف ما يحدث، فقد ترغب في النظر بشكل أعمق داخل حزم الشبكة التي يحاول التطبيق إرسالها إلى الخادم.
هنا يأتي دور تطبيق Wireshark. كانت Microsoft تقدم وتدعم بعض الأدوات المطورة ذاتياً التي تخدم وظائف مماثلة، مثل NetMon و Message Analyzer، ولكن كلاهما تم إيقاف دعمهما رسمياً الآن. ربما لأن Wireshark رائع ومجاني! تلتقط هذه الأداة حركة المرور الشبكية أثناء خروجها من النظام أو وصولها إليه، وتلتقط المعلومات الموجودة داخل الحزم بحيث يمكنك إلقاء نظرة أعمق على ما يحدث. في مثالنا عن تطبيق لا يمكنه الاتصال، يمكنك تشغيل Wireshark على جهاز العميل لمراقبة حركة المرور الصادرة، وأيضاً على خادم التطبيق لمراقبة حركة المرور الواردة من العميل.
هناك الكثير من الوظائف داخل Wireshark، وليس لدينا مساحة لتغطية كل شيء هنا، لذا سأتركك مع رابط لتنزيل هذه الأداة حتى تتمكن من البدء في اختبارها بنفسك:
https://www.wireshark.org/download.html.
اداة TCPView
الأدوات التي ناقشناها حتى الآن رائعة ويمكن استخدامها يومياً لفحص الموارد الفردية التي تريد اختبارها، ولكن في بعض الأحيان، تكون هناك مواقف تحتاج فيها إلى التراجع ومعرفة ما الذي تبحث عنه في المقام الأول. ربما تعمل مع تطبيق على جهاز كمبيوتر ولا تعرف أي خادم يتصل به. أو ربما تشك في أن الجهاز يحتوي على فيروس ويحاول الاتصال بجهة معينة على الإنترنت، وتود تحديد الموقع الذي يحاول الاتصال به أو العملية التي تجري الاتصال. في هذه الحالات، سيكون من المفيد إذا كانت هناك أداة يمكنك تشغيلها على الكمبيوتر المحلي تعرض لك جميع تدفقات حركة المرور النشطة على هذا الكمبيوتر أو الخادم بوضوح واختصار. هذا هو بالضبط ما يقوم به TCPView. ال TCPView هي أداة أنشأتها Sysinternals؛ قد تكون سمعت عن بعض أدواتهم الأخرى، مثل ProcMon و FileMon. تشغيل TCPView على جهاز يعرض جميع اتصالات TCP وUDP النشطة التي تحدث على ذلك الكمبيوتر في الوقت الفعلي. أيضاً من المهم أنه لا تحتاج إلى تثبيت أي شيء لتشغيل TCPView؛ فهو ملف قابل للتنفيذ مستقل، مما يجعله سهل الاستخدام للغاية وإزالته من الجهاز عندما تنتهي منه.
يمكنك تنزيل TCPView من:
https://technet.microsoft.com/en-us/sysinternals/tcpview.aspx.
ببساطة انسخ الملف إلى الكمبيوتر أو الخادم الذي تريد مراقبته وانقر عليه نقرًا مزدوجًا. تظهر واجهة TCPView في الشكل 7.13 وهي تعمل على جهاز الكمبيوتر المحلي الخاص بي، وتعرض جميع الاتصالات التي يجريها Windows وتطبيقاتي حالياً. يمكنك إيقاف هذا الإخراج لإلقاء نظرة أقرب، ويمكنك أيضاً تعيين عوامل تصفية لتقليص البيانات والعثور على ما تبحث عنه حقاً. تقوم عوامل التصفية بالتخلص من الضوضاء، بحيث يمكنك النظر بشكل أدق إلى وجهة معينة أو معرف عملية محددة:
اداة netstat
بالنسبة لأي شخص قد لا يكون من محبي تنزيل وتشغيل ملف تنفيذي، أو فقط لأي شخص يبحث عن وظائف مماثلة عبر أمر Microsoft المدمج، فإن netstat هو أداة سطر أوامر كانت موجودة منذ زمن طويل وتعرض معلومات مشابهة (وإن لم تكن بنفس الفائدة) لتلك الخاصة بـ TCPView. يعرض netstat أيضاً معلومات اتصال لكل منفذ ولكل عملية على ما يحدث على الجهاز الذي تقوم بتشغيل الأمر عليه. هناك مفاتيح متعددة يمكن استخدامها للتلاعب بمخرجات أمر netstat أو تحسينها؛ إذا فتحت Command Prompt واستخدمت netstat /?، فسيتم تقديم قائمة كاملة بالمفاتيح الاختيارية ووصفها.
الطريقة المفضلة لدي لاستخدام netstat هي بإضافة الخيار –ano. افتح Command Prompt على أي جهاز كمبيوتر أو خادم، وألقِ نظرة على مخرجات netstat –ano، كما هو موضح في لقطة الشاشة التالية.
بعد تشغيل الأمر، قم بالتمرير إلى أعلى المخرجات، وألقِ نظرة على جميع تلك الاتصالات التي تعرض عنوان Local Address بقيمة 0.0.0.0. هذه هي المنافذ المختلفة التي يستخدمها الخادم حالياً للاستماع إلى الاتصالات الواردة. أستخدم هذه المخرجات دائماً عند إلغاء خوادم قديمة لأنك غالباً ما يمكنك معرفة ما يفعله الخادم من المنافذ التي يستخدمها. في لقطة الشاشة الخاصة بي أعلاه، يمكنك أن ترى بسرعة أن هذا الخادم يستمع على المنافذ 443 و445، مما يشير على الأرجح إلى أنه يُستخدم كخادم ويب يشغل اتصالات HTTPS وخدمات الملفات عبر SMB. على الجانب الأيمن من المخرجات، الظاهر هنا بسبب استخدامي الخيار -o، يمكنك أيضاً رؤية معرّفات العمليات (PIDs) التي تملك المنافذ المستخدمة.
النهاية
نكون هنا انتهينا من الجزء 1 من الفصل 7 تماما من شهادة MCSA المقدمة من Microsoft الأن نغوص في الأعماق
و لا بد وانت تقرا ان تكون مركز جيدا لكل معلومة ومعك ورقة وقلم , لانك بالتاكيد ستحتاجها
واذا واجهتك اي مشكلة في الفهم او ما شابه , يمكنك على الفور الذهاب الى المجتمع الخاص بنا في Telegram للمناقشة والتواصل معنا من هنا
او اذا واجهتك مشكلة في الموقع او تريد اجابة سريعة يمكنك الذهاب الى اخر صفحة في الموقع ستجد صفحة اتصل بنا موجودة يمكنك ارسالة لنا مشكلتك , وسيتم الرد عليها بسرعة جدا ان شاء الله
ويمكنك الأنضمام الى المجتمع Hidden Lock بالكامل مع جميع قنواته للأستفادة في اخر الأخبار في عالم التقنية وايضا الكتب بالمجان والكورسات والمقالات من خلال الرابط التالي لمجموعة القنوات من هنا
يمكنك ايضا متابعتنا في منصات X او Twitter سابقا , لمشاهدة الاخبار والمقالات السريعة والمهمة من
وفقط كان معكم Sparrow اتمنى ان تدعوا لي وتتذكروني في الخير دوما
