
تطوير البنية التحتية لتكنولوجيا المعلومات ، عاجلاً أم آجلاً ، تأتي المهمة للتكامل مع أي خدمات لمنظمة كبيرة. قد يكون هذا ، على سبيل المثال ، مصرفًا أو مشغل اتصالات. كقاعدة عامة ، لدى المؤسسات الكبيرة سياسات أمان معلومات راسخة ، والتي تتطلب بشكل خاص تنفيذ خدمة ذات بنية أساسية خارجية من خلال القنوات المشفرة - IPSec. في الوقت نفسه ، في مؤسسات
بدء التشغيل الصغيرة ، لا توجد خبرة في تنظيم مثل هذه المخططات ، ومن المعدات لا يوجد سوى VDS مع Linux على متن الطائرة. علاوة على ذلك ، لدهشتي ، عمليا لا توجد مواد في Runet تصف أدوات استكشاف أخطاء Linux وإصلاحها. دعنا نحاول إزالة هذه الفجوة ووصف الجزء العملي من الإعدادات.
يتم تقديم المخطط العام للخدمة أدناه. كقاعدة ، يتم توحيد كل شيء في المؤسسات الكبيرة بالفعل ، ويتم تشغيله ، ويتم إجراء جميع أنواع التشفير الممكنة وقطع الشبكة الأخرى على معدات منفصلة (tsiska-junipers وغيرها مثلهم) ، والأهم من ذلك بواسطة
الأفراد (ربما كل مربع أزرق في الرسم البياني أدناه يخدمها أشخاص مختلفون). لديك جهاز افتراضي واحد سيتم إطلاق الخدمة به وسيتم تنظيم IPSec.

يرجى ملاحظة أن IPSec نفسها منظمة بين عنوان IP واحد (في المثال الخاص بي
10.0.255.1 <-> 10.0.1.1
) ، والخدمة نفسها منظمة بين الآخرين (
192.168.255.1<-> 192.168.1.1
). تسمى هذه المخططات أيضًا
IPSec Network-Network .
مثال بسيط هو أنك تعمل في شركة
SuperService شابة ولكنها طموحة للغاية ، وتحتاج إلى تنظيم التفاعل مع واجهة برمجة التطبيقات المغلقة لـ
MegaTelecom . البنية التحتية الخاصة بك هي خادم VDS واحد ، البنية التحتية للشريك هي مجموعة من معدات الشبكة والخادم. تنقسم المهمة إلى مرحلتين:
- لتنظيم النقل (كيف سيحدث التشغيل البيني).
- تكوين الخدمة (تشغيل التطبيقات مباشرة على الخوادم).
لذا ، قرر مدير
SuperService تنظيم اتصال ببعض المنظمات الكبيرة لحل مشكلة تجارية. التفت إلى
MegaTelecom ، وأرسلوا إليه
المواصفات الفنية للاتصال. أحد هذه الشروط
IPSec . جاء هذا الشرط على شكل لوحة
اكسل ، مثال عرضته أدناه. في الصورة ، أبرزت المعلمات المهمة تقنياً باللون الأصفر. قد يختلف التنسيق ، ولكن يبقى الجوهر هو نفسه.

