البحث في الموقع

تحدثنا في الجزء السابق عن أهمية إعادة توجيه العناوين القديمة للصفحات إلى عناوينها الجديدة، وسنكمل شرح كيفية فعل ذلك في ووردبريس في هذا الدرس. أولًا: نقل موقع ووردبريس قديم إلى مضيفٍ جديد هذه الحالة غير معقدة أبدًا، فلو كنتَ تنقل موقع ووردبريس إلى مضيفٍ جديد دون تغيير بنية الروابط الدائمة لصفحات الموقع، فلا توجد اختلافات في الروابط الدائمة مما لا يستدعي استخدام إعادة توجيه عبر الرمز 301. وهذا بسبب امتلاك الموقع لنفس الصفحات التي كانت فيه بنفس روابطها الدائمة، وذلك من وجه نظر Google، فلو كان يتوقع وجود إحدى الصفحات في الرابط example.com/great-optimized-page فسيجد نفس الصفحة بنفس المحتوى بعد نقل الموقع إلى المضيف الجديد، وكل ما اختلف هو أنَّ الخادوم الذي كان مسؤولًا عن إيصال الصفحة إلى العميل قد تغيّر. لن تحتاج إلى إجراء الكثير من العمليات للحفاظ على تقييم SEO عندما تنقل موقع ووردبريس من مضيفٍ لآخر مع الإبقاء على بنية الروابط الدائمة نفسها في أغلبية الحالات، لكن ما يزال عليك أن تنتبه إلى أمرين مهمين ألا وهما: سرعة الموقع والانتقال إلى خادومٍ يستعمل تشفير SSL. التأكد من أداء وسرعة الموقع أوّل عنصر يمكن أن يؤثر في تقييم SEO عند نقل موقع ووردبريس من مضيفٍ إلى آخر هو سرعة الموقع، إذ يُكافِئ Google المواقع السريعة، لذا احرص على نقل عملائك إلى بيئةٍ أسرع وليس إلى بيئةٍ أبطأ، وابذل جهدك لكي تتفادى حدوث أيّة مشاكل في الأداء والتي قد تحدث عند الانتقال إلى مضيفٍ آخر. أداة PageSpeed Insights من Google هي أداةٌ رائعةً لاستكشاف المشاكل المتعلقة بالأداء وتحسين سرعة الموقع. أنصحك أيضًا بالتواصل مع فريق الدعم الفني لشركة الاستضافة وتتأكد من ضَبطِ كلَّ شيءٍ ضبطًا صحيحًا، فاطلب منهم مثلًا التحقق أنَّ التخزين المؤقت لصفحات الموقع يعمل عملًا سليمًا. فلو انتقلتَ مثلًا إلى شركة الاستضافة SiteGround، فعليك أن تُفعِّل ميزات التخزين المؤقت يدويًا، وربما ترغب بتعطيل بعض إضافات التخزين المؤقت مثل W3 Total Cache، لكي لا تتكرر النسخ المؤقتة في الخادوم. قد تستصعب فعل ما سبق ذكره، لذا حاول التواصل مع فريق الدعم التقني لشركة الاستضافة ليساعدك في الأمر. الجوانب التقنية الأخرى الخاصة بضبط الخادوم، مثل استخدام آخر إصدار من PHP وتفعيل شيءٍ يسمى php-fpm (والذي لا أتظاهر بفهم الغاية منه)، يمكن أن تؤثر في أداء موقعك تأثيرًا كبيرًا، لذا إذا أشارت أداة PageSpeed Insights إلى أداءٍ ضعيفٍ أو متوسط (خصوصًا إذا كان وقت استجابة الخادوم كبيرًا) فلا تخجل من الحديث عن هذه المشكلة مع فريق الدعم التقني لمحاولة حلّها. الانتقال إلى SSL ثاني أمر عليك أخذه بالحسبان عند نقل موقع ووردبريس بين خادومين هو أمرٌ تقنيٌ بحت، ويتمحور حول شهادات SSL، فلو كنتَ تنتقل من موقع لا يستعمل شهادات SSL (أي أنَّ روابط URL تشبه http://example.com) إلى بيئة تستعمل فيها شهادات SSL (الروابط تشبه https://example.com)، فيجب أن تتنبَّه إلى ذلك؛ لأنَّ محرِّك البحث والزوار سيبحثون عن الصفحات في http://example.com وإذا لم تمنعهم من ذلك، فسينتهي بهم المطاف بالدخول إلى النسخة القديمة غير الآمنة من الموقع، وهذا يعني: 1. سيُدخِل المستخدمون بياناتهم الشخصية مثل معلومات بطاقاتهم الائتمانية في النسخة غير الآمنة من الموقع، وهذا أمرٌ خطيرٌ جدًا من الناحية الأمنية. 2. ستكون معلومات تحليل موقعك غريبةً جدًا، لأنك سترى إحصائيات عن زيارات النسخة الآمنة أو غير الأمنة كلًا على حدة. 3. سيرى محرِّك Google نسختين من الصفحات، إحداها موجودةٌ في http://example.com والأخرى مماثلةٌ تمامًا لها موجودةٌ في https://example.com، مما يجعله يظن أنَّك تملك موقعين منفصلين فيهما نفس المحتوى، مما يعرِّضك للعقوبة بسبب تكرارك للمحتوى نفسه. دون الدخول بتفاصيل تقنية بحتة عن هذه المشكلة، دعني أخبرك ماذا عليك أن تفعل: ثبِّت إضافة WP Force SSL وهي إضافةٌ بسيطةٌ ورائعةٌ والتي تُعيد توجيه جميع الزيارات التي تقصد الصفحات التي تبدأ بالسابقة ‎http://‎ إلى نسخة https://‎ منها. عليك اتباع التعليمات الخاصة بالإضافة والمتعلقة بضبط ووردبريس ثم عليك تفعيلها. هنالك عملٌ كثيرٌ علينا فعله لجعل شهادات SSL المثبتة حديثًا تعمل عملًا سليمًا، لكن بعد تثبيت إضافة WP Force SSL فستتأكد من عدم وجود نسختين من موقعك مما لا يضر بتقييم SEO. أبقِ في ذهنك أنَّ Google سيُكافئ المواقع التي تستعمل تشفير SSL، لذا اعلم أنَّ انتقالك إلى استخدام شهادة SSL سيفيدك على المدى الطويل. ثانيًا: نقل موقع عادي إلى موقع ووردبريس إذا كنتَ تنقل موقعًا من تقنيةٍ مختلفةٍ إلى ووردبريس، فعليك حكمًا أن تفهم كيفية استعمال إعادة التوجيه من النوع 301، وكيف ستساعدك إعادة التوجيه في ووردبريس في الحفاظ على تقييم SEO للصفحات القديمة. السبب وراء استخدام إعادة التوجيه هو اختلاف التقنيات واختلاف بُنى الروابط الدائمة. التقنيات المختلفة تستعمل بُنى مختلفة للروابط الدائمة انظر إلى الصفحات الأربع الآتية: 1. example.com/great-optimized-page.html 2. example.com/great-optimized-page.asp 3. example.com/great-optimized-page.php 4. example.com/index.php?page=great-optimized-page لا يعلم Google أرتباط أيِّ صفحةٍ من الصفحات السابقة بأخرى، فلها أربعة روابط URL مختلفة تمامًا، ولا يملك Google أيّة فكرة أنَّها تُشير جميعها إلى المحتوى نفسه. إذا كتبتَ موقعك من الصفر باستخدام PHP فستبدو الروابط الدائمة لصفحاتك كالآتية: example.com/great-optimized-page.php. أما إذا استعملتَ صفحات HTML الثابتة، فستبدو الروابط الدائمة كما يلي: example.com/great-optimized-page.html. أما إذا كنّا سننتقل من دروبال إلى ووردبريس فقد تكون بنية الروابط الدائمة مختلفةً اختلافًا جذريًا. تتضمن خطتك نقل أحد أنواع المواقع السابقة إلى ووردبريس؛ والتي تُتيح استعمال عدِّة أشكال من الروابط الدائمة، وأشهرها يبدو كالآتي: example.com/great-optimized-page. إذًا عند نقلك لموقعك إلى ووردبريس، فسيصبح لكل صفحة في الموقع رابطٌ دائمٌ جديدٌ بسبب اختلاف التقنيات المستعملة، وهذا ينطبق على الغالبية العظمى من التقنيات التي تحاول نقلها إلى ووردبريس. كيف نخبر Google عن التغييرات في الروابط الدائمة وكما شرحنا أعلاه، لا يعلم Google عن تغيير الروابط الدائمة شيئًا إلا إذا أخبرتَه بذلك، وعليك فعل ذلك للحفاظ على تقييم SEO لعملائك، لذا حان الوقت الآن لتعلّم كيفية إعادة توجيه الصفحات في ووردبريس. الطريقة التقنية لفعل ذلك هي عبر تعديل ملف ‎.htaccess، والذي يستعمله خادوم أباتشي (Apache) ليقرأ التعليمات منه، لكن كتابة قواعد ملف ‎.htaccess هي مهمةٌ صعبة ومن السهل تعطيل الموقع في حال ارتكاب خطأ صغير فيه؛ لكن هنالك حلٌّ آخر يوفِّر بديلًا رائعًا أقل تعقيدًا من التعديل اليدوي هو استخدام إضافة مجانية خاصة بوردبريس باسم Simple 301 Redirects. إضافة Simple 301 Redirects تسمح لنا بتمرير الزيارات إلى مكانٍ آخر ضمن النطاق نفسه، أو إلى نطاقٍ آخر مختلفٍ تمامًا، كما لو أنَّك تكتب قواعد ملف ‎.htaccess يدويًا. يمكنك أيضًا استخدام المحارف البديلة (wildcard) لتحديد جميع الصفحات، فلنقل مثلًا أنك تريد إعادة توجيه جميع الصفحات الموجودة في domain.com/‎ إلى مكانها الجديد في domain.com/app/‎. هذه صورةٌ لصفحة إعدادات إضافة Simple 301 Redirects التي تُظهِر جميع عمليات إعادة التوجيه في أحد المواقع: ‎كما ترى، الروابط الموجودة في العمود على يسار الصورة يُعاد توجيهها إلى مختلف أشكال الروابط. يجدر بالذكر أنَّ هنالك ملحق مجاني باسم Bulk Uploader يتبع لإضافة Simple 301 Redirects، والذي يساعدك في معالجة عشرات ومئات عمليات إعادة التوجيه عبر رفع ملف بتنسيق CSV. كيف تعثر على الصفحات التي عليك إعادة توجيهها أفضل طريقة لمعرفة ما هي روابط URL التي تريد إعادة توجيهها هي إنشاء سجل بها قبل نقلك الموقع إلى ووردبريس، إذ يمكنك إنشاء ورقة عمل Excel أو Calc تحتوي جميع الروابط الدائمة الموجودة في الموقع الأصلي وأين يجب أن تُشير بعد الانتقال إلى موقع ووردبريس. يجب أن تبدو السجلات كالآتية: ‎/great-optimized-page.asp > /great-optimized-page وذلك لكل صفحة موجودة في موقعك. لكن في حال نقلتَ موقعك إلى ووردبريس ولنفترض أنّك فقدتَ سجل الصفحات التي كانت موجودةً في موقعك القديم، فتكون أفضل طريقة حينئذٍ هي رؤية ما الذي يعرفه Google عن موقعك عبر تصفح صفحة النتائج الخاصة بموقعك. إذا كتبتَ عبارة بحث شبيهة بالعبارة الآتية site:exmaple.com في مربع البحث في Google، فستلاحظ وجود عدد كبير من روابط URL التي تُشير إلى صفحاتٍ في موقعك القديم (مثل صفحة ‎/great-optimized-page.asp)، وذلك لأنَّ Google ما يزال يعرض تلك النتائج ويُوجِّه الزوار إليها، حتى لو لم تعد موجودةً. يجدر بك إعادة توجيه جميع النتائج التي تعثر عليها باستخدام إضافة Simple 301 Redirects، أو أيِّ إضافةٍ أخرى تُجري عملية إعادة التوجيه، أو يمكنك كتابة قواعد ملف ‎.htaccess يدويًا. يمكنك اختبار نجاح عملية إعادة التوجيه بضغطك على أحد الروابط، فإن وجدتَ أنها تُشير إلى الصفحة المعنية في ووردبريس فذلك أمرٌ حسن، أو انتهى بك المطاف في صفحة «404» فعليك تحري ما هي المشكلة التي تمنع إعادة التوجيه إلى الصفحات الجديدة. ثالثًا: تغيير بنية الروابط الدائمة في موقع ووردبريس موجود مسبقًا عندما تُغيّر بنية الروابط الدائمة في ووردبريس بالدخول إلى «Settings > Paramalinks» (الإعدادات > الروابط الدائمة)، فأنت تزيد من احتمال ظهور رسائل 404 للزوار. تحاول ووردبريس إعادة توجيه بعض أنواع التعديلات على الروابط الدائمة تلقائيًا، لكن لا تفعل ذلك لجميع أنواع التعديلات، ولسوء الحظ لا تكون القواعد التي تتبعها ووردبريس لإعادة التوجيه متناسقةً ولا يسهل فهمها، لذا لا تعتمد على ووردبريس لفعل ذلك، فعندما تُغيّر بنية الروابط الدائمة (حتى لو فعلتَ ذلك لرابطٍ دائمٍ لصفحةٍ واحدةٍ فقط) فعليك تجربة الموقع يدويًا باحثًا عن صفحات 404، وتجرِّب الروابط الدائمة القديمة، ثم تصلح أيّة صفحات 404 تعثر عليها باستخدام Simple 301 Redirects أو غيرها من الأدوات. الخلاصة ليس بالضرورة أن تكون عمليات إعادة التوجيه معقدةً، لكن من المهم جدًا أن نستعمل إعادة التوجيه عند الحاجة لما لها من أثرٍ كبيرٍ في الحفاظ على تقييم الصفحات في محرِّكات البحث. ترجمة –وبتصرّف– للمقال Understanding 301 Redirects in WordPress لصاحبه Fred Meyer

وجدتُ العمل كمطوّر على ووردبريس قليل المتاعب، فإنتاج مواقع وِب جميلة هو خدمةٌ رائعةٌ نقدمها للآخرين وأمرٌ لا يؤدي إلى كارثة إذا لم تتقنه تمامًا بادئ الأمر؛ حيث لا يُشابه العمل طيارا حربيا أو في حرس الحدود! لكن مع ذلك، هنالك استثناءات: ففي بعض الأحيان سبَّب لي عملي مشاكل وكان شعوري بالذنب وتأنيب الضمير سيؤدي بي إلى ترك عملي. ولاحظتُ أنَّ أسباب ذلك هي نفسها، ولقد وضعتها في رسمٍ توضيحي، لذا سأترك المخطط ليتحدث عنها: رغبتُ بترك عملي مرات عدّة عندما أثرّتُ على تقييم موقع العميل في محركات البحث؛ فأخطاء SEO لها وقعٌ كبيرٌ نظرا لأسباب كثيرة منها: يمكنها أن تكلِّف عميلك قدرا كبيرا من المال، فلو كان موقع عميلك هو مصدر دخله الرئيسي، فأخطاء SEO ستؤثر على دخله الشهري، أو تدمره (وبالتالي نمط حياته). يسهل كثيرًا الوقوع بهذه الأخطاء، خصوصًا لو كنتَ على درايةً بتطوير مواقع ووردبريس، لكن معلوماتك عن بنية الإنترنت ومحركات البحث محدودة. إذا ارتكبتَ خطأً كبيرًا، فمن شبه المستحيل إصلاحه! فعلى عميلك أن ينفق أشهرًا من وقته في إعادة بناء موقعه بمساعدة خبير SEO بعد خسارته لتقييمه العالي، ولا يوجد شيءٌ يمكنك أن تفعله للمساعدة. سنناقش في هذا الدرس إحدى الأمور التي أرى المطورين غير المتمرسين يفعلونها بعملائهم، ألا وهي عدم استخدام إعادة التوجيه للروابط التي جرى تغييرها، خصوصًا عند تحويل موقع إلى ووردبريس من تقنية أخرى. المفاهيم الأساسية عند استخدام إعادة التوجيه هذا القسم ليس دليلًا شاملًا لإعادة التوجيه، وإنما يشرح الأفكار الأساسية التي يتعامل Google بناء عليها مع صفحات الويب وروابطها، ولماذا علينا أن نسعى محاولين إرضاءه عند تغيير روابط الصفحات. تقييمات البحث يعمل محرِّك Google للبحث داخليًا عبر تقييم الصفحات التي يمكن البحث عنها، وقد يُظهِر محرِّك Google إحدى الصفحات كأوّل نتيجة عند البحث اعتمادًا على معايير كثيرة، ويُظهِر صفحةً أخرى كثاني نتيجة، وهلم جرًا. ولأنَّ محرِّك البحث Google يستقبل شهريًا مليار عملية بحث، فتقييم إحدى صفحات الموقع في Google تقييمًا مرتفعًا يعني الحصول على عدِّد هائل من الزيارات إلى موقعك، والذي بدوره يعني إمكانية بيع الكثير من المنتجات، أو الضغط على الإعلانات، أو توقيع العرائض، أو أيّ أمر آخر يجعلك تجني المال أو تُحقِّق هدفك من الموقع. التقنية المستعملة لمساعدة مواقع معيّنة لتحسين تقييمها في محرِّك Google (وغيره من محركات البحث الأقل شهرة) تسمى «Search Engine Optimization» (التهيئة لمحركات البحث) اختصارًا SEO، وإذا قلنا «تقييم SEO لإحدى الصفحات» فنحن نشير إلى تقييم الصفحة عند محرِّك Google. الروابط الدائمة لا يُقيّم Google الأداء بناءً على كامل صفحات الموقع، وإنما لكل صفحةٍ على حدة. فلنقل مثلا أنّ لدينا صفحة رابطها example.com/great-optimized-page ذات أداءٍ جيد (لسببٍ من الأسباب) وتظهر في أعلى قائمة النتائج في إحدى عبارات البحث الشهيرة؛ مما يؤدي إلى توجيه زيارات كثيرة إلى تلك الصفحة، وقد تكون تلك الصفحة بمفردها مسؤولةً عن أغلبية زيارات (وبالتالي دخل) الموقع، حتى لو لم تكن بقية صفحات الموقع ذات أداء جيد في محرِّكات البحث. الرابط الدائم(paramlink وهي كلمةٌ مركّبةٌ أصلها «permanent link») هو عنوان URL الذي يُفترَض أنَّه الرابط الدائم لإحدى الصفحات. ففي مثالنا السابق، كان الرابط الدائم للصفحة هو example.com/great-optimized-page. يُرسِل محرِّك Google الزوار إلى صفحتك عبر الرابط الدائم، فلو كان يوصي Google بأحد المطاعم إلى كثير من زواره، لكن رابط الصفحة لم يعد يعمل فجأة، ورَجَعَ الزوار إلى Google مشتكين من عدم وجود تلك الصفحة، فسيتوقف Google عن إظهار تلك الصفحة في نتائج البحث. ما هي إعادة التوجيه؟ يشرح Google لنا معنى إعادة التوجيه شرحًا جيدًا، لذا لنبدأ باقتباسٍ من عندهم: علاقة إعادة التوجيه بالتهيئة لمحركات البحث وكما في مكاتب البريد، سيُسعَد Google بتحديث سجلاته عندما تُرسِل له استمارة «تغيير العنوان» (وفي حالتنا، هذه «الاستمارة» هي إعادة التوجيه ذات الرمز 301)، وبعد فترةٍ قصيرةٍ من تغييرك للرابط الدائم لصفحتك وضبط إعادة توجيه من الرابط القديم إلى الجديد، فسيبدأ Google بربط نتائج البحث إلى عنوان صفحتك الجديدة، وهذا ما يسمح للصفحة ذات الرابط الجديد بالاحتفاظ بتقييم الرابط القديم نفسه. ماذا يحدث إذا لم تضبط إعادة التوجيه؟ حسنًا لو لم يُغيّر أحدنا عنوان منزله بعد انتقاله، فستذهب الكثير من «المعلومات» المهمة (مثل الدعوات، واستمارات الضرائب، والرسائل البريدية …) إلى عنوانٍ قديم، وستُعاد الكثير من الطرود إلى مكتب البريد، ولن تحصل على أيٍّ منها! هذا ينطبق أيضًا على عناوين الويب، فلو تغيّر عنوان example.com/great-optimized-page دون تمرير الزيارات إلى رابطٍ آخر، فإنّ جميع الزيارات إلى ذاك العنوان لن تكتمل، فلم تعد الصفحة متوفرة في ذاك العنوان، لذا ستظهر رسالة الخطأ الشهيرة «404» عند محاولة زيارة الصفحة، وهذا الرمز يعني «لا توجد صفحة مرتبطة بهذا العنوان». لا يحب Google إرسال الزوار إلى روابط «ميتة»، لذا سيحذف الصفحة example.com/great-optimized-page من سجلاته، ويسمح لبقية الصفحات التي تناقش الموضوع نفسه بأخذ مكان هذه الصفحة؛ وهذا يعني أنَّ السنوات الطوال التي أمضيناها في تطوير الصفحة للحصول على تقييم عال في Google قد ضاعت، ومن المرجح أنها ضاعت للأبد! كيف يبدو الضرر الذي أُحدِثَ في تقييم SEO لموقع العميل إذا نقلتَ لتوِّك الموقع إلى ووردبريس، وكان مبنيا على تقنية قديمة منذ عقود متضمنًا نظام تجارة إلكترونية لا يعمل تمامًا، لكن لمّا كان الموقع قديما ومتخصصا في تقديم خدماتٍ ممتازة في مجالٍ معيّن، فتقييمه أصبح مرتفعًا جدًا في Google. أما موقع ووردبريس فهو جميل، ويُحمَّل بسرعة، وإدارته أسهل، ويبدو بمظهرٍ رائعٍ على الهواتف؛ لكن بعد نقلك لجميع منتجات الموقع إلى WooCommerce فلم تُعِد توجيه الروابط الدائمة لصفحات الموقع القديمة. مرّت ستة أسابيع على إطلاق الموقع الجديد، ثم أتتك رسالةٌ عبر البريد الإلكتروني من عميلك قائلًا فيها: «لقد أحببتُ الموقع الجديد، لكنني نظرتُ في تحليل Google Analytics ووجدتُ أنَّ الموقع لا تأتيه زيارات من محرِّك البحث؛ إضافةً إلى انخفاض مبيعاتي من 10 آلاف دولار شهريًا قبل الانتقال إلى الموقع الجديد إلى حوالي 500 دولار بعد الانتقال إلى الموقع الجديد. هلّا أخبرتني ماذا يحدث؟». لقد أدركتَ خطأك هنا! فصفحات الموقع القديمة ذات التقييم العالي أصبحت تعرض الخطأ 404 (الصفحة غير موجودة) ولم تُجرِ عملية إعادة توجيه إلى الروابط الدائمة في موقعك الجديد الذي يستعمل ووردبريس؛ لكن للأسف لقد فات الأوان، فذهبت التقييمات العالية لموقع العميل، وحذفه Google من سجلاته، وأصبح عميلك يخسر آلاف الدولارات شهريًا بسبب خطئك، وأمسيتَ تفكِّر بإلقاء حاسوبك من النافذة والانضمام إلى مدرسة تدريب الطيارين الحربيين. لا تحسبنّ قصة الرعب السابقة غير حقيقية، بل هي شائعةٌ أكثر مما تتوقع. وفقدان تقييم SEO لصفحات موقع العميل هو أخطر الأمور التي قد تحدث عند تطوير المواقع. سنتحدث في الجزء الثاني من هذه المثال عن طرائق تفادي حدوث مثل هكذا قصص، بمختلف حالات استخدام ووردبريس. ترجمة –وبتصرّف– للمقال Understanding 301 Redirects in WordPress لصاحبه Fred Meyer.

NAT، أو نقل عنوان الشبكة network address translation، عبارة عن مصطلح عام لإدارة الرُّزَم packets من أجل إعادة توجيهها إلى عنوان بديل، وهو يُستخدم عادةً للسماح لحركة مرور البيانات traffic بتجاوز حدود الشبكة، يمتلك المُضيف host الذي يُطبِّق NAT نفاذًا إلى شبكتين أو أكثر بشكل نموذجي وهو مُعَد لنقل حركة مرور البيانات بينها. إعادة توجيه المنافذ Port forwarding هو عمليّة إعادة توجيه الطلبات لمنفذ مُعيَّن إلى مُضيف آخر، شبكة، أو منفذ. وبينما تقوم هذه العمليّة بتعديل وجهة الرُّزَم أثناء نقلها، فهي تُعتبَر نوع من عمليّات NAT. سنشرح في هذا الدرس كيفيّة استخدام iptables لإعادة توجيه المنافذ إلى مضيفين خلف جدار ناري باستخدام تقنيات NAT، يكون هذا مفيدًا في حال قمنا بإعداد شبكة خاصّة Private Network ولا زلنا نريد السماح لبعض حركة مرور البيانات بالمرور عبر جهاز مُحدّد كبوّابة gateway، سنستخدم مُضيفين اثنين يعملان على نظام Ubuntu لتوضيح هذا. المتطلبات الأساسية والأهداف لمتابعة هذا الدّرس تحتاج إلى مُضيفين اثنين يعملان على نظام Ubuntu في نفس مركز البيانات مع تمكين الشبكات الخاصّة private networking، نحتاج إلى إعداد حساب مُستخدِم غير جذري non-root مع صلاحيّات sudo على كل من هذين الجهازين، تستطيع معرفة كيفيّة إعداد مُستخدِم مع صلاحيّات sudo باتّباع درس الإعداد الأولي لخادوم Ubuntu. سيعمل المُضيف الأول كجدار ناري ومُوجِّه router لأجل الشبكة الخاصّة، ولأغراض توضيحيّة سيكون المُضيف الثاني مُعدًّا مع خادوم ويب قابل للوصول فقط باستخدام واجهته الخاصّة، سنقوم بإعداد جهاز الجدار الناري ليُعيد توجيه الطلبات التي يتلقّاها على واجهته العامّة إلى خادوم الويب حيث ستصل إلى واجهته الخاصّة. تفاصيل المضيف نحتاج قبل البدء أن نعرف الواجهات والعناوين التي يتم استخدامها من قِبَل كلا الخادمين لدينا. العثور على تفاصيل شبكتنا للحصول على تفاصيل أنظمتنا نبدأ بإيجاد واجهات شبكاتنا Network Interfaces، نستطيع العثور على الواجهات والعناوين المرتبطة بها على أجهزتنا بكتابة: ip -4 addr show scope global 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 inet 198.51.100.45/18 brd 45.55.191.255 scope global eth0 valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 inet 192.168.1.5/16 brd 10.132.255.255 scope global eth1 valid_lft forever preferred_lft forever يُظهِر الخَرْج output السّابق واجهتين (eth0 و eth1) والعناوين المُخصّصة لكل منهما (192.51.100.45 و 192.168.1.5 على الترتيب)، ولمعرفة أيّ الواجهتين هي الواجهة العامّة نكتب: ip route show | grep default default via 111.111.111.111 dev eth0 تكون الواجهة الظاهرة أمامنا (eth0 في هذا المثال) هي الواجهة المُتصلة إلى بوّابتنا الافتراضيّة، وهي بكل تأكيد واجهتنا العامّة. قم بإيجاد هذه القيم على كل جهاز لديك واستخدمها للمتابعة مع هذا الدّرس بشكل صحيح. عينة بيانات من أجل هذا الدرس لكي نجعل متابعة هذا الدّرس أسهل سنستخدم العناوين الوهميّة وتعيينات الواجهة التالية، قم بوضع القيم الخاص بك بدلًا من هذه القيم: تفاصيل شبكة خادوم الويب: عنوان IP العام Public IP Address: 203.0.113.2 عنوان IP الخاص Private IP Address: 192.0.2.2 الواجهة العامّة Public Interface: eth0 الواجهة الخاصّة Private Interface: eth1 تفاصيل شبكة الجدار الناري: عنوان IP العام Public IP Address: 203.0.113.15 عنوان IP الخاص Private IP Address: 192.0.2.15 الواجهة العامّة Public Interface: eth0 الواجهة الخاصّة Private Interface: eth1 إعداد خادوم الويب سنبدأ بإعداد مُضيف خادوم الويب، نقوم بتسجيل الدخول كمستخدم sudo للبدء. تثبيت Nginx الخطوة الأولى التي سنقوم بها هي تثبيت Nginx على مُضيف خادوم الويب لدينا وقفله بحيث يستمع فقط إلى واجهته الخاصّة، يجعلنا هذا متأكدين من أنّ خادوم الويب لن يكون متوفّرًا إلّا إذا ضبطنا إعادة توجيه المنافذ بشكل صحيح. نبدأ بتحديث الذاكرة المؤقتة للحزم المحليّة local package cache باستخدام الأمر apt لتنزيل وتثبيت Nginx: webserver $ sudo apt-get update webserver $ sudo apt-get install nginx تقييد Nginx إلى الشبكة الخاصة بعد تثبيت Nginx نقوم بفتح ملف إعدادات كتلة block الخادوم الافتراضيّة للتأكد من أنّه يستمع فقط إلى واجهته الخاصّة، نفتح الملف عن طريق الأمر التالي: webserver $ sudo nano /etc/nginx/sites-enabled/default نبحث بداخله عن الأمر التوجيهي listen، ينبغي أن نجده في سطرين متتاليين في أعلى ملف الإعدادات: etc/nginx/sites-enabled/default/ server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; . . . } نقوم عند الأمر التوجيهي listen الأول بإضافة عنوان IP الخاص لخادوم الويب لدينا مع نقطتين قبل 80 لنُخبِر Nginx أن يستمع فقط إلى واجهته الخاصّة، سنوضّح في هذا الدّرس إعادة توجيه IPv4 فقط، لذا نستطيع إزالة الأمر التوجيهي listen الثاني المُعَد من أجل IPv6. سنقوم في مثالنا بتعديل الأمر التوجيهي listen بحيث يبدو كما يلي: etc/nginx/sites-enabled/default/ server { listen 192.0.2.2:80 default_server; . . . } عند الانتهاء نحفظ الملف ونغلقه، نختبر الملف بحثًا عن أخطاء الصياغة syntax بكتابة ما يلي: webserver $ sudo nginx -t إن لم تظهر أيّة أخطاء نُعيد تشغيل خادوم Nginx لتمكين الإعدادات الجديدة: webserver $ sudo service nginx restart التحقق من تقييد الشبكة Network Restriction من المُفيد عند هذه النقطة التحقّق من مستوى النفاذ الذي نملكه لخادوم الويب لدينا. إن قمنا بمحاولة النفاذ لخادوم الويب عبر واجهته الخاصّة من خلال خادوم الجدار الناري firewall ينبغي أن ينجح هذا: firewall $ curl --connect-timeout 5 192.0.2.2 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> . . . أمّا إن قمنا باستخدام الواجهة العامّة سنجد أنّنا لن نستطيع الاتصال: firewall $ curl --connect-timeout 5 203.0.113.2 curl: (7) Failed to connect to 203.0.113.2 port 80: Connection refused وهو بالضبط ما نتوقّع حدوثه. إعداد الجدار الناري لإعادة توجيه المنفذ 80 نستطيع الآن العمل على تنفيذ إعادة توجيه المنافذ على جهاز الجدار الناري. تمكين إعادة التوجيه في النواة Kernel الأمر الأول الذي يجب فعله هو تمكين إعادة التوجيه على مستوى النّواة، تكون إعادة التوجيه غير مُشغَّلة في مُعظم الأنظمة. ولتشغيل إعادة توجيه المنافذ لأجل هذه الجلسة فقط نكتب: firewall $ echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward ولتشغيل إعادة توجيه المنافذ بشكل دائم ينبغي علينا تحرير الملف etc/sysctl.conf/، نفتح الملف بصلاحيّات sudo بكتابة: firewall $ sudo nano /etc/sysctl.conf نبحث بداخله عن السطر التالي ونقوم بإزالة التعليق uncomment عنه: etc/sysctl.conf/ net.ipv4.ip_forward=1 عند الانتهاء نحفظ الملف ونغلقه، نقوم بتطبيق الإعدادات في هذا الملف بكتابة ما يلي: firewall $ sudo sysctl -p firewall $ sudo sysctl --system إعداد الجدار الناري الأساسي سنستخدم الجدار الناري الموجود في هذا الدّرس كإطار عمل أساسي من أجل القواعد، قم بتنفيذ التعليمات في درس كيفية إعداد جدارٍ ناريّ باستخدام iptables، وبعد الانتهاء يجب أن تكون قد: قمت بتثبيت iptables-persistent حفظت مجموعة القواعد الافتراضيّة في etc/iptables/rules.v4/ تعلّمت كيفيّة إضافة أو ضبط القواعد عن طريق تحرير ملف القواعد أو باستخدام الأمر iptables بعد أن تقوم بإعداد الجدار الناري الأساسي أكمل الخطوات التالية لكي تستطيع ضبطه من أجل إعادة توجيه المنافذ. إضافة قواعد إعادة التوجيه نريد أن نضبط جدارنا الناري بحيث تتم إعادة توجيه حركة مرور البيانات traffic المُتدفّقة لواجهتنا العامّة (eth0) إلى واجهتنا الخاصّة (eth1). يمتلك جدارنا الناري الأساسي السلسلة FORWARD مُعدّة افتراضيًّا لكي تستبعد DROP حركة مرور البيانات، نحتاج لإضافة قواعد تسمح لنا بإعادة توجيه الاتصالات لخادوم الويب لدينا، ولأغراض أمنية سنقوم بتحديد هذا بشكل مُحكَم بحيث يتم فقط السماح للاتصالات التي نرغب بإعادة توجيهها. سنقبل في السلسلة FORWARD الاتصالات الجديدة المتجهة للمنفذ 80 والقادمة من واجهتنا العامة مُغادرةً إلى واجهتنا الخاصة، يتم تحديد الاتصالات الجديدة بواسطة اللاحقة conntrack ويتم تمثيلها بشكل خاص بواسطة رُزمة TCP SYN: firewall $ sudo iptables -A FORWARD -i eth0 -o eth1 -p tcp --syn --dport 80 -m conntrack --ctstate NEW -j ACCEPT سيسمح هذا للرزمة الأولى المعنيّة بإنشاء الاتصال بالعبور من خلال الجدار الناري، نحتاج أيضًا للسماح بأي حركة مرور بيانات لاحقة في كلا الاتجاهين والتي تنتج عن هذا الاتصال، نكتب ما يلي للسماح بحركة مرور البيانات التي تُنشئ هذا الاتصال ESTABLISHED والمتعلّقة به RLEATED بين واجهاتنا الخاصّة والعامة: firewall $ iptables -A FORWARD -i eth0 -o eth1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT firewall $ iptables -A FORWARD -i eth1 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT بإمكاننا إعادة التحقّق من أنّ سياساتنا على السلسلة FORWARD هي الاستبعاد DROP بكتابة ما يلي: firewall $ sudo iptables -P FORWARD DROP عند هذه النقطة سمحنا بحركة مرور بيانات مُحدّدة بين واجهاتنا الخاصّة والعامّة بالمرور من خلال الجدار الناري لدينا، ومع ذلك لم نقم بضبط القواعد التي تُخبِر iptables فعليًّا كيف يقوم بنقل وتوجيه حركة مرور البيانات. إضافة قواعد NAT لتوجيه الرزم بشكل صحيح سنضيف الآن القواعد التي تُخبِر iptables كيف يقوم بتوجيه حركة مرور بياناتنا، نحتاج لتنفيذ عمليتين منفصلتين من أجل أن يقوم iptables بتغيير الرُّزَم بشكل صحيح بحيث يتمكّن العملاء من التواصل مع خادوم الويب. تحدث العمليّة الأولى التي تُدعى DNAT في السلسلة PREROUTING من جدول nat، وهي عمليّة تقوم بتبديل عنوان وجهة الرُّزَم لتمكينها من التوجه بشكل صحيح عندما تمر بين الشبكات، سيتصل العملاء على الشبكة العامّة إلى خادوم الجدار الناري لدينا بدون أن يعلموا عن بُنية الشبكة الخاصّة لدينا، نحتاج لتبديل عنوان الوجهة لكل رُزمة بحيث تعلم عند إرسالها خارج شبكتنا الخاصّة كيف تصل بشكل صحيح إلى خادوم الويب. بما أنّنا نقوم فقط بإعداد إعادة توجيه المنافذ ولا نقوم بعمل NAT على كل رُزمة تصطدم بجدارنا الناري فيجب علينا أن نُطابِق المنفذ 80 في قاعدتنا، سنقوم بمطابقة الرُّزَم التي تستهدف المنفذ 80 إلى عنوان IP الخاص لخادوم الويب لدينا (192.0.2.2 في مثالنا): firewall $ sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 192.0.2.2 يهتم هذا بنصف الحل، فينبغي الآن أن يتم توجيه الرُّزَم بشكل صحيح إلى خادوم الويب لدينا، ومع ذلك فإنّ الرُّزَم لا تزال تملك العنوان الأصلي للعميل كعنوان مصدر، وسيحاول الخادوم إرسال الرد مباشرة إلى ذلك العنوان، ممّا يجعل من المستحيل تأسيس اتصال TCP قانوني. نحتاج من أجل ضبط التوجيه المناسب أن نقوم بتعديل عنوان المصدر للرُزَم عندما تغادر الجدار الناري في طريقها إلى خادوم الويب، يجب علينا تعديل عنوان المصدر وتغييره إلى عنوان IP الخاص لخادوم الجدار الناري لدينا (في مثالنا 192.0.2.15)، سيتم عندها إرسال الرّد إلى الجدار الناري والذي يستطيع إعادة توجيهه إلى العميل كما هو متوقّع. ولتمكين هذه الوظيفة سنضيف قاعدة إلى سلسلة POSTROUTING من جدول nat، والتي يتم تقييمها مباشرة قبل إرسال الرُّزَم على الشبكة، سنطابق الرُّزَم الموجّهة إلى خادوم الويب عن طريق عنوان IP والمنفذ: firewall $ sudo iptables -t nat -A POSTROUTING -o eth1 -p tcp --dport 80 -d 192.0.2.2 -j SNAT --to-source 192.0.2.15 حالما يتم إعداد هذه القاعدة ينبغي أن يصبح خادوم الويب لدينا قابل للنفاذ عن طريق توجيه متصفّح الويب لدينا إلى العنوان العام لجهاز الخادوم الناري: curl 203.0.113.15 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> . . . اكتمل هنا إعداد إعادة توجيه المنافذ. ضبط مجموعة القواعد الدائمة نستطيع الآن بعد أن قمنا بإعداد إعادة توجيه المنافذ أن نحفظه في مجموعة قواعد دائمة. إن لم تكن تهتم بفقدان التعليقات الموجودة في مجموعة القواعد الحالية لديك فاستخدم الخدمة iptables-persistent لحفظ قواعدك: firewall $ sudo service iptables-persistent save إن كنت ترغب بالحفاظ على التعليقات في ملفّك، فقم بفتحه وتحريره يدويًّا: firewall $ sudo nano /etc/iptables/rules.v4 سنحتاج إلى ضبط الإعدادات في الجدول filter من أجل قواعد السلسلة FORWARD التي تمّت إضافتها، يجب علينا أيضًا ضبط القسم الذي يقوم بإعداد الجدول nat كي نستطيع إضافة القواعد PREROUTING و POSTROUTING، سيبدو هذا في مثالنا مُشابِهًا لما يلي: etc/iptables/rules.v4/ *filter # Allow all outgoing, but drop incoming and forwarding packets by default :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] # Custom per-protocol chains :UDP - [0:0] :TCP - [0:0] :ICMP - [0:0] # Acceptable UDP traffic # Acceptable TCP traffic -A TCP -p tcp --dport 22 -j ACCEPT # Acceptable ICMP traffic # Boilerplate acceptance policy -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT -A INPUT -i lo -j ACCEPT # Drop invalid packets -A INPUT -m conntrack --ctstate INVALID -j DROP # Pass traffic to protocol-specific chains ## Only allow new connections (established and related should already be handled) ## For TCP, additionally only allow new SYN packets since that is the only valid ## method for establishing a new TCP connection -A INPUT -p udp -m conntrack --ctstate NEW -j UDP -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j TCP -A INPUT -p icmp -m conntrack --ctstate NEW -j ICMP # Reject anything that's fallen through to this point ## Try to be protocol-specific w/ rejection message -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable -A INPUT -p tcp -j REJECT --reject-with tcp-reset -A INPUT -j REJECT --reject-with icmp-proto-unreachable # Rules to forward port 80 to our web server # Web server network details: # * Public IP Address: 203.0.113.2 # * Private IP Address: 192.0.2.2 # * Public Interface: eth0 # * Private Interface: eth1 # # Firewall network details: # # * Public IP Address: 203.0.113.15 # * Private IP Address: 192.0.2.15 # * Public Interface: eth0 # * Private Interface: eth1 -A FORWARD -i eth0 -o eth1 -p tcp --syn --dport 80 -m conntrack --ctstate NEW -j ACCEPT -A FORWARD -i eth0 -o eth1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT -A FORWARD -i eth1 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # End of Forward filtering rules # Commit the changes COMMIT *raw :PREROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] COMMIT *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] # Rules to translate requests for port 80 of the public interface # so that we can forward correctly to the web server using the # private interface. # Web server network details: # * Public IP Address: 203.0.113.2 # * Private IP Address: 192.0.2.2 # * Public Interface: eth0 # * Private Interface: eth1 # # Firewall network details: # # * Public IP Address: 203.0.113.15 # * Private IP Address: 192.0.2.15 # * Public Interface: eth0 # * Private Interface: eth1 -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 192.0.2.2 -A POSTROUTING -d 192.0.2.2 -o eth1 -p tcp --dport 80 -j SNAT --to-source 192.0.2.15 # End of NAT translations for web server traffic COMMIT *security :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] COMMIT *mangle :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT قم بحفظ الملف وأغلقه بعد إضافة ما سبق وضبط القيم لكي تنطبق على بيئة شبكتك الخاصّة. نختبر صياغة ملف القواعد لدينا بكتابة: firewall $ sudo iptables-restore -t < /etc/iptables/rules.v4 إن لم يتم اكتشاف أيّة أخطاء نقوم بتحميل مجموعة القواعد: firewall $ sudo service iptables-persistent reload نختبر أنّ خادوم الويب لدينا لا يزال قابل للنفاذ من خلال عنوان IP العالم للجدار النّاري: firewall $ curl 203.0.113.15 ينبغي لهذا أن يعمل كما عمل سابقًا. الخاتمة ينبغي الآن أن نكون متآلفين مع إعادة توجيه المنافذ على خادوم لينِكس باستخدام iptables، تتضمّن العملية السماح بإعادة التوجيه على مستوى النّواة، إعداد النفاذ للسماح بإعادة التوجيه لحركة مرور البيانات لمنافذ مُحدّدة بين واجهتين على نظام الجدار النّاري، وضبط قواعد NAT بحيث يُمكِن توجيه الرُّزَم بشكل صحيح، ربّما تبدو هذه عمليّة صعبة، ولكنّها تُوضّح أيضًا مرونة إطار عمل ترشيح الرُّزَم netfilter وجدار iptables النّاري، يُمكِن استخدام هذا لتمويه بُنية الشبكة الخاصّة لدينا مع السمّاح بحركة مرور البيانات للخدمات بالمرور بشكل حر عبر بوّابة جهاز الجدار النّاري. ترجمة -وبتصرّف- لـ How To Forward Ports through a Linux Gateway with Iptables لصاحبه Justin Ellingwood.

