مقدمة
العديد من الشركات تعاني من مشكلة بطئ الإنترنت. إذا لم تعاني فالجميع دائما يريد زيادة سرعة الإنترنت.
دائما ارى من يستخدم bluecoat وغيره من منتوجات أكثر كلفة، بالرغم أننا ممكن أن نغطي على معظم الإحتياجات بالمجان وبإستخدام جهاز pc متواضع، حتى في الشركات الكبيرة.
هذا الكلام ليس نظريا بل طبقته في عدة مؤسسات والتجربة خير برهان. عنق الزجاجة هو خط الإنترنت وأي جهاز pc سيكون قوي جدا، ومعظم الوقت سيكون وضعه شبه idle، وهذا من خلال مراقبة نسبة استخدام المعالج، والذاكرة العشوائية، وسرعة القراءة والكتابة. مهما كان خط الإنترنت سريعا سنجده لا يتعدى الـ100mbps في معظم الأحيان. في معظم الأحيان 2 أو 4 أو 8. وهذا يعتبر لا شيء مقارنة بإمكانيات أي جهاز pc.
فلماذا نعقد الأمور ونشتري معدات أكثر كلفة بحجة الحصول على دعم فني. لو سقط الكاش فلن يتوقف شيء وسيكمل الـtraffic مساره فقط دون كاشينج إلى حين عودته، وهذا بواسطة آلية ستناقشها بإذن الله أيضا.
بكل بساطة، ستحضر جهاز pc يحتوي على منفذ 100mbps، وتنصب عليه هذا البرنامج. وبإجراء تغييرات معينة في الشبكة (وهي سهلة)، سيتم تحويل مسارات جميع الـtraffic الذاهب إلى تصفح الإنترنت من خلال الـproxy هذا، والذي بدوره سيقوم بتخزين تلك الملفات لإستخدامها لاحقا. هكذا لن نحتاج إلى حتى تغيير إعدادات متصفح الإنترنت عند بقية الموظفين لأنها ستكون transparent بالنسبة لهم.
وحتى لو كانت البيئة ثقيلة وتحتاج إلى جهاز قوي فلا مشكلة أيضا. للعلم برنامج squid cache يتم استخدامه بواسطة العديد من مزودات الخدمة في العالم.
إن شاء الله، سنتطرق عن كيفية تنصيب وإعداد forward cache proxy (بعكس reverse الذي تحدثنا عنه في درس سابق).
محتوى الدرس
- طريقة التثبيت الآلية على نظام Debian, Ubuntu ومشتقاتهم
- طريقة التثبيت الآلية على نظام Gentoo
- طريقة التثبيت الآلية على نظام FreeBSD
- طريقة التثبيت اليدوية
- إعدادات شائعة (لكن اختيارية) لخادم Squid
- مقدمة حول Transparent Proxy
- إعداد خادم Squid وتشغيله كـtransparent proxy
- إعداد الشبكة لتطبيق Transparent Forward Proxy
طريقة التثبيت الآلية على نظام Debian, Ubuntu ومشتقاتهم
apt-get install squid
ينزلك البرنامج من الإنترنت، ويثبتلك إياه، وإذا في dependecies ينزلهم ويثبتهم لك تلقائيا. وإذا كان في مجال، كان سيقبل يدك ورأسك أيضا. لينكس صعب؟ :huh:
طريقة التثبيت الآلية على نظام Gentoo
emerge squid
نفس الأعلى، إلا أنه يقوم بتنزيل السورس كود، ثم كوبايل ولنكينج، وثم تثبيت. نفس الكلام ينطبق على الـdependencies. كل هذا تلقائيا في كلمتين.
طريقة التثبيت الآلية على نظام FreeBSD
cd /usr/ports/www/squid make make install rehash
تنزيل، كومبايل، تثبيت، دبندنسيز. لكن الأمر rehash مش ضروري. هذا يعتمد على الـshell، بعضهم يقومون بتخزلين الملفات الـتنفيذية في مسار الـpath في hash table لتسريع الـlookup. الهدف منه أن الـsquid binary files تكون accessable كـأوامر. يعني من دون rehash عندما تستخدم shell مثل tcsh لما تكتب squid ثم إنتر يقول command not found. طبعا ممكن تقوم بـlogout/login ويبنيلك الهاش من جديد، لكن مافي داعي أن نحل المشاكل بأسلوب جحا. إذا كتبت rehash سيبنيه لك. وكما قلت هذا له علاقة بالـshell لا أكثر ولا أقل.
ستظهر لك شاشة، بها خصائص يمكنك ان تختارها. قم بإختيار مامعناه: transparent with PF حتى يقوم بكوبايل مع دعم خاصية الشفافية.
طريقة التثبيت اليدوية
المفروض أنك ما تحتاج لهذه الطريقة. لكن إذا كان لديك سبب ما واحتجت التثبيت اليدوي، فهي كالتالي:
./configure --enable-linux-netfilter make make install
لاحظ "--enable-linux-netfilter" هذا مع linux ليدعم الشفافية بواسطة netfilter أو iptables. بالنسبة لنظام freebsd يجب أن تضع "--enable-pf-transparent".
إذا تشابهت عليكم الأمور ممكن تكتب هذا الأمر لتجد لائحة الأوامر:
./configure --help | less
يجب أن تكون عندك اصدارة perl كـdependencis واعتمادا على نظام التشغيل ربما يكون عندك متطلبات أخرى. راجع الرسائل التي تظهر لك وقم بتثبيت الناقص يدويا.
إعدادات شائعة (لكن اختيارية) لخادم Squid
ملاحظة: هذا القسم اختياري، فالإعدادات الإفتراضية ستعمل. لكن إذا أردت زيادة الكفاءة والفائدة _أو_ غذا اتبعت الطريقة اليدوية، فقم بقراءته. في الحالتين فالموضوع أيضا سهل.
حسن يا رجالا كالجبال 
، كل المصائب ستكون في ملف اسمه squid.conf. لكن السؤال: أين هو؟
مع نظام ubuntu وdebian و gentoo سيكون في:
/etc/squid/squid.conf
مع الغرنيق freebsd سيكون في:
/usr/local/etc/squid/squid.conf
نظام freebsd يميز بين مسارات البرامج التي _أنت_ ثبتها، وبين مسارات البرامج التي تأتي مع النظام. فهناك فرق بين /usr/local/etc وبين /etc. واي برنامج تثبته سيظهر في /usr/local/etc. بينما مع لينكس كل شيء في /etc. القضية بسيطة وماهي إلا مسارات مختلفة لا أكثر ولا اقل.
طريقة تنظيم الإعدادات
افتح ملف squid.conf بأي محرر نصوص. وستجد أنه مليء بالملاحظات المسبوقة بعلامة المربع الـ#. فالـdocumentation فيه ممتازة. قبل كل أمر توجد مقدمة وأمثلة، وبعدها تجد الأمر مسبوقا بالـ#. عندما يكون مسبوقا بالـ# يعني وكأنه ممسوح من ملف squid.conf، وفائدته فقط حتى يخبرك أن هذا هو الـdefault
أين يتم تخزين ملفات الكاش؟
افتح ملف squid.conf، وابحث عن cache_dir. وستجد شيئا يشبه هذا:
#Default:
# cache_dir ufs /var/spool/squid 100 16 256
ufs نظام تخزين squid للكاش وموجوزد من زمان. aufs و diskd يخزنون بنفس صيغة ufs لكن الفرق أنهم يتجنبون اغلاق squid process في حال كان الـdisk i/o عاليا. الأول يقوم بفصله بواسطة thread آخر، الثاني يقوم بفصله كـprocess آخر. حاليا سنستخدم ufs للتبسيط.
/var/spool/squid هو المسار الذي يخزن فيه الكاش. 100 حجم الكاش بالبايت. يعني بالإعدادات الإفتراضية 100MB وهذا قليل. أنصحك تخليه أكبر. شخصيا أرى 50000MB جيد (يعتمد على المساحة المتوفرة، دائما خذ أقل من المساحة المتوفرة لتكون في السليم).
16 هو عدد فولدرات الكاش المستوى الأول. 256 هو عدد فولدرات الكاش المستوى الثاني. يعني يوجد عندنا 16 فولدر (مستوى أول)، وداخل _كل_ فولدر منهم يوجد 256 فولدر آخر (مستوى ثاني). وداخل كل فولدر من المستوى الثاني سيتم تخزين ملفات الكاش.
السؤال يقول، مالحكمة من 256 فولدر في 16 فولدر آخر؟ هذا من أجل زيادة سرعة إيجاد الملفات. كلما كان العددين أكبر، كلما زادت السرعة لكن ضاع جزء أكبر من مساحة القرص الصلب. إذا كنت مستخدم مبتدئ لاعليك من هذا ولمعظم الشركات لن تفرق كثيرا.
الفكرة تأتي من أن كل فولدر هو في الحقيقة عبارة عن ملف يحتوي على اسماء الملفات التي بداخله + الـinodes. وإذا زدنا حجم الكاش سيكون لدينا العديد من الـcache object files داخل تلك الملفات، وهكذا سيصبح حجم _ملف_ الفولدر كبير. لاحظ: حجم _ملف_ الفولدر، وليس _محتوى_ الفولدر. وهكذا سيكون ابطأ لأنه حتى يقوم الـfile system بالحصول على الـinode لذلك الـobject سيضطر للبحث في قائمة أكثر طولا.
ليس هذا فحسب، بل أيضا سيتم خلق pointers داخل pointers فقط لوصف ملف الفولدر لأن حجمه كبير والمساحة المتوفرة في كلـinode لوضع الـpointers لا تكفي فيضطر نظام الملفات إلى اتباع أسلوب _شجري_. حيث أن كل pointer موجه إلى block، وكل block عادة 1024Byte. لكن عندما يصبح شجريا فسيكون عندنا pointer على pointer وثم block. هذا أمر طبيعي يحدث مع معظم أنظمة الملفات. لكن أنظمة الملفات الأحدث مثل ext4 و ReiserFS4 تحتوي على خاصية اسمها Extents فهي لا تستخدم خاصية pointer لكل block إنما تضع range وهذا يتجنب هذه المشكلة الأخيرة. للإستزادة حول Extents اقرأ هذا الرابط.
خلاصة الكلام، عندما تزيد حجم الكاش، فكر في زيادة عدد فولدرات المستوى الأول والثاني. وهذا _فقط_ لزيادة السرعة.
فحتى تزيد من حجم الكاش، لزيادة السرعة وارشاد استهلاك الإنترنت:
#Default:
# cache_dir ufs /var/spool/squid 100 16 256
cache_dir ufs /var/spool/squid 50000 32 512
وفي كل حال زيادة عدد الفولدرات مش ضروري. هذا فقط إذا اردت زيادة السرعة. للمستخدم المبتدئ لا تكترث بهذا. كل ماعليك هو زيادة الحجم وأنت مغمض العينين.
كيف أتم خلق ملفات الكاش؟
على نظام ubuntu يحدث تلقائيا. على نظم freebsd أو الطريقة اليدوية ستكتب الأمر:
squid -z
وكل مايقوم به هذا الأمر، بكل بساطة، خلق فولدرات 32 في 512.
بما أننا قمنا بتعديل عدد الفولدرات. أنصح بمسح الكاش القديم، وبنائه من جديد بواسطة squid -z. يعني
rm -r /var/spool/squid/*
squid -z
ماهو الحجم الأقصى لكل cached object؟
ابحث عن الجزئية هذه المسبوقة بالـ# وقم بإضافة التالي
#Default:
# maximum_object_size 8 KB
maximum_object_size 100 MB
هكذا لو نزلت أحد ملف حجمه 100MB وماتحت سيتم تخزينه في الكال. لكن لو نإذا كان حجمه أكثر فلن يتم تخزينه. لأننا لا نريد ضياع الكاش ومسح الملفات السابقة بفضل مستخدم قام بتحميل أفلام كبيرة.
ماذا يحدث لو الكاش full؟
سيتم مسح cached objects أخرى واستبدالها بالـobjects الجديدة. لكن السؤال يقول، بناءا على ماذا؟ أهمهم كالتالي:
- LRU - مفعل افتراضيا. يقوم بإزالة _آخر_ ماتم استدعاؤه من الكاش.
- heap GDSF - يقوم بإزالة الـobjects _الأكبر_ والتي حصلت على frequency أو تكرار للـhit بمعدل أقل. بعبارة أخرى، سيبقى بالكاش ملفات أصغر ذات hit rate أعلى. يعني سيزيد total hit quantity لكن سيقل total hit size
- heap LFUDA - نفس السابق إلا أنه لا يهتم بحجم الملف. لذا زيادة الـmaximum_object_size سيفيد هنا، وسيؤدي إلى زيادة total hit size. هذا نحتاجه لأننا قمنا بزيادة الـmaximum_object_size أيضا. فهما مرتبطين إذا أردنا استخدامهم بشكل جيد.
#Default:
# cache_replacement_policy lru
cache_replacement_policy heap LFUDA
مقدمة حول Transparent Proxy
البروكسيات العادية الغير شفافة، تقوم بالإستماع على منفذ معين، وليكن 8080، او 3128، ولا أي منفذ آخر. في هذه الحالة يجب اعداد جميع متصفحات الإنترنت بإستخدام هذا البروكسي من خلال اعطائه رقم الـip و المنفذ لهذا البروكسي. سواءا يدويا أم آليا. لكن هذه الطريقة لا تجبر المستخدم بإستخدام البروكسي.
كطريقة بديلة، بإمكاننا استخدام البروكسي الشفاف - transparent proxy - والذي بدوره سيقوم بإستقبال الطلبات دون علم المستخدم. يعني من غير اعداد البروكسي في متصفح المستخدم، أو حتى إذا قام بالمستخدم بوضع بروكسي _آخر_ فبالإمكان تحويله بشفايفة إلى البروكسي الشفاف دون علم المستخدم.
وهذا مطبق في عديد من الدول منها مزودة خدمة الإنترنت في الإمارات العربية المتحدة. ولو قام أحدكم بوضع أي بروكسي آخر خارجي على منفذ 8080 فسيجد أنه في الواقع يتم تحويله دون علمه إلى بروكسي تابع لمزودة الخدمة بشفافية.
قبل كل شيء، هناك عدة نقاط يجب معرفتها:
- عندما لا يقوم متصفح الإنترنت بإستخدام أي بروكسي، أي اتصال مباشر بالإنترنت، فإن الطلبات تخرج إلى رقم IP تابع للموقع المطلوب، والمنفذ على الأرجح سيكون 80
- فشكل البكت، على النتورك، سيكون ip.src=client ip.dst=google's_ip tcp.src=random tcp.dst=80
- لكن اذا قمنا بوضع اعدادات بروكسي، فالبكت الخارج من متصفح الإنترنت سيكون متجها إلى البروكسي ومنفذه.
- فبالتالي شكل البكت على النتورك مع اعداد البروكسي سيكون ip.src=client ip.dst=proxy's_ip tcp.src=random tcp.dst=8080
- في الحالتين تم ارسال طلب إلى http://google.com، لكن على مستوى البكت الفرق شاسع.
- في الحالة الأولى (من غير بروكسي)، سيقوم متصفح الإنترنت أيضا بالـDNS resolving لـgoogle.com يعني سنرى DNS بكتس تخرج من الجهاز.
- في الحالة الثانية (مع بروكسي)، لن يقوم متصفح الإنترنت بإستخدام DNS، فكل الذي سيقوم به أنه سيرسل اسم "google.com" هكذا كما هو داخل الطلب، وثم يتولى البروكسي عملية الـname resolving بواسطة الـDNS. لذا لن نشاهد DNS يخرج من جهاز العميل (متصفح الإنترنت). للعلم، حتى لو لم يكن عند العميل خادم DNS سيعمل كل شيء طبيعيا لأن عملية تحويل الdomain name على البروكسي أساسا.
كيف سيعمل البروكسي الشفاف - Transparent Proxy:
- على مستوى النتوورك، بطريقة وبأخرى (سنشرحها لاحقا)، سنقوم بتحويل مسار البكتس إلى البروكسي.
- طبعا ليس كل البكتس، إنما فقط البكتس المشبهوة أنها للمواقع. مثلا منفذ tcp80 و tcp8080 وغيرها من منافذ.
- فصحيح أن المستخدم لا يعلم أن هناك بروكسي شفاف، إلا أن الشبكة ستقوم بتحويل مسار الطلب إلى بروكسي شفاف فالمنتصف دون علمه.
- هذا البروكسي الشفاف سيستقبل البكتس كما هي. يعني بكتس ذاهبة إلى جوجل على منفذ 80، وبكتس ذاهبة إلى بروكسي آخر على منفذ 8080.
- لكن كيف سيقوم البروكسي بمعالجة البيانات بينما هو فقط يتنسط على منفذ معين (مثلا 3128)؟ أحد الإحتمالات هو استخدام port forwarding. وهذا ماسنتكم عنه في هذا الدرس.
- الـport forwarding، سيقوم بتغيير الـdestination IP address والـport numbe إلى localhost:3128
- وبهذه الطريقة سيقوم البروكسي بمعالجته بحكم أن البكت قد تم إرساله إلى المنفذ الذي يتنسط عليه.
- لكن هناك سؤال، إذا خطر فبالك فهذا دليل أنك مصحصح: بعدما يتم تحويل رقم الـIP والمنفذ ليشير إلى البروكسي، مثلا google_ip تحول إلى localhost_ip، ومنفذ 80 تحول إلى منفذ 3128. فكيف سيقوم البروكسي أن المستخدم أراد دخول جوجل ولا ياهو؟ الآي بي تغير!
- الحل هو من خلال API يستخدمه Squid. مثلا عندما قام IPTABLES أو PF بتحويل مسار البكت، فبإمكان Squid معرفة الأرقام القديمة الصحيحة من خلال ذلك الـAPI
- ولهذا السبب، وقت الـcompile بالطريقة اليدوية، عليك تحديد اسم الحائط الناري الذي ستستخدم معه Transparent Proxy. إذا كنت تستخدم IPTABLES بيجب عليك اخباره بذلك. اذا كنت تريد استخدام PF فيجب عليك اخباره بذلك وقت الـcompiling. النسخة الموجودة مع Debian تم compile لتعمل مع IPTABLES، لهذا السبب لا مشكلة. بينما نسخة الـFreeBSD يجب عليك وقت الـcompiling ووضع علامة "صح" بجوار Transparent with PF إذا كنت تستخدمه.
- هكذا عندما يستقبل البروكسي البكت، صحيح أن الـdestination ip مختلف، إلا أنه سيتمكن من معرفة الرقم الحقيقي قبل الـport forwarding بواسطة تلك الـAPI التي تعتمد على الحائط الناري المستخدم.
- الفائدة من استخدام الـAPI مهم في حالة كان العميل لم يقم بوضع بروكسي. أي اتصال مباشر. لأنه معيار HTTP القديم لم يقم بوضع hostname، فالطريقة الوحيدة لجعله يعمل هو من خلال معرفة destination IP والذي نحتاج إلى تلك الـAPI لمعرفته. بينما إذا قام المستخدم بوضع بروكسي، فلا داعي لإستخدام تلك الـAPI لأن الجهة المطلوبة سيتم وضعها في الـبكت.
- الـAPI هذه تعمل بشفافية تامة وأنا تكلمت عنها حتى تفهم مايحدث ولا تستغرب من هذا السحر في منتهى الجمال، حفاظا على بقية شعرك من التساقط. بعبارة أخرى شعر راسي تساقط بالنيابة عن شعر رأسك. شعر الرأس مهم في معظم المجتمعات.
- إذا تساقط شعر راسك فالعلاج صعب. مثلا هناك 5a-reductase inhibitors لكنها تؤدي إلى مشاكل أخرى في الهرمونات مثل انخفاض نسبة dihydrotestosterone في الدم. يعني سيكون عندك testosterone لكن لن يتحول إلى الصورة الفعالة، بالتالي فقدان الرجولة شيئا فشيئا. لذا أفضل شيء هو شامبو مضاد للقشرة. لكن هذا خارج الدرس على كل حال.
إعداد خادم Squid وتشغيله كـtransparent proxy
اعداد squid
افتح ملف squid.conf، واكتب التالي:
# Squid normally listens to port 3128
http_port 3128 transparent
وثم نشغل خادم Squid بواسطة init scripts على لينكس:
/etc/init.d/squid start
أو بواسطة rc scripts على Freebsd
/usr/local/etc/rc.d/squid start
الفكرة نفسها لكن مسار الـscript مختلف. طبعا ممكن تشغيله من دون اسكربت، يعني تكتب "squid" وكفى لكن لا أنصح بهذا.
اعداد الحائط الناري على خادم squid
هنا يجب علينا إضافة قوانين في iptables تقوم بتحويل مايأتي على tcp 80 و tcp 8080 إلى منفذ localhost:3128 tcp
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128
وإذا كنا نستخدم freebsd او غيرها من مشتقات bsd فسنقوم بنفس الشيء لكن بواسطة PF:
rdr pass on fxp0 proto tcp from any to any port 80 -> localhost port 3128
هذا تكتبه في ملف pf.conf والذي مساره معرف في /etc/rc.conf
cat /etc/rc.conf | grep pf_
pf_enable="YES"
pf_rules="/etc/pf.conf"
فمثلا، هنا عندنا الملف في مجلد etc واسمه pf.conf. لذا نضع اعدادات PF فيها. وكما قلت هذا فقط لأنظمة BSD التي تستخدم حائط نار PF فقط.
إعداد الشبكة لتطبيق Transparent Forward Proxy
كما تشاهد في الرسمة التوضيحية. الذي يربط الشبكة ببعضها هو الـcollapsed core-distribution switch. وفي هذه الحالة هذا هو أيضا الـRouter. في حال كان تصميم الشبكة مختلفا لا مشكلة. كل ما عليك هو تطبيق خاصية policy-based routing على الrouter الذي يربط الـشبكات المختلفة ببعضها البعض، ومنها الشبكة التي بها Squid.
ماذا يعني Policy-Based Routing
محولات الشبكة، أو الـRouters، بالإعدادات الإفتراضية، تقوم بتحويل مسارات الـpackets بناء على destination IP address. يعني بعبارة أخرى، ممكن نقول IP destination-based Routing (تسمية غير شائعة فقط للتوضيح).
بينما مع الـPolicy-Based Routing، فبإمكاننا اخبار محول الشبكة (router) باختيار المسار المطلوب، بناء على معلومات أخرى كالـ:
- Src TCP
- Dst TCP
- Src UDP
- Dst UDP
- IPP, DSCP يعني QoS Bits
- ICMP
- وغيره من طرق ممكن تتفلسف فيها بناء على access-lists كما تشاء.
الخلاصة أن القضية مع الـPolicy-Based Routing مرنة. ونحن في الـTransparent Squid Proxy سنطلب من محول الشبكة، أو الـcollapsed core-dist L3 switch بتحويل أي شيء متجه إلى منفذ TCP 80 و TCP 8080 إلى خادم البروكسي لدينا. والنتيجة ستكون كالتالي:
- أي مستخدم لم يقم بوضع اعدادات البروكسي، سيمر من خلال Squid proxy دون علمه بشفافية تامة بالنسبة له
- أي مستخدم، قام بوضع بروكسي آخر، يستخدم مثلا منفذ 8080 سيتم أيضا تحويله دون أن يدري إلى Squid بشفافية تامة بالنسبة له
- طبعا بإمكاننا إضافة منافذ أخرى شائعة مثل 8181
- أو حتى بواسطة استخدام Access-List يقوم بتحديد بروكسيات بوجه التحديد، مثلا source IP any, destination IP=badproxies.com destination port:80 - لاحظ أنه هذا البروكسي يستخدم منفذ شائع وهو 80، لكننا بواسطة تحديد رقم الآي بي بإمكاننا استخراجه كالشعرة من العجين وإلزام مستخديمنا بالدخول من Squid بشفافية دون علمهم حتى لو قاموا بإختيار ذلك البروكسي.
إعداد Policy-Based Routing
الإعداد كذلك سهل، اتبع هذه الخطوات. أول خطوة: نعلم الراوتر، ماذا يعني www traffic، وذلك من خلال access-list عادية.
router#configure terminal
router(config)#ip access-list extended WWW-TRAFFIC
router(config-ext-nacl)#deny ip host 10.2.0.1 any
router(config-ext-nacl)#permit tcp any any eq www
أنصح بإستخدام named access-lists لأنها ستريحك مستقبلا لما تعدل فيها.
لماذا وضعت deny ip host 10.2.0.1 any؟ لأن 10.2.0.1 هو رقم IP البروكسي. ويجب اخراجه. إذا لم أقم بإخراجه، حينها سيحدث لدينا loop بين البروكسي والراوتر إلى أن ينتهي ttl = 0.
لماذا وضعت permit tcp any any eq www؟ هذا لأنني أريد على الجميع المرور بالبروكسي. لكن إذا كنت تريد تخصيص قسم محدد، فتستطيع تصغير الدائرة وذكر الشبكات التي تريد فقط.
ملاحظة: عندما نقول deny لا يحدث drop للبكت. إنما وفقط يحدث normal routing وليس policy-based routing. فـpermit يعني policy-based routing، وdeny يعني normal routing.
وثم نقول للراوتر: آلية الـتحويل الـwww-traffic إلى squid proxy.
router#configure terminal
router(config)#route-map FORCE-TRANS-PROXY
router(cconfig-route-map)#match ip address WWW-TRAFFIC
router(cconfig-route-map)#set ip next-hop 10.2.0.1
لاحظ أن هذا فقط آلية التحويل. حتى الآن لم نطبق أي شيء.
حتى نطبقه نطبق التالي على الـinbound interface. المنفذ الذي _يستقبل_ البكت من المستخدمين. في هذا الدرس المستخدمين مشبوكين على vlan 10، لذا نطبقه هناك. لكن إذا كان لديك عدة vlans للمستخدمين وعدة SVI يجب عليك تطبيقها على كل SVI.
router#configure terminal
router(config)#interface vlan 10
router(cconfig-if)#ip policy route-map FORCE-TRANS-PROXY
ومبروك عليك الـTransparent Squid Proxy. الدعم الفني مجانا هدية من قسم الشبكات بالفريق العربي للبرمجة بمناسبة العيد :).
