🌴 🤸🏾 🚌 वेब ट्रैफिक कैशिंग पर एक और लेख 💈 ⚱️ 🕵🏾

परिचय, या हमें WCCP पर एक और लेख की आवश्यकता क्यों है?

WCCP प्रोटोकॉल का उपयोग करके वेब ट्रैफ़िक के पारदर्शी कैशिंग के संगठन के बारे में बहुत कुछ लिखा गया है, जिसमें हब पर एक अच्छा लेख भी शामिल है आमतौर पर, इन लेखों में, बाईं ओर की आकृति में दिखाए गए के समान एक योजना पर विचार किया जाता है।

पहली नज़र में, समाधान के ठोस फायदे हैं: कार्यान्वयन सरल है, कैशिंग उपयोगकर्ताओं के लिए बिल्कुल पारदर्शी है, अगर प्रॉक्सी सर्वर विफल हो जाता है, तो अनुरोध स्वचालित रूप से सीधे रीडायरेक्ट हो जाएंगे।

लेकिन क्या WCCP हमेशा सुचारू रूप से चल रहा है? और यदि नहीं, तो उभरते मुद्दों से कैसे निपटें?

उदाहरण के लिए, लगभग सभी लेखों में उल्लेख किया गया है कि कैश सर्वर उपयोगकर्ताओं के समान खंड में होना चाहिए, लेकिन इसके कारण निर्दिष्ट नहीं हैं। लेकिन क्या होगा यदि सुरक्षा नीति के लिए आवश्यक है कि सभी सर्वर परिधि नेटवर्क में हों और एक फ़ायरवॉल द्वारा संरक्षित हों?

हाल ही में, मुझे दूरसंचार ऑपरेटर के नेटवर्क में एक कैशिंग सर्वर स्थापित करते समय एक समान आवश्यकता से निपटना पड़ा, जिसका एक सरल आरेख दाईं ओर शीर्षक चित्र में दिखाया गया है।

अगर पाठकों की रुचि है कि ऐसी योजनाओं को लागू करते समय वे किन समस्याओं का सामना करते हैं, और सीमाओं के आसपास कैसे पहुंचें, स्वागत है।

सिद्धांत - मानक और कार्यान्वयन सुविधाएँ

पहला, थोड़ा सिद्धांत। WCCP प्रोटोकॉल को वास्तविक समय में ट्रैफ़िक (न केवल वेब) पर पुनर्निर्देशित करने के लिए डिज़ाइन किया गया है। प्रोटोकॉल मूल रूप से सिस्को द्वारा विकसित किया गया था, फिर यह एक खुला मानक बन गया जिसका उपयोग अधिकांश विक्रेताओं द्वारा किया जाता है।

आज, संस्करण 2, जो इंटरनेट-ड्राफ्ट की स्थिति में है और ड्राफ्ट-मैक्लेगन-डब्ल्यूसीपी-वी 2 आरवी 1-00 द्वारा वर्णित है , प्रासंगिक है ।

आइए हम इस प्रोटोकॉल के संचालन में कई महत्वपूर्ण बिंदुओं पर ध्यान दें (आंकड़ा देखें)।

सभी WCCP संदेश 2048 के गंतव्य पोर्ट नंबर के साथ UDP पैकेट हैं। संदेश का क्रम इस प्रकार है:

यदि सर्वर ट्रैफ़िक कैशिंग अनुरोधों को संसाधित करने के लिए तैयार है, तो यह WCCP2_HERE_I_AM संदेश भेजता है।
राउटर सर्वर को WCCP2_I_SEE_YOU संदेश भेजता है जिसमें सेटिंग्स के बारे में जानकारी होती है, विशेष रूप से, "आईडी प्राप्त करें" फ़ील्ड।
प्रतिक्रिया में सर्वर एक और संदेश WCCP2_HERE_I_AM भेजता है, जिसमें पिछले चरण के समान "प्राप्त आईडी" फ़ील्ड होता है, जिससे यह पुष्टि होती है कि यह राउटर के साथ काम करने के लिए तैयार है।
ऐसा संदेश प्राप्त करने के बाद, राउटर समझता है कि इस क्षण से वेबसाइटों के लिए उपयोगकर्ता के अनुरोधों को कैश सर्वर पर पुनर्निर्देशित किया जाना चाहिए।

