Squid के ज़रिए एक VPN एंडपॉइंट: एक सीमित CONNECT अपवाद

Squid किसी CONNECT अनुरोध का उत्तर उस पहली http_access पंक्ति से देता है जो मेल खाती है, और वह पंक्ति कोई अस्वीकृति भी हो सकती है। यही एक तथ्य समझाता है कि VPN एंडपॉइंट के लिए अपवाद आम तौर पर पहले प्रयास में क्यों विफल होता है, क्योंकि अनुरोध कभी उस अनुमति तक नहीं पहुँचता जिसे किसी ने सबसे नीचे जोड़ा था। एक सीमित सुधार मौजूदा पोर्ट गार्ड रखता है और उन्हें एक समीक्षित स्रोत, गंतव्य और पोर्ट के बारे में सिखाता है। प्रॉक्सी पर बाकी सब कुछ ठीक वैसे ही व्यवहार करता है जैसे पहले करता था।

Squid किसी CONNECT अनुरोध का निर्णय कैसे करता है

एक CONNECT अनुरोध किसी होस्ट और पोर्ट का नाम देता है, और Squid http_access पंक्तियों को क्रम से तब तक देखता है जब तक उनमें से कोई मेल न खाए। मेल खाती अस्वीकृति मूल्यांकन को तुरंत समाप्त कर देती है और क्लाइंट को प्रॉक्सी से 403 मिलता है। इसीलिए किसी नियम की स्थिति उसके शब्दों से अधिक मायने रखती है। उसी पंक्ति को एक कदम ऊपर खिसकाना परिणाम पूरी तरह बदल सकता है।

पारंपरिक गार्ड Safe_ports के बाहर की हर चीज़ को अस्वीकार करते हैं और SSL_ports के बाहर CONNECT को अस्वीकार करते हैं। ये नाम आपकी अपनी कॉन्फ़िगरेशन में परिभाषित ACL हैं, इसलिए उनकी सामग्री प्रोटोकॉल की नहीं, आपकी है। कोई वितरण Safe_ports के रूप में पोर्ट की व्यापक श्रेणी की अनुमति दे सकता है और CONNECT को अलग से सीमित कर सकता है। यह मानने से पहले कि कोई पोर्ट डिज़ाइन से अवरुद्ध है, जीवंत मान पढ़ें।

पुष्टि करें कि प्रॉक्सी ही वह घटक है जो अनुरोध को अस्वीकार कर रहा है। Squid द्वारा बनाया गया 403 VPN सर्वर की TLS चेतावनी जैसा बिल्कुल नहीं दिखता, और दोनों को एक समस्या में मिला देने पर पहला घंटा चला जाता है। अनुरोध के लिए एक्सेस लॉग की पंक्ति देखें, क्योंकि वह क्रिया और उसे पैदा करने वाला नियम दोनों दर्ज करती है।

तीन अलग ACL के बजाय एक संयुक्त मिलान बनाएँ

अपवाद को तीन तथ्यों से बनाएँ: एक स्वीकृत स्रोत श्रेणी, एक स्वीकृत गंतव्य पता और वह एकमात्र पोर्ट जिस पर एंडपॉइंट सुनता है। दो अलग ACL और एक संयुक्त मिलान बहुत अलग नीति बनाते हैं, क्योंकि मूल्यांकन संयोजन का होता है। संयुक्त ACL का नाम उस बात पर रखें जिसकी वह अनुमति देता है, न कि उस विधि पर जिसे वह वहन करता है।

नीचे दिया गया स्वरूप दस्तावेज़ीकरण श्रेणियों का उपयोग करता है जिन्हें समीक्षित मानों से बदलना होगा। Squid इनमें से कोई भी नाम अपने लिए आरक्षित नहीं रखता, इसलिए उन्हें चुनना और सुसंगत रखना आपका काम है। यह विधि Squid 6 और 7 तक सीमित है, जिनकी प्रलेखित कॉन्फ़िगरेशन all-of समूह का समर्थन करती है। वर्तमान संदर्भ उन निर्देशों को Squid 8 में अनुपलब्ध बताता है, इसलिए इसे संस्करण-बद्ध विधि मानें, माइग्रेशन पथ नहीं, और लागू करने से पहले अपने संस्करण के संदर्भ में निर्देश जाँचें।

