مشكلة Dns طلب الموقع الخاص بالشركة من داخل الدومين

أفضل حل لفتح الموقع من داخل الدومين هو إدخال IP السيرفر بدل اسمه

لذلك عليك الإتصال بالشركة المستضيفة وطلب Server IP

وبفرض أنه

192.168.0.1

تقوم بفتح الموقع كمايلي:

http://192.168.0.1

وفي حال وجود لوحة تحكم خاصة بالبريد

http://192.168.0.1:2082

وهكذا

عليك بعمل DNS Forwarding ...

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

عليك بعمل DNS Forwarding ...

السلام عليكم ورحمته الله وبراكاته

تحياتي للعاملين في الفربق العربي للبرمجة :blush: وللاستاذ محمد أكرم :happy: أنا عضو جديد أرجو قبولي في موقعكم المتميز بنسبة للمشكلة المطروحة أنا أتعرض لنفس المشكلة

أسم الدومين مثال GROUP.COM

وأسم الموقع على الانترنيت مثال GROUP.COM

من داخال الشركة لااستطيع الخول الى الموقع ألا أذا قمت بألغاء

DNS

للجهاز ووضع

DNS IP FOR INTERNET

فكيف يجب أن أحل هذه المشكلة من

DNS Forwarding

وأنا مطر جدا :wub: :S

ولك جزيل الشكر

محب الله ورسوله

HAITHAM P5

الإخوة wa7ad_lb و HAITHAMP5..

لو قعدتم 100 سنة على الـDNS Forwarding فهي لن تحل المشكلة. الحل هو إما في DNS Splitting أو DNS Doctoring

سبب المشكلة:

عندما يقوم مستخدم داخل الشبكة، او خارج الشبكة بطلب اسم النطاق فانه سيحصل على رقم IP public دائما وهو على سبيل المثال 200.200.200.200

المشكلة الحقيقية هي NAT. الـNAT يعتمد على اتجاه الطلب الذي يأتي منه. مثلا:

200.200.200.200---->192.168.1.1

عندما يدخل شخص من الإنترنت إلى خادم الموقع من خلال الإنترفيس الشابك على الإنترنت، سيأتي الطلب من الإنترنت متجها إلى 200.200.200.200 ويتم تحويله إلى 192.168.1.1

لكن إذا أتى الطلب من الإنترفيس المشبوك على الـLAN، فإن الـNAT لن يتم تطبيقه، بالتالي لن تستطيع دخول الموقع.

الحل الأول: DNS Split

أقرب حل للصواب قاله الأخ m_ismael لكنه حل قبيح نوعا ما لاننا نكره استخدام الأرقام... فالحل الأفضل كما قلت DNS Splitting

الـDNS Splitting بصفة عامة هو أن الطلبات الصادرة من الداخل سيتم ترجمتها إلى 192.168.1.1، بينما الطلبات الصادرة من الخارج سيتم ترجمتها إلى 200.200.200.200 و بالتالي تتجنب مشكلة الـNAT

وأصلا حتى لو لم تكن لديك المشكلة هذه فDNS Splitting موصى به لزياده سرعة الإتصال من الداخل.

الحل الثاني DNS Doctoring

حل آخر هو DNS Doctoring وهو فعال بالـDefault مع NAT في Cisco IOS. بالتالي ماعليك سوى تغيير رقم الآي بي في الـDNS Server إلى 192.168.1.1. الطلبات الداخلية ستكون سعيدة، والطلبات الخارجية ستتعرض لـDNS Doctoring وسيتم تحويله إلى 200.200.200.200 وستكون سعيدة أيضا

shado كتب:

حتى عملية الطلب من الداخل وعند طلب اي شي متعلق بالنت حتى لو دمين يجب ان تتم عملية NAT لانها عملية لا بد من وجوبها حتى لعمليات الاتصال الداخلية

تحياتي

الله معك..

انت مش فاهم السؤال... السيرفر في الشبكة المحلية + الكلاينت في الشبكة المحلية ايضا.. هنا المشكلة، لا حاجة للـNAT بينهم. وأصلا النات سيسبب مشكلة عدم الإتصال للسبب الذي ذكرته آنفا