सिस्टम जाने के लिए तैयार है। WCCP2_HERE_I_AM और WCCP2_I_SEE_YOU मैसेजिंग प्रक्रिया समय-समय पर (डिफ़ॉल्ट रूप से, प्रत्येक 10 सेकंड में) दोहराई जाती है, और यदि राउटर को कैश सर्वर से प्रतिक्रिया नहीं मिलती है, तो बाद वाले को प्रक्रिया से बाहर रखा गया है।
वास्तव में, प्रोटोकॉल कुछ अधिक जटिल है, यह प्रमाणीकरण, विभिन्न पुनर्निर्देशन एल्गोरिदम, आदि प्रदान करता है, लेकिन हम जानबूझकर उन विवरणों को छोड़ देंगे जो आगे की समझ के लिए महत्वहीन हैं। इच्छुक पाठक उन्हें संबंधित ड्राफ्ट में पा सकते हैं, जिसका लिंक ऊपर दिया गया है।

इस तरह के कार्यान्वयन से समाधान की गलती सहनशीलता में योगदान होता है - यदि कैश सर्वर विफल हो जाता है और WCCP2_HERE_I_AM संदेश भेजना बंद कर देता है, तो राउटर पैकेट को आगे बढ़ाने और उन्हें सीधे इंटरनेट पर भेजना बंद कर देगा। सेवा बहाल होने के बाद, WCCP2_HERE_I_AM / WCCP2_I_SEE_YOU मैसेजिंग प्रक्रिया दोहराई जाएगी, और कैशिंग योजना फिर से काम करना शुरू कर देगी।

उपयोगकर्ताओं के लिए, इस तरह के इनकार या तो पूरी तरह से अदृश्य है, या यह एक बार "कनेक्ट करने में असमर्थ" संदेश की तरह लग सकता है, जो ब्राउज़र में पेज को फिर से लोड किए जाने के बाद गायब हो जाएगा।

Wireshark में, WCCP मैसेजिंग प्रक्रिया दिखाई देती है जैसा कि निम्न आकृति में दिखाया गया है। टाइम कॉलम पर ध्यान दें। ट्रैफ़िक छवि एक वास्तविक दुनिया प्रणाली से ली गई है, इसलिए सुरक्षा उद्देश्यों के लिए आईपी पते को काट दिया जाता है।

आइए देखें कि जब कोई क्लाइंट वेब सर्वर से डेटा प्राप्त करने की कोशिश करता है तो क्या होता है। स्पष्टता के लिए, हम उदाहरणों में उपयोग के लिए आवंटित विशेष श्रेणियों का उपयोग करके मेजबानों को विशिष्ट आईपी पते प्रदान करेंगे, और सादगी के लिए, हम सभी अनावश्यक कार्यक्षमता (एनएटी, फ़ायरवॉल, आदि) को विचार से बाहर कर देंगे।

