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 ले यीमध्ये कुनै पनि नाम आफ्नो लागि आरक्षित राख्दैन, त्यसैले ती छान्ने र एकरूपमा राख्ने काम तपाईंको हो। यो विधि all-of समूहलाई समर्थन गर्ने कागजातीकृत कन्फिगरेसन भएको Squid 6 र 7 मा सीमित छ। हालको सन्दर्भले ती निर्देशनहरूलाई 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 ह्यान्डशेक छुट्टै परीक्षण रहन्छ।