acl pvpn_src src 192.0.2.128/25
acl pvpn_dst dst 198.51.100.77/32
acl pvpn_port port 1194
acl pvpn_ok all-of CONNECT pvpn_port pvpn_dst pvpn_src

all-of समूह तभी मेल खाता है जब हर सदस्य मेल खाए, यानी स्रोत, गंतव्य और पोर्ट एक ही पंक्ति पर जाँचे जाते हैं। समूह अपने आप में कुछ नहीं देता, और तीन में से केवल दो तथ्यों से मेल खाता अनुरोध उसे संतुष्ट नहीं कर सकता। यही गुण अपवाद को सीमित रखता है जब कोई बाद में दूसरा गेटवे जोड़ता है। या तो नया गंतव्य जानबूझकर जोड़ा जाता है, या अनुरोध मूल गार्ड पर लौट जाता है।

पोर्ट गार्ड को हटाए बिना उन्हें मोड़ें

अपनी मौजूदा जगहों पर दोनों पारंपरिक गार्ड पंक्तियाँ ऐसी दिखती हैं। वे आम तौर पर प्रमाणीकरण के बाद और सब कुछ अनुमत करने वाली नीति पंक्तियों से पहले रहती हैं।

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

हर एक में निषेधित संयुक्त मिलान जोड़ें, ताकि मेल खाता अपवाद ऐसे गार्ड से बच जाए जो अन्यथा उसे अस्वीकार कर देता। केवल गार्ड पंक्तियाँ बदलती हैं, और हर एक में केवल एक अतिरिक्त शर्त जुड़ती है।

http_access deny CONNECT !SSL_ports !pvpn_ok
http_access deny !Safe_ports !pvpn_ok

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

अपवाद कहाँ नहीं रखा जाना चाहिए

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

देखें कि पोर्ट गार्ड के बाद अनुरोध को अभी क्या चाहिए। प्रमाणित खाता, अनुमत क्लाइंट पता और गंतव्य नीति सभी अभी भी लागू हैं, और अपवाद उनमें से कुछ भी नहीं बदलता। यदि आपकी प्रॉक्सी स्वीकृत खाते को पहले से मनमाने गंतव्यों तक पहुँचने देती है, तो पोर्ट गार्ड कभी असली नियंत्रण नहीं था।

विचार करें कि एंडपॉइंट आख़िर TCP है या नहीं। CONNECT अपवाद TCP धाराएँ वहन करता है, और UDP उपयोग करने वाली OpenVPN प्रोफ़ाइल उसके ज़रिए पहुँच योग्य नहीं बनेगी। प्रोफ़ाइल को TCP में केवल तब बदलें जब सर्वर उस तरह सुनता हो और ऑपरेटर व्यवहार के अंतर को स्वीकार करे।

पार्सर और एक वास्तविक अनुरोध से सीमा जाँचें

पुनः लोड करने से पहले कॉन्फ़िगरेशन पार्स करें, और ऐसा करते समय दूसरा सत्र खुला रखें। पुनः लोड के समय वाक्य-रचना त्रुटि प्रॉक्सी को पुरानी कॉन्फ़िगरेशन पर छोड़ सकती है या नई को पूरी तरह अस्वीकार कर सकती है। पार्सर अस्वीकृत पंक्ति बताता है, जो क्लाइंट त्रुटि के बताने से अधिक है।

फिर पुनः लोड करें और स्वीकृत स्रोत से प्रॉक्सी के ज़रिए एक वास्तविक CONNECT भेजें। पार्सर चलाना पहले आता है, क्योंकि टाइपिंग त्रुटि वाला पुनः लोड आपको नीति के बारे में कुछ नहीं सिखाता।

squid -k parse
squid -k reconfigure
curl -v -p -x http://proxy.lab.internal:3128 https://vpn.lab.internal:1194/ --max-time 5

तीन स्थितियाँ जाँचें: स्वीकृत स्रोत और खाता, अस्वीकृत स्रोत, और उसी पोर्ट पर भिन्न गंतव्य। तीसरी स्थिति ही साबित करती है कि अपवाद सीमित है, क्योंकि वह गंतव्य-मिलान के बिना पोर्ट का उपयोग करती है। क्लाइंट संदेश पर भरोसा करने के बजाय तीनों के लिए एक्सेस लॉग पढ़ें। सफल CONNECT केवल एक TCP धारा स्थापित करता है और कुछ नहीं, इसलिए VPN हैंडशेक एक अलग जाँच ही रहता है।