eech55 .. نورت :)

الموقع Hosted على الشبكه الداخليه ... وPublished على الانترنت ... ومعمول له MAP مع Domain Name.

داخليا ... اذا أردت طلب الموقع ... فأنت في كل الأحوال ترسل ال Request الى ال Local DNS بشكل أجباري, السبب !! مستحيل ان يعمل الكلاينت على الشبكه الداخليه داخل Domain Boundaries بدون DNS ...

الان عند طلب الموقع ... يتم ارسال العتوان لل Local DNS الذي يجب ان يحتوي على Host A record .... ما يحدث لو لم يكن ال Host A Record يشير الى ال IP الداخلي الحاص بالموقع فال Client لا يفهم ان ال DNS Server يملك العنوان ... فهو فعليا يقوم بالطلب بشكل Recursive .... هنا يقوم ال Local DNS بفحص ال Local Mapped DB ... ان لم يجد يقوم بارسال ال Request بشكل Iterative لأي DNS اخر ... طبعا ال Iterative Request يكوت بناءا على ماذا؟؟

أمرين:

1- DNS Forwarders.

2- Root Hint.

في الاولى ... يقوم ال DNS بارسال ال Request لل Forwarders كما هو مهيأ داخله .. كمثال ... وضعت ال Forwarder هو ال ISP DNS ... سيرسل الطلب لل ISP ليقوم بفحص العنوان ... في حال كان ال Domain مفعل على الانترنت ... يرسل ال Request من ال ISP DNS لل Local DNS ... ومن طرفه يرسل الطلب لل Client ...

في الثانيه ... ان لم يكن هناك Forwarders ... سيتم نقل الطلب لل Root Hints ... ال Root Hint أما يكون موضوع بشكل يدوي ... او ياخذ قيمته من ال DNS IP الموضوع في اعدادات الشبكه لل Local DNS Server ...

الان من الحاله المطروحه ... ما دام الموقع Hosted داخليا ... تأكد من صحة ال Host A الحامل لعنوان الموقع مع ال IP ... ال Troubleshooting للموضوع سهل.

لاحظ عند وضع عنوان ال ISP تستطيع التصفح !! لأن ال Request أساسا لا يمر على ال Local DNS ... فبالتالي مشلكتلك تكمن إما في:

- ال Map ما بين ال Local Record للموقع وال External Record له.

- ال SOA بين ال Local و ال ISP فيه مشكلة Synchronization (استبعدها لانك تستطيع التصفح من الخارج).

ساتي لل Troubleshooting Methods للمشكله وكيف تحلها عندما أجد وقت :)

الكلام الذي بالأعلى على ذمتي.

Mohammed Akram كتب:

eech55 .. نورت :)

الموقع Hosted على الشبكه الداخليه ... وPublished على الانترنت ... ومعمول له MAP مع Domain Name.

داخليا ... اذا أردت طلب الموقع ... فأنت في كل الأحوال ترسل ال Request الى ال Local DNS بشكل أجباري, السبب !! مستحيل ان يعمل الكلاينت على الشبكه الداخليه داخل Domain Boundaries بدون DNS ...

الان عند طلب الموقع ... يتم ارسال العتوان لل Local DNS الذي يجب ان يحتوي على Host A record .... ما يحدث لو لم يكن ال Host A Record يشير الى ال IP الداخلي الحاص بالموقع فال Client لا يفهم ان ال DNS Server يملك العنوان ... فهو فعليا يقوم بالطلب بشكل Recursive .... هنا يقوم ال Local DNS بفحص ال Local Mapped DB ... ان لم يجد يقوم بارسال ال Request بشكل Iterative لأي DNS اخر ... طبعا ال Iterative Request يكوت بناءا على ماذا؟؟

أمرين:

1- DNS Forwarders.

2- Root Hint.