उपयोगकर्ता ब्राउज़र SRC IP 198.51.100.150, DST IP 192.0.2.20, DST TCP पोर्ट 80, TCP SYN ध्वज के साथ एक पैकेट भेजकर एक टीसीपी सत्र आरंभ करता है।
इस तरह के एक पैकेट को प्राप्त करने के बाद, राउटर इसे इंटरनेट पर आगे नहीं भेजता है, लेकिन इसे पूरी तरह से जीआरई पैकेट में पैक करता है और इसे कैश सर्वर को भेजता है। GRE पैकेट में क्रमशः SRC IP 192.51.100.1 और DST IP 198.51.100.100 है। विंडशार्क में, यह निम्न आकृति जैसा दिखता है।
इस तरह के एक पैकेट को प्राप्त करने के बाद, सबसे पहले कैश सर्वर यह तय करता है कि वह इस पैकेट को प्रोसेस करेगा या नहीं। यदि नहीं, तो पैकेट को उसी जीआरई सुरंग के माध्यम से सामान्य अग्रेषण के लिए राउटर में वापस भेजा जाता है, और एल्गोरिथ्म समाप्त होता है। यदि हाँ, तो सर्वर अगले चरण के लिए आगे बढ़ता है।
कैशिंग सर्वर अपनी ओर से वेब सर्वर के साथ एक संबंध स्थापित करता है, जिसके लिए वह SRC IP 198.51.100.100, DST IP 192.0.2.20, DST TCP पोर्ट 80, TCP SYN ध्वज के साथ एक पैकेट भेजता है।
जवाब में, वेब सर्वर SRC IP 192.0.2.20, SRC TCP पोर्ट 80, DST IP 198.51.100.100, TCP SYN / ACK झंडे के साथ एक पैकेट भेजता है, यानी जब तक कि तीनों का उपयोग करके एक TCP सत्र की सामान्य शुरुआत के अनुसार सब कुछ नहीं हो जाता। रास्ता हाथ मिलाना।
कैशिंग सर्वर, वेब सर्वर से प्रतिक्रिया प्राप्त करता है, दो काम करता है:
- SRC IP 198.51.100.100, DST IP 192.0.2.20, DST TCP पोर्ट 80, ACK ध्वज के साथ वेब सर्वर को एक पैकेट भेजता है, अर्थात, यह सामान्य TCP सत्र जारी रखता है, जो वेब सर्वर के लिए लगता है कि इसे एक नियमित रूप से एक्सेस किया गया था। आईपी पते के साथ ग्राहक 198.51.100.100।
- एसआरसी आईपी 192.0.2.20, एसआरसी टीसीपी पोर्ट 80, डीएसटी आईपी 198.51.100.150, टीसीपी SYN / ACK झंडे के साथ वेब क्लाइंट को एक पैकेट भेजता है, यानी क्लाइंट के लिए, स्थिति ऐसी लगती है जैसे कि वेब सर्वर ने सीधे जवाब दिया। इस क्षण को याद रखें, यह आगे की समझ के लिए महत्वपूर्ण है।
तो, हमारे पास दो स्थापित टीसीपी सत्र हैं, एक ग्राहक और कैश सर्वर के बीच और दूसरा कैश सर्वर और वेब सर्वर के बीच। कैश सर्वर सामान्य रूप से वेब सर्वर से सामग्री प्राप्त करता है, इसे क्लाइंट को प्रसारित करता है, साथ ही इसे मेमोरी में या (और) डिस्क पर संग्रहीत करता है।
एक ही सामग्री के बाद के उपयोग पर, कैशिंग सर्वर, कुछ शर्तों के अधीन, अपने वेब सर्वर को फिर से पंप करने में सक्षम नहीं होगा, लेकिन इसे वेब क्लाइंट को स्वयं देने के लिए।

वर्णित एल्गोरिदम को आंकड़े में योजनाबद्ध रूप से दिखाया गया है।

कई महत्वपूर्ण बिंदुओं पर ध्यान दें:

जीआरई सुरंग के अंदर के पैकेट मुख्य रूप से राउटर से कैश सर्वर को भेजे जाते हैं (जब तक कि कैश सर्वर पैकेट को संसाधित नहीं कर सकता और सामान्य अग्रेषण के लिए राउटर में वापस भेज देता है)।
विपरीत दिशा में, अर्थात्, कैश सर्वर से वेब क्लाइंट तक, पैकेट सीधे भेजे जाते हैं, आमतौर पर राउटर को दरकिनार करते हैं।
कैशिंग सर्वर वेब क्लाइंट के लिए पैकेट के लिए पता निर्धारित नहीं करता है, लेकिन उस वेबसाइट का पता जिसके लिए अनुरोध किया गया था।

प्रोटोकॉल का ऐसा कार्यान्वयन राउटर पर लोड को काफी कम कर देता है, क्योंकि इसमें केवल वेब क्लाइंट से वेब सर्वर पर ट्रैफ़िक को पुनर्निर्देशित करना होता है, जिसका वॉल्यूम आमतौर पर छोटा होता है। एक वेब सर्वर से ट्रैफ़िक, जिसकी मात्रा आमतौर पर महत्वपूर्ण है, किसी भी जटिल प्रसंस्करण के अधीन नहीं है - यह बस रूट किया गया है।

लेकिन ऐसा कार्यान्वयन असममित यातायात बनाता है, जो बदले में, अगले अनुभाग में चर्चा की गई जटिलता पैदा करता है।