إرسال رسائل البريد الإلكترونيّ التعريفيّة (introduction) شيءٌ أساسيٌّ يقوم به مؤسِّسو المشاريع الناشئة بشكلٍ متكرّر. عليك أيضًا –كمؤسّسٍّ لمشروعٍ ناشئ- أن تتعلَّم كيفيّة كتابة ما يسمّى بـ" رسائل البريد الإلكتروني التعريفيّة القابلة لإعادة التوجيه" (forwardable introduction email) والتّي سنتعرّف على طريقة كتابتها والمغزى منها في هذا المقال. لماذا الرسائل التعريفية القابلة لإعادة التوجيه؟مثلما سبق وأن كتب رجل الأعمال الأمريكي فرد ولسن في وقتٍ سابق، فإنّ المُوافقة الثًنائية أو ما يُعرف بـ "double opt-in” هو الطريقةُ المُعتادة المتّبعة للتّعريف بالمؤسّسات والشّركات (يعني أن يُوافق الطّرفان على القيام بالأمر). افرِض أنّ مؤسّس شركةٍ ناشئة طلب مني أن أعرّفه على مستثمرين أو عملاءَ محتملين، حتّى إن كنت أعرف ذلك العميل أو المستثمر جيّدًا، فإنه لا يمكنني أن أُعرِّف بالمؤسّسة على نحو جيّد إلا بعد أن أعرف أولًا إن كان الطرف الآخر (الذي سأرسل له رسالة تعريفٍ بالمؤسّسة) مهتمًا بالأمر ولديه الوقت للتّواصل أم لا. ولمعرفة ذلك أرسل له بريدًا إلكترونيًّا. لكنّ كتابة رسالة إلكترونية من الصِّفر يستهلك وقتًا. سيتوجّب عليّ شرح المشروع التّجاري، وشرح أهمّية التّواصل مع المؤسّسة، وشرح القليل عن المؤسّس...الخ. سيستهلك كل بريدٍ إلكتروني 10 دقائق من وقتي إن كنت سأعمل على هذا النّحو. الرسائل القابلة لإعادة التوجيه تقلّل الجهد الذي سأبذله. لأنّ المؤسّس يشرحُ عمله والسبب الذي كتب الرسالة التعريفيّة لأجله. كلّ ما عليّ فعلهُ هو النّقر على على زرّ تمرير الرّسالة، إضافة جملة أو اثنتين عن تجربتي في التعامل مع الشركة ومؤسّسها، ثم إرسالُها. هيكل ونمط كتابة الرسائل القابلة لإعادة التوجيهطريقة كتابة الرسالة التعريفيّة وهيكلتها أمرٌ مهم، وإذا لم تقم به بشكلٍ صحيح سيضيف هذا عبئًا إضافيًّا على من سيعيد توجيه الرّسالة الإلكترونية. الفكرةُ في الأساس أن تجعله يتجنّب النسخ واللصق وتعديل الرّسالة . باختصار، البريد الإلكتروني القابل لإعادة التّوجيه يجب أن يكون مكتوبًا بطريقةٍ موجّهةٍ للمستلم النّهائي. إليك مثالًا يوضّح الفكرة: (لاحظ أنّه مجرّد مثالٍ فقط وتليه التّرجمة للتوضيح) From: krystle @ getbentobox.com To: alex.iskold @ techstars.com Subject: Intro to Danny Meyer at USHG for Bento Box Body Alex, thank you for passing this note to Danny Danny Bento Box (Techstars ’15) is building a digital operations platform for restaurants starting with mobile friendly web sites & marketing tools. Here is our Demo Day Pitch http://bit.ly/BentoBoxDemoDayPitch We now have over 100+ top NYC restaurants as customers including most of the Union Square Hospitality Group, Meatball Shop, Breslin, etc. The restaurants on the platform are seeing significant increase in conversion and reservations. We’ve been growing across our key metrics 30% MoM and are now expanding to Boston and Portland I’ve been a follower and admirer of yours for years, and I would love to get your feedback on our business Thank you Krystle لما وصلتني هذه الرّسالة، نقرت على زر إعادة تمرير الرّسالة وأضفت بضعة أسطر فوقها (الرسّالة تليها التّرجمة للتّوضيح): Danny Krystle graduated Techstars NYC program in April. She is a deeply passionate and knowledgable founder. I highly recommend her and the team and hope you can find the time to connect. Please see more about her business and ask below Alex عندما يستلم "داني" البريد الإلكتروني، سيكون الأمر واضحًا له: سيفهم أنّ هذا البريد الإلكتروني عبارة عن طلب للتّعرف عليه والحديث معه.يستطيع رؤية اسم الشركة في حقل العنوان بوضوح.سيكون من السّهل إيجاد هذه الرسالة لاحقًا، لأنّ العنوان مميّز.يستطيع رؤية ملاحظاتي في أعلى الرسالة.بإمكانه قراءة المزيد عن الشركة وأن يسأل عنها في أسفل الرسالة.يمكنه الرّد بالقبول أو الرّفض اعتمادًا على الأمر.إذا تمّ القبول يمكنني أن أعيد توجيه البريد الإلكتروني لكريستل وتكون مهمّتي في تعريف الطّرقين قد كُلّلت بالنّجاح.إذا تمّ الرّفض، يمكنني إرسال الرّد بالرفض إلى الرسالة الأصلية التي أرسلتها كريستل.باتّباع الطريقة السليمة لكتابة البريد الإلكتروني القابل لإعادة التوجيه ستُقلّل الجهد الذي سيبذله الموكّل بإيصال الرسالة. وستجعل الرسائل التعريفيّة أكثر فاعليّة. جرّب هذه الطّريقة وأخبرنا بالنتائج. وإن كان لديك نصائح حول كتابة البريد الإلكتروني القابل لإعادة التوجيه فسنسعد بمعرفتها. ترجمة –وبتصرف- للمقال How to write a forwardable introduction email لصاحبه Alex Iskold. حقوق الصورة البارزة: Designed by Freepik.