في الاولى ... يقوم ال DNS بارسال ال Request لل Forwarders كما هو مهيأ داخله .. كمثال ... وضعت ال Forwarder هو ال ISP DNS ... سيرسل الطلب لل ISP ليقوم بفحص العنوان ... في حال كان ال Domain مفعل على الانترنت ... يرسل ال Request من ال ISP DNS لل Local DNS ... ومن طرفه يرسل الطلب لل Client ...

في الثانيه ... ان لم يكن هناك Forwarders ... سيتم نقل الطلب لل Root Hints ... ال Root Hint أما يكون موضوع بشكل يدوي ... او ياخذ قيمته من ال DNS IP الموضوع في اعدادات الشبكه لل Local DNS Server ...

الان من الحاله المطروحه ... ما دام الموقع Hosted داخليا ... تأكد من صحة ال Host A الحامل لعنوان الموقع مع ال IP ... ال Troubleshooting للموضوع سهل.

لاحظ عند وضع عنوان ال ISP تستطيع التصفح !! لأن ال Request أساسا لا يمر على ال Local DNS ... فبالتالي مشلكتلك تكمن إما في:

- ال Map ما بين ال Local Record للموقع وال External Record له.

- ال SOA بين ال Local و ال ISP فيه مشكلة Synchronization (استبعدها لانك تستطيع التصفح من الخارج).

ساتي لل Troubleshooting Methods للمشكله وكيف تحلها عندما أجد وقت :)

الكلام الذي بالأعلى على ذمتي.

السلام عليكم

:blush: والشكر الكبير لكم جميعا ولاستاذنا الكبير

'Mohammed Akram'

والشكر على الرد العلمي المفصل :happy: وأنا أنتظر

Troubleshooting

العملي بفارغ الصبر :wub:

محب الله ورسوله

اقتباس

الموقع Hosted على الشبكه الداخليه ... وPublished على الانترنت ... ومعمول له MAP مع Domain Name.

داخليا ... اذا أردت طلب الموقع ... فأنت في كل الأحوال ترسل ال Request الى ال Local DNS بشكل أجباري, السبب !! مستحيل ان يعمل الكلاينت على الشبكه الداخليه داخل Domain Boundaries بدون DNS ...

الان عند طلب الموقع ... يتم ارسال العتوان لل Local DNS الذي يجب ان يحتوي على Host A record .... ما يحدث لو لم يكن ال Host A Record يشير الى ال IP الداخلي الحاص بالموقع فال Client لا يفهم ان ال DNS Server يملك العنوان ...

الـDNS Clients في الوندوز ومعظم انظمة التشغيل الشبيهة باليونكس نسخ مبسطة لا تقبل إلا اجابتين:

1- الجواب النهائي وليس referrals

2- رسالة خطأ

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

لكن أنت اضفت اختيار ثالث وهو ان الكلاينت ينظرإلى الرقم، واذا لم يكن داخلي فسيرسله إلى local DNS. هذا عجيب.

اقتباس

لاحظ عند وضع عنوان ال ISP تستطيع التصفح !! لأن ال Request أساسا لا يمر على ال Local DNS ... فبالتالي مشلكتلك تكمن إما في:

ليس شرطا. إذا كان البروكسي SOCKS فحينها سيتم استخدام الـLocal DNS. واذا كان HTTP Proxy فحينها سيتم استخدام الـبروكسي التابع لمزود الخدمة.

اقتباس

في الثانيه ... ان لم يكن هناك Forwarders ... سيتم نقل الطلب لل Root Hints ... ال Root Hint أما يكون موضوع بشكل يدوي ... او ياخذ قيمته من ال DNS IP الموضوع في اعدادات الشبكه لل Local DNS Server ...

بالنسبة لـSOA و كون رقم الـIP خطأ فهذا ليس واردا البتة لأن الموقع يعمل بإستخدام البروكسي. وهذا دليل ان A record مشير إلى رقم إنترنت خارجي صحيح.

من باب فائدة القارئ. عندك خلط فالمصطلحات. Recursive يعني أن الـDNS server يقوم بإتباع جميع الـreferrals في سبيل إعطاء الجواب الفيصل (اما 1 او 2) للكلاينت.