अभ्यास - राउटर और फायरवॉल से लड़ना

हम पिछली योजना को संशोधित करते हैं - हम कैश सर्वर को फ़ायरवॉल के पीछे रखते हैं:

हम मानेंगे कि हम लोकप्रिय उपकरणों का उपयोग करते हैं - सिस्को IOS सॉफ्टवेयर संस्करण 12.3 और उच्चतर के साथ एक सिस्को राउटर, सॉफ्टवेयर संस्करण 8.2 और उच्चतर के साथ एक सिस्को एएसए फ़ायरवॉल, एक लिनक्स-आधारित कैश सर्वर (आरएचईएल या सेंटो वितरण) और स्क्वाश कैशिंग सॉफ़्टवेयर।
इस मामले में सब कुछ कैसे कॉन्फ़िगर करें? मान लीजिए कि बुनियादी कार्यक्षमता पहले से ही कॉन्फ़िगर की गई है, अर्थात, वेब क्लाइंट और कैश सर्वर इंटरनेट पर संसाधनों का उपयोग करने में सक्षम हैं। आइए सिस्को पर WCCP की स्थापना करके शुरू करते हैं।

हम प्रारंभिक कार्य करेंगे, जिसके लिए हम दो अभिगम सूचियाँ बनाएंगे:

ip access-list standard l_wccp_service permit 203.0.113.100 ip access-list extended l_wccp_redirect permit tcp host 198.51.100.150 any eq www

पहले निर्धारित करता है कि कौन से कैशिंग सर्वरों को WCCP2_HERE_I_AM संदेश प्राप्त करने की अनुमति है।
दूसरा यह निर्धारित करता है कि कैश सर्वर पर ट्रैफ़िक को क्या लपेटा जाना चाहिए।

हम WCCP को कॉन्फ़िगर करेंगे और इसे आंतरिक उपयोगकर्ताओं की तलाश में इंटरफ़ेस पर सक्षम करेंगे, अर्थात, पता 198.51.100.1 होगा। निश्चितता के लिए, इसे FastE ईथरनेट0 / 0 होने दें:

 ip wccp web-cache redirect-list l_wccp_redirect group-list l_wccp_service interface FastEthernet0/0 ip wccp web-cache redirect in

फ़ायरवॉल पर, हम WCCP और GRE पैकेट को राउटर और कैश सर्वर के बीच आदान-प्रदान करने की अनुमति देते हैं।

 access-list l_wccp extended permit gre host 198.51.100.1 host 203.0.113.100 access-list l_wccp extended permit udp host 198.51.100.1 host 203.0.113.100 access-group l_wccp in interface outside

अब कैशिंग सर्वर को कॉन्फ़िगर करें। सबसे पहले, स्क्वीड को स्थापित और कॉन्फ़िगर करें, जिसके लिए अपने पसंदीदा टेक्स्ट एडिटर का उपयोग करके /etc/squid/squid.conf फ़ाइल खोलें और यह सुनिश्चित करें कि इसमें निम्न पंक्तियाँ हैं:

 # /etc/squid/squid.conf http_port 3128 transparent wccp2_router 198.51.100.1 wccp2_forwarding_method 1 wccp2_return_method 1 wccp2_assignment_method hash wccp2_service standard 0

आइए एक सुरंग इंटरफ़ेस बनाएं, जिसके लिए, फिर से, हमारे पसंदीदा संपादक में, निम्नलिखित सामग्री के साथ फ़ाइल / etc / sysconfig / network-script / ifcfg-tun0 बनाएं:

 # /etc/sysconfig/network-scripts/ifcfg-tun0 DEVICE=tun0 BOOTPROTO=none ONBOOT=yes TYPE=GRE PEER_OUTER_IPADDR=198.51.100.1 PEER_INNER_IPADDR=192.168.168.1 MY_INNER_IPADDR=192.168.168.2