في البداية ، لا يأتي من جانبك ، يجب ملؤه وإرساله للموافقة على الشريك. بعد الموافقة ، يمكنك الجلوس ومحاولة ضبط جهاز Linux الخاص بك.
مفهوم IPSec
بعد ذلك ، سأقدم القليل من النظرية للأشخاص الذين ليسوا على دراية بالتكنولوجيا على الإطلاق. يشير كل ما سأصفه أيضًا إلى محض إيثرنت و IPv4. لن أخوض في التشفير ، خوارزميات تبادل المفاتيح ، ولكن بدلاً من ذلك أركز على جزء الشبكة.
IPSec - مجموعة من التقنيات والبروتوكولات لتنظيم اتصال آمن.
على عكس تقنيات الأنفاق الأخرى (GRE ، PPP ، L2TP ، حتى MPLS-TE) ، لا يتم إنشاء واجهات نفق صريحة لـ IPSec يمكن من خلالها توجيه حركة المرور. بدلاً من ذلك ، يوفر IPSec مفهوم ما يسمى بـ
Assotiations Security (SA) .
SA هو النفق من جهاز شبكة إلى آخر. ولكن لا تنس أن
SA ليست واجهة شبكة بالمعنى الطبيعي للكلمة ، ولا يعمل التوجيه الكلاسيكي هنا. بدلاً من جدول التوجيه ، يعمل مفهوم
سياسة الأمان (SP) هنا. نحن نصف بشكل صريح شيئًا مثل قائمة الوصول (ACL) لتمرير حركة المرور عبر SA محدد. يتم تعريف كل هذه الأشياء في ما يسمى إطار عمل
ISAKMP .
ISAKMP - وصف لإجراءات IPSec ، في الأدبيات التي يسمونها إطار عمل. يصف المصطلحات SA ، SP ، SAD (قاعدة بيانات Assotiations) ، SPD (قاعدة بيانات سياسة الأمان) ، الحاجة إلى تثبيت الأنفاق الإضافية ... تم تصميم ISAKMP بحيث لا تعتمد على تقنيات الأنفاق وخوارزميات المصادقة والتشفير. إنه ببساطة يقدم التعريفات اللازمة.
IKE (v1 / 2) - بروتوكول المصادقة مباشرة. يقوم بالفعل بتنفيذ خوارزميات تبادل المفاتيح وتطبيقاتها.
بفضل مفهوم Cisco ، أصبح ISAKMP و IKE مترادفين الآن.
قبل تشفير حركة المرور ، يجب أن يتفق الطرفان على المعلمات (والمفاتيح) لهذا التشفير. للقيام بذلك ، يرتفع نفق مساعد بين الجانبين (ويسمى أيضًا نفق ISAKMP) ، والذي يعمل طوال الوقت. هذا النفق ثنائي الاتجاه هو اتصال UDP (افتراضيًا على المنفذ 500). لتنظيم هذا النفق المساعد ، يجب على الطرفين المصادقة على بعضهما البعض (يجب أن تتطابق كلمة المرور). يتم ذلك عن طريق
بروتوكول IKEv1 / 2 (تبادل مفاتيح الإنترنت) . وبالفعل في نفق
ISAKMP المنظم ، يتفق الطرفان على تشفير حركة مرور المستخدم مباشرة.
تنقسم منظمة IPSec نفسها إلى مرحلتين:
- إنشاء نفق مساعد ISAKMP
- إنشاء نفق بيانات المستخدم
كما كتبت ، في مفهوم IPSec (أو بالأحرى ، في مفهوم
ISAKMP ) تسمى الأنفاق
SA .
يمكن تنفيذ المرحلة الأولى (تنظيم ISAKMP SA) في وضعين:
- رئيسي - يتبادل الأطراف معايير التفاوض بالتناوب. يعتبر أكثر أمانًا ، ويستخدم للقنوات الدائمة (حالتنا).
- عدواني - في رسالة واحدة يرسل البادئ جميع معلمات التنسيق الضرورية ؛ يتم استخدامه عند توصيل مستخدم بعيد لجلسة مؤقتة (لجعله أسرع)
يجب أن تفهم أن أنفاق SA
الرئيسية أحادية الاتجاه . لإرسال البيانات في اتجاهين عبر قناة IPSec ، يجب أن يكون هناك نفقان: المصدر (src) → جهاز الاستقبال (dst) والعكس صحيح.
في جميع طرق التشفير ، تتم إضافة رؤوس إضافية إلى حزمة IP الأصلية ، ويحدث التغليف. هناك طريقتان لهذا التغليف -
AH (رأس المصادقة) و
ESP (حمولة أمان التغليف) . يوثق AH فقط الحزمة (موقعة رقمياً من قبل المرسل) ، ESP ويصادق (الإشارات) ، والتشفير. اليوم ، لم يتم استخدام AH تقريبًا أبدًا ، كل شيء معبأ في ESP.
يمكنك تشفير ومصادقة حزمة IP المصدر دون مراعاة رأس IP (وضع النقل) أو معها (وضع النفق).
يتم استخدام
النقل عندما يتم التخطيط لتنظيم أنفاقه باستخدام تقنيات أخرى (وليس IPSec / ESP). على سبيل المثال ، GRE ، l2tp ، ppp. لغرض ربط بعض الخدمات بالبنية التحتية الداخلية لمنظمة كبيرة ، لا يتم استخدامها عمليًا. لقد استخدمت هذا السيناريو لدمج عدة مكاتب في VPN واحد من خلال IPSec. نحن مهتمون أكثر
بوضع النفق . كما ترى من الصورة ، تمت إضافة رأس IP إضافي هنا.