و Iterative تعني أن السيرفر يقوم بإرسال الـreferals إلى الكلاينت ويترك الكلاينت يخدم نفسه بنفسه. فتجد الكلاينت يقوم بسؤال DNS servers أخرى بحسب ماجاء في الـreferals. وهذا لا يحدث مع نظام التشغيل وندوز ومعظم أنظمة تشغيل اليونكس. فالكلاينت الموجودة في هذه الأنظمة نسخ مبسطة لا تدعم هذا الإختيار.

عندما نقول DNS Client أرسل Recursive request يعني أنه أرسل طلب إلى DNS و هذا الـDNS يجب عليه التعامل مع الطلب بشكل Recursive أي أنه ينهي العملية إلى الآخر ويرسل الجواب النهائي (1 او 2) إلى الكلاينت.

عندما نقول DNS Client أرسل Iterative requestd يعني أنه أرسل طلب إلى DNS وهذا الـDNS بإمكانه عدم اتمام الطلب إلى النهائية والإكتفاء بإرسال الـreferal إلى الكلاينت. والكلاينت يخدم نفسه بنفسه ويخاطب خادمات DNS أخرى.

http://www.zytrax.com/books/dns/ch2/index.html#recursive

http://www.zytrax.com/books/dns/ch2/index.html#iterative

eech55 كتب:

الكلاينت مافرقت معاه إذا الرقم داخلي ولا خارجي. وسيقبل أي رقم.

الـDNS Clients في الوندوز ومعظم انظمة التشغيل الشبيهة باليونكس نسخ مبسطة لا تقبل إلا اجابتين:

1- الجواب النهائي وليس referrals

2- رسالة خطأ

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

لكن أنت اضفت اختيار ثالث وهو ان الكلاينت ينظرإلى الرقم، واذا لم يكن داخلي فسيرسله إلى local DNS. هذا عجيب.

ليس شرطا. إذا كان البروكسي SOCKS فحينها سيتم استخدام الـLocal DNS. واذا كان HTTP Proxy فحينها سيتم استخدام الـبروكسي التابع لمزود الخدمة.

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

بالنسبة لـSOA و كون رقم الـIP خطأ فهذا ليس واردا البتة لأن الموقع يعمل بإستخدام البروكسي. وهذا دليل ان A record مشير إلى رقم إنترنت خارجي صحيح.

من باب فائدة القارئ. عندك خلط فالمصطلحات. Recursive يعني أن الـDNS server يقوم بإتباع جميع الـreferrals في سبيل إعطاء الجواب الفيصل (اما 1 او 2) للكلاينت.

و Iterative تعني أن السيرفر يقوم بإرسال الـreferals إلى الكلاينت ويترك الكلاينت يخدم نفسه بنفسه. فتجد الكلاينت يقوم بسؤال DNS servers أخرى بحسب ماجاء في الـreferals. وهذا لا يحدث مع نظام التشغيل وندوز ومعظم أنظمة تشغيل اليونكس. فالكلاينت الموجودة في هذه الأنظمة نسخ مبسطة لا تدعم هذا الإختيار.

عندما نقول DNS Client أرسل Recursive request يعني أنه أرسل طلب إلى DNS و هذا الـDNS يجب عليه التعامل مع الطلب بشكل Recursive أي أنه ينهي العملية إلى الآخر ويرسل الجواب النهائي (1 او 2) إلى الكلاينت.

عندما نقول DNS Client أرسل Iterative requestd يعني أنه أرسل طلب إلى DNS وهذا الـDNS بإمكانه عدم اتمام الطلب إلى النهائية والإكتفاء بإرسال الـreferal إلى الكلاينت. والكلاينت يخدم نفسه بنفسه ويخاطب خادمات DNS أخرى.

http://www.zytrax.com/books/dns/ch2/index.html#recursive

http://www.zytrax.com/books/dns/ch2/index.html#iterative

السلام عليكم

ألف شكر لكم :happy: وأنا الان أقرا ما هو موجد داخل

link :blink: