المقدمة
يوضح هذا المستند كيفية إستخدام Umbrella DNS باستخدام وكيل HTTP.
المتطلبات الأساسية
المتطلبات
لا توجد متطلبات خاصة لهذا المستند.
المكونات المستخدمة
تستند المعلومات الواردة في هذا المستند إلى خدمة Umbrella Global DNS، وليس لبوابة الويب الآمنة (SWG).
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
معلومات أساسية
يعترض وكيل HTTP حركة مرور HTTP/S على الشبكة. بعد ذلك، يقوم بإجراء اتصال HTTP/S بالخادم البعيد نيابة عن العميل الأصلي، مما يقوم بإرجاع الاستجابات إلى هذا العميل. يتمتع معظم وكلاء HTTP بالقدرة على حظر الاتصالات بمواقع معينة استنادا إلى التصنيف أو محتوى الأمان أو حظر الاستجابات من الخوادم البعيدة التي تجعل المحتوى يحتوي على محتوى غير مرغوب فيه مثل البرامج الضارة.
هناك طريقتان رئيسيتان لإعادة توجيه حركة مرور HTTP إلى وكيل: إعادة توجيه صريحة وإعادة توجيه شفاف. تتطلب هذه الطرق المختلفة خطوات مختلفة يجب إتخاذها من أجل العمل بشكل صحيح بالاشتراك مع Umbrella.
يناقش هذا المقال كيفية تأثير وكيل HTTP على سلوك Umbrella وكل جزء من حل Umbrella ثم يوفر مجموعتين من الخطوات لإعادة التوجيه الصريح وإعادة التوجيه الشفاف.
هذا المخطط هو ملخص للحلول المعروضة بمزيد من التفاصيل:
proxy-umbrella-diagram.png
كيف يؤثر وكيل HTTP على خدمة DNS العامة ل Umbrella
عند اعتراض حركة مرور HTTP/S، يقوم وكيل HTTP بقراءة رأس المضيف في طلب HTTP/S، وإنشاء استعلام DNS الخاص به لهذا المضيف. وبالتالي، من المهم أخذ سلوك الوكيل في الاعتبار عند نشر حلول Umbrella. وعلى المستوى المجرد، يتضمن هذا التأكد من عدم إعادة توجيه إتصالات HTTP/S لعناوين IP الخاصة بالمظلة إلى الوكيل، ولكنها بدلا من ذلك يتم إرسالها مباشرة إلى الوجهة المقصودة.
حماية الشبكة
عند إستخدام حماية شبكة Umbrella فقط، يوصى بتكوين وكيل HTTP نفسه لاستخدام Umbrella مباشرة لحل DNS، أو يمكنه إستخدام خادم DNS داخلي يقوم بدوره بإعادة توجيه استعلامات DNS إلى Umbrella. يمكن تسجيل عنوان IP الخارجي المناسب كهوية شبكة في لوحة معلومات المظلة. في هذا السيناريو، لا يلزم إتخاذ أي إجراء إضافي لاستخدام Umbrella.
إذا لم يكن هذا ممكنا لسبب ما، وكان العملاء أنفسهم يستخدمون Umbrella، فيمكن عندئذ إتخاذ الإجراءات المفصلة في هذه المادة لضمان عدم تجاوز التنفيذ من قبل وكيل HTTP.
Umbrella Roaming Client
عند إستخدام عميل Umbrella المتجول، يتم إرسال استعلامات DNS من جهاز العميل مباشرة إلى Umbrella. ومع ذلك، نظرا لأن وكيل HTTP يقوم بتنفيذ استعلامات DNS الخاصة به، فإن هذا يجعل التنفيذ بواسطة عميل Umbrella المتجول غير فعال. وهكذا، عند إستخدام عميل Umbrella المتجول في بيئة وكيل، يجب اتباع الإجراءات المفصلة في هذه المقالة.
تكامل الأجهزة الظاهرية و Active Directory
يهدف الجهاز الظاهري (VA) إلى العمل كخادم DNS لأجهزة العميل على الشبكة المحمية. وعلى هذا النحو، يؤدي إستخدام وكيل HTTP إلى عدم فعالية إنفاذه بنفس الطريقة التي يتم بها تطبيق العميل المتجول. وعلى هذا النحو، يمكن اتباع الإجراءات المفصلة في هذه المادة لضمان فعالية الإنفاذ ودقة الإبلاغ.
بالإضافة إلى الإجراءات أدناه، يوصى بتكوين وكيل HTTP لاستخدام VA كخادم DNS الخاص به. وهذا يتيح لك تحديد سياسة خاصة بالوكيل حتى يمكن تحديد الاستفسارات من الوكيل. كما يسمح لك هذا النهج بتعطيل تسجيل الاستعلامات التي تم إنشاؤها من الوكيل، والتي تتجنب وجود استعلامات مكررة في تقاريرك.
وكلاء واضحون
يستلزم نشر وكيل صريح تعديل إعدادات وكيل المستعرض لإعادة توجيه حركة مرور البيانات بشكل صريح إلى وكيل. ويتم ذلك إما باستخدام "نهج المجموعة" في Windows، أو بشكل أكثر شيوعا، باستخدام ملف "التكوين التلقائي للوكيل" (PAC). في كلتا الحالتين، يتسبب ذلك في قيام المستعرض بإرسال كافة حركات مرور بيانات HTTP مباشرة إلى الوكيل، بدلا من إرسالها إلى الموقع البعيد. نظرا لأن المستعرض يعرف أن الوكيل يقوم بإنشاء طلب DNS خاص به، فلا يتعطل حل اسم المضيف للموقع البعيد نفسه. بالإضافة إلى ذلك، وكما تمت الإشارة مسبقا، فعندما يصل اتصال HTTP إلى الوكيل، يقوم الوكيل بإنشاء استعلام DNS الخاص به، والذي يمكن الحصول عليه نتيجة مختلفة عن تلك التي سيحصل عليها العميل.
وبالتالي، من أجل العمل بشكل صحيح مع Umbrella، يلزم تغييران:
- يجب إجبار العميل على إجراء استعلام DNS.
- يجب ألا تنتقل إتصالات HTTP الموجهة إلى عناوين IP الخاصة ب Umbrella إلى الوكيل، بل يجب أن تنتقل مباشرة إلى Umbrella.
يمكن تنفيذ كلا هذه التغييرات باستخدام ملف مسوغات الوصول المحمي:
function FindProxyForURL(url, host) { // Generate DNS request on the client hostIP = dnsResolve(host); // If the requested website is using an Umbrella IP address, return DIRECT if (isInNet(hostIP, "67.215.64.0", "255.255.224.0") || isInNet(hostIP, "204.194.232.0", "255.255.248.0") || isInNet(hostIP, "208.67.216.0", "255.255.248.0") || isInNet(hostIP, "208.69.32.0", "255.255.248.0") || isInNet(hostIP, "185.60.84.0", "255.255.252.0") ||
isInNet(hostIP, "155.190.0.0", "255.255.0.0") ||
isInNet(hostIP, "146.112.0.0", "255.255.0.0")) ||
isInNet(hostIP, "151.186.0.0", "255.255.0.0"))
{ return "DIRECT"; } // DEFAULT RULE: All other traffic, use below proxies, in fail-over order. return "PROXY 192.0.2.5:8080; PROXY 192.0.2.6:8080";}
في ملف مسوغات الوصول المحمي هذا، يتم إنشاء استعلام DNS أولا، مع التقاط IP الناتج في متغير hostIP. تتم بعد ذلك مقارنة عنوان IP الناتج هذا مع كل نطاق عناوين IP الخاصة بالمظلة. في حالة وجود تطابق، لا يتم إرسال الاستعلام إلى الوكيل، بل يتم إرساله مباشرة. وإذا لم يكن هناك تطابق، فسيتم إرسال الطلب إلى البروكسيات المناسبة.
لاحظ أنه بالنسبة للمواقع التي لم يتم حظرها وبالتالي لا يتم إعادة توجيهها إلى عنوان IP الخاص ب Umbrella، فإن تأثير إستخدام ملف مسوغات الوصول المحمي السابق هو أن كل من العميل والوكيل يقوم بإجراء طلب DNS للمضيف البعيد. إذا كان الوكيل يستخدم أيضا OpenDNS، فهذا يعني أن التقارير الخاصة بك تعرض استعلامات مكررة. إذا كنت تستخدم Virtual Appliance، كما تمت الإشارة إليه مسبقا، فيمكن حساب ذلك عن طريق إنشاء هوية شبكة داخلية للوكيل الخاص بك. إذا كنت ترغب في ذلك، يمكنك بالإضافة إلى ذلك إنشاء سياسة للوكيل تقوم بتعطيل التسجيل بالكامل لإخفاء هذه الطلبات المكررة.
ملاحظة: إذا كنت تقوم بحظر طلبات HTTP/S الصادرة على جدار الحماية الخاص بك من مصادر أخرى غير الوكيل، فيجب التأكد من السماح بهذه الطلبات إلى نطاقات IP التي تمت مناقشتها مسبقا للسماح للأجهزة الخاصة بك بالوصول إلى صفحات كتل Umbrella.
الوكلاء الشفافة
بالنسبة للوكيل الشفاف، تتم إعادة توجيه حركة مرور HTTP إلى الوكيل على مستوى الشبكة. نظرا لأن العميل غير مدرك للوكيل، يقوم المستعرض بإنشاء طلب DNS خاص به. وهذا يعني أنه إذا كان الوكيل يستخدم أيضا Umbrella، يتم تكرار كل طلب. بالإضافة إلى ذلك، لا يتم تطبيق النهج بشكل صحيح لأن الوكيل يستخدم إستجابة DNS التي تلقاها، وليس النتيجة التي تلقاها العميل.
بخلاف الحالة الصريحة من قبل في هذه المقالة، لا يتطلب حل هذه المشكلة فرض طلب DNS على العميل، حيث إن ذلك يحدث بالفعل. ومع ذلك، لا يزال يلزم تجاوز وكيل إتصالات HTTP إلى عناوين IP الخاصة ب Umbrella. تختلف طريقة القيام بذلك بشكل كبير حسب الآلية التي تستخدمها لإعادة توجيه حركة المرور إلى الوكيل. ومع ذلك، فإنها تتضمن بشكل عام إستثناء نطاقات عنوان IP الخاص ب Umbrella من أن يتم إعادة توجيهه.
على سبيل المثال، لنفترض أنه يتم إستخدام WCCP على Cisco ASA لإعادة توجيه حركة المرور إلى الوكيل، باستخدام قائمة التحكم في الوصول (ACL) هذه:
access-list wccp-traffic extended permit ip any any
يمكن تعديل قائمة التحكم في الوصول إلى حركة مرور WCCP لرفض إعادة التوجيه إلى الوكيل (وبالتالي تجاوز الوكيل) لنطاقات IP المظلة:
access-list wccp-traffic extended deny ip any 67.215.64.0 255.255.224.0access-list wccp-traffic extended deny ip any 204.194.232.0 255.255.248.0access-list wccp-traffic extended deny ip any 208.67.216.0 255.255.248.0access-list wccp-traffic extended deny ip any 208.69.32.0 255.255.248.0access-list wccp-traffic extended deny ip any 185.60.84.0 255.255.252.0access-list wccp-traffic extended deny ip any 146.112.0.0 255.255.0.0
access-list wccp-traffic extended deny ip any 155.190.0.0 255.255.0.0
access-list wccp-traffic extended deny ip any 151.186.0.0 255.255.0.0
access-list wccp-traffic extended permit ip any any
ملاحظة: لم يتم إختبار قائمة التحكم في الوصول (ACL) هذه وتختلف حسب إصدار ASA أو إصدار Cisco IOS® الذي يتم إستخدامه. يرجى التأكد من أن أي قوائم تحكم في الوصول (ACL) تقوم بإنشائها مناسبة للحل الخاص بك، وتم إختبارها بشكل شامل قبل نشرها في بيئة إنتاج.
ملاحظة: إذا كنت تقوم بحظر طلبات HTTP/S الصادرة في جدار الحماية الخاص بك من مصادر أخرى غير الوكيل، فيجب التأكد من السماح بهذه الطلبات إلى نطاقات IP التي تمت مناقشتها مسبقا للسماح للأجهزة الخاصة بك بالوصول إلى صفحات كتل المظلة.