بالمناسبة ، هناك مثال حقيقي لاستخدام التغليف AH. افترض أن لدينا شبكتين متصلتين بأجهزة توجيه مختلفة. يجب أن ينقل المضيفون معلومات مع MTU 1500 بايت بدون تجزئة ، ولكن لدينا قسم وسيط يدعم فقط 1380 بايت. المسار بأكمله موثوق به. يمكننا الاستفادة من حقيقة أن IPSec لا تنشئ واجهات نفق ، بالمعنى الكلاسيكي الذي لا يتم توجيه حركة المرور من خلاله. سنقوم بإنشاء نوع AH type tunnel SA (لسنا بحاجة إلى التشفير) ، ثم ستنتقل إليه حركة المرور. سيتم تجزئة حزم IP الخارجية فقط (وفقًا لرؤوس IP الخارجية) في حركة المرور ، وستتم إعادة تجميع الحزم الداخلية بدون تغييرات.


لاحظ أن رأس
ESP يرتفع
قبل نقل TCP / UDP . هل تتذكر أن حقل IP يحتوي على حقل بروتوكول؟ بناءً على هذا المجال ، تقوم معدات الشبكة (والمضيفون النهائيون) بمعالجة حزم IP بشكل صحيح. لذا بالنسبة لـ ESP ، فإن رقمها هو 50. ويمكن الاطلاع على قائمة كاملة من البروتوكولات لهذا المجال على
ويكي ، يمكن أن تكون مفيدة للغاية.