IP पते PEER_INNER_IPADDR और MY_INNER_IPADDR बिल्कुल हो सकते हैं - सामान्य तरीके से इस सुरंग के माध्यम से कुछ भी रूट नहीं किया जाएगा। इसके बजाय, DST पोर्ट 80 के साथ आने वाले सभी TCP ट्रैफ़िक को iptables का उपयोग करके स्क्वीड पर लपेटा जाएगा। यह मानते हुए कि स्क्वीड पोर्ट 3128 पर प्रतिक्रिया दे रहा है, हम सुरंग का इंटरफ़ेस बढ़ाएँगे और स्क्वीड पर आवश्यक ट्रैफ़िक को लपेटेंगे:

 /etc/sysconfig/network-scripts/ifup tun0 iptables -t nat -A PREROUTING -i tun0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 203.0.113.100:3128 /etc/init.d/iptables save

सत्यापित करें कि कैश सर्वर ने राउटर के साथ पंजीकरण किया है:

 cisco# show ip wccp Global WCCP information: Router information: Router Identifier: 198.51.100.1 Protocol Version: 2.0 Service Identifier: web-cache Number of Service Group Clients: 1 Number of Service Group Routers: 1 Total Packets s/w Redirected: 175623 Process: 0 Fast: 0 CEF: 175623 Redirect access-list: l_wccp_redirect Total Packets Denied Redirect: 113892411 Total Packets Unassigned: 20590 Group access-list: l_wccp_service Total Messages Denied to Group: 26558 Total Authentication failures: 0 Total Bypassed Packets Received: 0

यहां हम एक अप्रिय घात की उम्मीद कर सकते हैं: एक राउटर में आमतौर पर विभिन्न आईपी पते के साथ कई इंटरफेस होते हैं। और कुछ भी उसे एक इंटरफ़ेस के SRC IP से WCCP2_I_SEE_YOU पैकेट और दूसरे इंटरफ़ेस के SRC IP से GRE पैकेट भेजने से रोकता है।
कुछ में, लेकिन सिस्को IOS रूटर्स के फर्मवेयर के सभी संस्करण नहीं, कमांड "आईपी wccp स्रोत-इंटरफ़ेस" प्रदान किया गया है, जो आपको इंटरफ़ेस को हार्ड-सेट करने की अनुमति देता है जिसका आईपी पता WCCP सबसिस्टम से संबंधित सभी पैकेटों के लिए SRC IP के रूप में उपयोग किया जाएगा। ।

यदि आपका राउटर इस कमांड का समर्थन करता है, तो आप भाग्य में हैं। इसे चलाएं:

 ip wccp source-interface FastEthernet 0/0

अगर, ऐसे आदेश के जवाब में, राउटर "सिंटैक्स त्रुटि" जैसा कुछ उत्पन्न करता है, तो हम निम्नानुसार आगे बढ़ते हैं - ME पर एक डायग्नोस्टिक चलाते हैं, और कैश सर्वर पर कुछ नेटवर्क विश्लेषक (कम से कम tcpdump) और पता करते हैं कि आईपी पते से आते हैं। WCCP पैकेज, और जिसके साथ जीआरई पैकेज।

इसके बाद, स्क्वीड सेटिंग्स में, टनल इंटरफेस और iptables सेटिंग्स में पहला आईपी पता निर्दिष्ट करें - दूसरा। हम तदनुसार एमई पर पहुंच सूचियों को संशोधित करते हैं।

IP पते को रोकने के लिए जिसमें WCCP पैकेट राउटर के बाद के पुनर्गठन के दौरान इंटरफेस के बीच आते हैं, आप पिछले एक पर लूपबैक इंटरफ़ेस बना सकते हैं। इस मामले में, WCCP अपने पैकेट भेजने के लिए सभी लूपबैक इंटरफेस के बीच सबसे बड़े आईपी पते का उपयोग करेगा।

 interface lo0 ip address 198.51.100.20 255.255.255.255

सत्यापित करें कि रीडायरेक्ट कार्य करता है। सबसे पहले, सुनिश्चित करें कि पैकेट पहले से बनाई गई एक्सेस सूचियों में गिना जाता है:

 cisco# show access-list l_wccp_redirect Extended IP access list l_wccp_redirect 10 permit tcp host 198.51.100.150 any eq www (2399 matches)

फिर क्लाइंट मशीन के ब्राउज़र में एक मनमाना वेब पेज खोलें। और निश्चित रूप से कुछ भी नहीं चलेगा। जब यह पता लगाने की कोशिश की जा रही है, तो हम शायद इस प्रकार के बारे में फ़ायरवॉल के लॉग में संदेश पाएंगे:

 %ASA-4-313004: Denied ICMP type=0, from 192.0.2.20 on interface dmz to 198.51.100.150: no matching session

