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 हस्तांदोलन स्वतंत्र चाचणीच राहते।