غياب رأس طبقة النقل (TCP / UDP / ICMP مشفر بالفعل!) يفرض قيودًا على تقنيات مثل NAT. تذكر أن NAT مع ترجمة المنفذ (التحميل الزائد ، PAT ، MASQARADE ، لديها العديد من الأسماء) تعمل على أساس منافذ بروتوكول النقل. وفي نفق IPSec المشفر ليسوا كذلك! للتغلب على هذه المشكلة ، هناك تقنية مثل
IPSec NAT-Traversal (NAT-T) . خلال المرحلة الأولى ، اتفق الطرفان على استخدام NAT-T. إذا كان كلا الجانبين يدعمان NAT-T (وحتى على نفس منافذ UDP) ، فسيتم إضافة رأس UDP إلى الأنفاق الناتجة لحركة المرور ، والتي ستمر بها الحزم بالفعل عبر أجهزة التوجيه مع ترجمة عنوان الشبكة.
لن يرتفع النفق نفسه ، تحتاج إلى توجيه حركة المرور إلى هناك. كما كتبت أعلاه ، لا تعمل قواعد التوجيه هنا ، تحتاج إلى كتابة سياسات
الأمان (SP) .
تتكون السياسات من عنوان المصدر وعنوان الوجهة والاتجاه (في الداخل والخارج و fwd) ومعلمات نفق المستخدم (هنا سيتم وصف ESP فقط سواء كانت AH أو إصدار النفق أو النقل). هذا أشبه بقواعد تنظيم NAT. ليس لدى NAT أيضًا إدخالات جدول توجيه كافية. وهناك أيضًا القواعد المشار إليها
أين وأين وكيف ، وليس
أين ومن خلال ماذا . وأيضًا مع حركة اليد الخاطئة ، يمكنك حظر جميع الاتصالات على الخادم البعيد.
تضيف جميع معالجات IPSec رؤوس علوية. على الأقل سوف يأكلون 40 بايت أخرى من الحزمة الأصلية. وهكذا ، على سبيل المثال ، مع MTU قياسي لـ PPPoE لـ 1380 بايت من الاتصالات ، سيكون MTU الحقيقي أقل من 1340.
IPSec على لينكس
دعونا نتدرب على استخدام مثال توزيعات DEB. سأفكر فقط في الحالة مع التفويض بناءً على
المفتاح المشترك مسبقًا (PSK) ، سنقوم بتكوين المخطط من بداية المقالة.
يدعم نواة IPSec نفسها ، ولكن هذا الدعم محدود للغاية. في الواقع ، لا تهتم الوحدات القوية إلا بالتشفير والمفاتيح (معالجة الحزم) التي تم استلامها بالفعل (تم نقلها إلى النواة). لتمرير هناك المعلمات والقواعد التي تحتاج إليها لمعالجة حركة المرور ، تحتاج إلى برنامج منفصل. مثل هذا البرنامج ، هناك العديد من الحلول:
- هاجر KAME من BSD
- xSWAN (سترونجسوان ، فريسوان ، ليبرسوان ، إلخ)
- جدار
بدا لي أبسط نسخة (يمكن التنبؤ بها) من KAME ، وسنواصل تحريفها.
تقليديا ، تتكون KAME من مكونين
- راكون الراكون للسيطرة على نفق ISAKMP .
- أدوات Setkey لإدارة أنفاق SA مع البيانات.
لنبدأ بالأول.
راكون هو المسؤول عن إعدادات تخويل النفق تحت IKE. هذا هو برنامج خفي ، تم تكوينه بملف تكوين واحد (
/etc/racoon.conf
) ، يتم تشغيله بواسطة برنامج نصي
/etc/init.d/racoon <start|stop|restart>
(
/etc/init.d/racoon <start|stop|restart>
).
root @ localhost: ~ # cat /etc/racoon.conf root @ localhost: ~ # cat /etc/racoon/psk.txt كما هو الحال دائمًا ، التفاصيل في
man 5 racoon.conf
بعد ذلك ،
سنتناول أداة
setkey . كما يبدأ كبرنامج خفي (
/etc/init.d/setkey <start|stop|restart>
) ، ولكنه في الواقع يقوم بتشغيل البرنامج النصي
/etc/ipsec-tools.conf
. كما قلت ، فإنه يحدد بالفعل إنشاء أنفاق لحركة مرور المستخدم. وهي تعيين
SA و SP لهم. هذا شيء مثل
خريطة التشفير على ASA. الخيار الأسهل بالنسبة لنا هو إضافة SP فقط. ثم سيتم بناء SA تلقائيًا استنادًا إلى معلمات المرحلة الثانية المحددة في إعدادات
الراكون .
ولكن من الممكن عدم استخدام معلمات المرحلة الثانية من
الراكون على الإطلاق ، ولكن لوضع SA من خلال هذه الأداة المساعدة. يمكن العثور على
man 8 setkey
في
man 8 setkey
. ولكن سأعطي مثالا على أبسط التكوين.
root @ localhost: ~ # cat /etc/ipsec-tools.conf flush; spdflush; spdadd 192.168.1.1/32 192.168.255.1/32 any -P out ipsec esp/tunnel/10.0.1.1-10.0.255.1/require; spdadd 192.168.255.1/32 192.168.1.1/32 any -P in ipsec esp/tunnel/10.0.255.1-10.0.1.1/require;
حاليا ،
يتم تكرار الأداة المساعدة
setkey بواسطة وحدة
iproute2 .
كجزء من ذلك ، هناك فريقان لإدارة السجلات SA و SP.
- حالة IP xfrm
- سياسة ip xfrm
بالإضافة إلى إدارة هذه الأداة المساعدة ، يمكنك الاطلاع على حالة عمليات ضمان الأمان (SA) المنظمة (SP) المنظمة والمطبقة على حركة المرور. المزيد من التفاصيل في
man 8 ip-xfrm
.
ألق نظرة أخرى على الجهاز اللوحي الأصلي. هناك عناوين IP مختلفة لخدمة IPSec والخدمة. تتم تصفية عنوان IP الداخلي داخل البنية التحتية Megatelecom . ولكن لدينا جهاز افتراضي واحد فقط. يجب أن يظهر عنوان IP الداخلي بطريقة أو بأخرى ، ويجب أن تنتقل الحزم إلى النفق منه. هناك عدة خيارات لتحقيق هذا السيناريو:
- مسار ثابت بدون اكتشاف نقطة توقف ، ولكن مع إشارة صريحة إلى الواجهة الصادرة وعنوان IP.
- تحديد المسارات استنادًا إلى التوجيه المستند إلى السياسة (PBR على Linux المعروف أيضًا بقاعدة ip ).
- ترجمة العنوان ( NAT / MASQARADE ).
من وجهة نظري ، الخيار الأول مناسب هنا.
يمكننا إضافة عنوان IP (ثانوي) إضافي إلى واجهتنا ، بينما من الأفضل إنشاء اسم مستعار لهذه الواجهة
root@localhost: ~# ip addr add 192.168.1.1/32 dev eth1 label eth1:1
وتكوين الطريق إلى خادم Megatelecom من عنوان IP هذا.
root@localhost: ~# ip route add 192.168.255.1/32 dev eth1:1 src 192.168.1.1
ولكن إذا فعلت ذلك ، فلن يبدأ شيء. الحقيقة هي أنه عند إضافة مسار في هذا النموذج ، ستحاول محطة Linux تحديد عنوان MAC الخاص بالمستلم ، وستقوم بذلك من خلال ARP ... سيقوم الكمبيوتر بإرسال طلبات ARP Who has IP 192.168.255.1
. نظرًا لأن 192.168.255.1 ليس على نفس الشبكة مثل 192.168.1.1 (قناع / 32!) ، فلن يكون هناك استجابة لـ ARP. ولكن عند محاولة الاتصال ، لن يتم إرجاع No route to host
من عنوان IP المحلي. ولهزيمة هذا ، نحتاج إلى وضع سجل ARP ثابت:
root@localhost: ~# arp -s 192.168.255.1 00:00:00:00:00:01 -i eth1:1
مثل هاك الحياة. بالمناسبة ، قد لا تؤدي هذه التلاعبات إلى التشغيل الصحيح لمكدس Linux IP. في إحدى الحالات ، لم تسفر أوامر ip route
عن النتيجة المرجوة ، كان من الضروري إعادة تشغيل مكدس الشبكة.
فحص الصحة
لا تنس أن النفق سيرتفع فقط عندما تذهب إليه حركة المرور! من الضروري البدء في تنفيذ الأمر ping من واجهة معينة (عنوان IP) قبل الوجهة.
root@localhost: ~# ping -I 192.168.1.1 192.168.255.1
مع تأخير بسيط ، يجب أن تكون هناك ردود من الجانب العكسي (ما لم يتم إغلاق ICMP بالطبع في أي مكان على الموقع).
يمكننا أن نرى ما إذا كان نفق ISAKMP قد ارتفع.
يمكننا أيضًا رؤية الأنفاق مع بيانات المستخدم.
racoonctl show-sa esp 10.0.1.1 10.0.255.1 esp mode=tunnel spi=2148175815(0x800a8fc7) reqid=0(0x00000000) E: 3des-cbc 799e587f 6a2b4b78 5590cc2a 3d3ee331 f7e7f472 01abcdef A: hmac-sha1 01c5161f 46679a36 5d07ee9d f159fc9a 01abcdef seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Oct 2 09:22:44 2018 current: Oct 2 10:39:21 2018 diff: 4597(s) hard: 28800(s) soft: 23040(s) last: Oct 2 09:22:45 2018 hard: 0(s) soft: 0(s) current: 84(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 1 hard: 0 soft: 0 sadb_seq=1 pid=3764 refcnt=0 10.0.255.1 10.0.1.1 esp mode=tunnel spi=45614328(0x02b804f8) reqid=0(0x00000000) E: 3des-cbc 97cedcf1 644e8bbb c22b4e2c fa08a874 01abcdef 211ad19e A: hmac-sha1 1ab3e79d 3fd924a0 01abcdef 6c9ac89a 01abcdef seq=0x00000000 replay=4 flags=0x00000000 state=mature created: Oct 2 09:22:44 2018 current: Oct 2 10:39:21 2018 diff: 4597(s) hard: 28800(s) soft: 23040(s) last: Oct 2 09:22:45 2018 hard: 0(s) soft: 0(s) current: 84(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 1 hard: 0 soft: 0 sadb_seq=0 pid=3764 refcnt=0
قد يكون من المفيد في
tcpdump أن ننظر إلى منطق إنشاء اتصال. هنا يمكنك أيضًا الاطلاع على مراحل إنشاء الاتصال وحركة المرور المنقولة بالفعل
المشفرة إلى ESP. بالطبع ، هناك تقنيات لفك تشفيرها ، ولكن عادة ما يكون هذا الاستنتاج كافيًا بالفعل.
root @ localhost: ~ # tcpdump -i eth1 host 10.0.255.1 18:01:06.409631 IP 10.0.1.1.500 > 10.0.255.1.500: isakmp: phase 1 I ident 18:01:06.439276 IP 10.0.255.1.500 > 10.0.1.1.500: isakmp: phase 1 R ident 18:01:06.440840 IP 10.0.1.1.500 > 10.0.255.1.500: isakmp: phase 1 I ident 18:01:06.475244 IP 10.0.255.1.1.500 > 10.0.1.1.500: isakmp: phase 1 R ident 18:01:06.477032 IP 10.0.1.1.500 > 10.0.255.1.500: isakmp: phase 1 I ident[E] 18:01:06.487785 IP 10.0.255.1.500 > 10.0.1.1.500: isakmp: phase 1 R ident[E] 18:01:06.488048 IP 10.0.1.1.500 > 10.0.255.1.500: isakmp: phase 2/others I inf[E] 18:01:07.412451 IP 10.0.1.1.500 > 10.0.255.1.500: isakmp: phase 2/others I oakley-quick[E] 18:01:07.465363 IP 10.0.255.1.500 > 10.0.1.1.500: isakmp: phase 2/others R oakley-quick[E] 18:01:07.465940 IP 10.0.1.1.500 > 10.0.255.1.500: isakmp: phase 2/others I oakley-quick[E] 18:01:08.467373 IP 10.0.1.1 > 10.0.255.1: ESP(spi=0x7aabfa82,seq=0x1), length 116 18:01:08.480141 IP 10.0.255.1 > 10.0.1.1: ESP(spi=0x0386f867,seq=0x1), length 116
عند الاتصال عن بعد عبر SSH ، حتى لا تنتج مجموعة من النوافذ ، من السهل تشغيل tcpdump في الخلفية:
root@localhost: ~# tcpdump -i eth1 -w ipsec.pcap esp &
نبدأ بينغ ، تلنت ، نت كات ...
root@localhost: ~# killall tcpdump
root@localhost: ~# tcpdump -vr ipsec.pcap
أيضًا في السجلات ، يمكنك رؤية الحالة الناجحة للاتصال. ويوضح الإنشاء الناجح لمرحلتي IPSec.
root @ localhost: ~ # cat /var/log/daemon.log Oct 3 17:53:26 vm22433 racoon: INFO: IPsec-SA request for 10.0.255.1 queued due to no phase1 found. Oct 3 17:53:26 vm22433 racoon: INFO: initiate new phase 1 negotiation: 10.0.1.1[500]<=>10.0.255.1[500] Oct 3 17:53:26 vm22433 racoon: INFO: begin Identity Protection mode. Oct 3 17:53:26 vm22433 racoon: INFO: received Vendor ID: CISCO-UNITY Oct 3 17:53:26 vm22433 racoon: INFO: received Vendor ID: DPD Oct 3 17:53:26 vm22433 racoon: INFO: received Vendor ID: draft-ietf-ipsra-isakmp-xauth-06.txt Oct 3 17:53:26 vm22433 racoon: INFO: ISAKMP-SA established 10.0.1.1[500]-10.0.255.1[500] spi:ebddc300af62ae42:abcdef0123 Oct 3 17:53:27 vm22433 racoon: INFO: initiate new phase 2 negotiation: 10.0.1.1[500]<=>10.0.255.1[500] Oct 3 17:53:27 vm22433 racoon: INFO: received RESPONDER-LIFETIME: 4608000 kbytes Oct 3 17:53:27 vm22433 racoon: WARNING: attribute has been modified. Oct 3 17:53:27 vm22433 racoon: INFO: IPsec-SA established: ESP/Tunnel 10.0.1.1[500]->10.0.255.1[500] spi=238677(0xe39eabc) Oct 3 17:53:27 vm22433 racoon: INFO: IPsec-SA established: ESP/Tunnel 10.0.1.1[500]->10.0.255.1500] spi=7204011111(0x44b4aaa)
هذا كل شيء. يبقى لإضافة جميع التلاعبات اللازمة لبدء التشغيل ، ويمكنك البدء في تكامل التطبيقات.
ملاحظة: طلب للإبلاغ عن جميع الأخطاء أو عدم الدقة في المقالة برسالة شخصية. عندما أقوم بتعديل المقالة ، ستبدو التعليقات سخيفة.