यदि हम Google पर जाने का प्रयास करते हैं, तो पहला लिंक हमें असममित रूटिंग के बारे में कुछ बताएगा। आइए जानें इसका क्या मतलब है।
सिस्को एएसए फ़ायरवॉल एक स्टेटफुल इंस्पेक्शन डिवाइस है, जो कि कैश सर्वर से क्लाइंट के लिए टीसीपी SYN / ACK झंडे के साथ एक पैकेट पास करने के लिए, आपको पहले ग्राहक से TCP SYN ध्वज वाला संबंधित पैकेट होना चाहिए। उसी एमई के माध्यम से वेबसाइट आगे बढ़ी।

इस स्थिति में, ME समझ जाएगा कि क्लाइंट ने एक TCP सत्र शुरू किया है, उपयुक्त आंतरिक संरचनाएँ बनाएगा और इस TCP सत्र की स्थिति की सही निगरानी करना शुरू करेगा।

हमारी योजना में, SYN पैकेट को एमई ए) जीआरई सुरंग के अंदर से गुजरता है और बी) "जैसे कि गलत दिशा में है।"
तदनुसार, ME अपनी कनेक्शन तालिका में एक टीसीपी सत्र शुरू नहीं करता है और यह नहीं समझ सकता है कि सत्र शुरू हो गया है, और इसके पैकेट को छोड़ दिया जाना चाहिए।

ऐसी स्थिति में क्या करें? यदि ME को दरकिनार करते हुए कैशिंग सर्वर को जोड़ना असंभव है, तो यह DMZ पक्ष से आने वाले पैकेट के लिए एक खुले टीसीपी सत्र के लिए चेक को अक्षम करने के लिए ही रहता है।

सिस्को एएसए में, सत्यापन अक्षम सुविधा को टीसीपी बाईपास कहा जाता है। फ़ंक्शन की सीमाएँ हैं:

सॉफ्टवेयर संस्करण 8.2 या इससे पहले के सिस्को एएसए पर काम नहीं करता है।
ज्ञात नहीं है (कम से कम, हम क्लाइंट ज़ोन और डीएमजेड दोनों को एक ही सिस्को एएसए मॉडल एमई पर व्यवस्थित करने के तरीके को खोजने में असमर्थ थे) - आईपी पते के अनुवाद अनुमान से काम नहीं करते हैं।

तो, TCP बायपास फ़ंक्शन सक्षम करें:

 access-list l_bypass extended permit tcp any eq www host 198.51.100.150 class-map c_bypass match access-list l_bypass policy-map p_bypass class c_bypass set connection advanced-options tcp-state-bypass service-policy p_bypass interface dmz

L_bypass एक्सेस सूची में क्लाइंट IP पतों की एक सीमा होनी चाहिए।

अब सब कुछ काम करना चाहिए। कम से कम इसने हमारे लिए काम किया।

निष्कर्ष

लेख एक छोटे से टेलिकॉम ऑपरेटर के नेटवर्क में वेब ट्रैफ़िक को कैशिंग करने के कार्य को लागू करने के अनुभव पर आधारित है, और एक बार फिर एक नेटवर्क इंजीनियर के काम में दो पुराने सिद्धांतों को दिखाता है:

प्रोटोकॉल के मानकों और विवरणों की उपेक्षा न करें;
यदि आप यह नहीं समझ पा रहे हैं कि क्या हो रहा है, तो बहुत आलसी न हों, नेटवर्क एनालाइज़र में प्लग करें।

सफल परीक्षण और कार्यान्वयन! और अभी और हमेशा अपने चैनलों को अधिक से अधिक अतिरिक्त यातायात के लिए परिवहन करने दें।

वेब ट्रैफिक कैशिंग पर एक और लेख

परिचय, या हमें WCCP पर एक और लेख की आवश्यकता क्यों है?

सिद्धांत - मानक और कार्यान्वयन सुविधाएँ

अभ्यास - राउटर और फायरवॉल से लड़ना

निष्कर्ष

More articles: