Apache 2.4 वापरून Subversion होस्ट VPN वापरकर्त्यांपुरता मर्यादित करा

Subversion व्हर्च्युअल होस्ट VPN पत्त्याकडे वळवल्याने कोणती साइट विनंतीला उत्तर देते ते बदलते, कोणाला ती पाठवण्याची परवानगी आहे ते नाही। प्रवेश तपासणी नंतर होते, URL शी जुळलेल्या विभागातील नियमांनुसार, आणि होस्टचे नाव त्या निर्णयात कधीही येत नाही। ServerName हा तुमचा एकमेव बदल असेल, तर रिपॉझिटरी कालच्याइतकीच उपलब्ध आहे। कॉन्फिगरेशनमध्ये दोन वेगळ्या प्रश्नांची उत्तरे द्यायची आहेत: कोणत्या सॉकेटने कनेक्शन स्वीकारले आणि विनंती कोणती ओळख घेऊन आली।

ServerName प्रत्यक्षात काय ठरवते

नाव-आधारित व्हर्च्युअल होस्टिंग Host हेडरची ServerName आणि ServerAlias नोंदींशी तुलना करते, एक होस्ट निवडते आणि तिला विनंती हाताळू देते। कनेक्शन स्वतः आधी सर्व्हरच्या मालकीच्या Listen सॉकेटने स्वीकारले होते, होस्टने नाही। त्यामुळे खाजगी दिसणारे नाव कोणतेही संरक्षण देत नाही: सॉकेटपर्यंत पोहोचणारा कोणताही क्लायंट तो Host हेडर पाठवू शकतो। नाव ही राउटिंग किल्ली आहे, आणि राउटिंग किल्ल्या कॉल करणारा निवडतो।

अंदाज न लावता तुम्ही मॅपिंग पाहू शकता। apachectl -S प्रत्येक होस्ट, तिचा पोर्ट आणि नावे छापते आणि पत्त्यासाठी कोणता डीफॉल्ट आहे ते चिन्हांकित करते।

RequireAll हा तो कंटेनर आहे जो दोन्ही तपासण्या अनिवार्य करतो

Apache 2.4 एका विभागातील Require निर्देशांना अंतर्निहित RequireAny मध्ये गुंडाळतो, त्यामुळे दोन उघडे निर्देश म्हणजे त्यापैकी कोणताही एक पुरतो। कंटेनर जोडा आणि अर्थ उलटतो:

<Location /svn/repo>
    AuthType Basic
    AuthName "Subversion"
    AuthBasicProvider file
    AuthUserFile /etc/apache2/svn.htpasswd
    <RequireAll>
        Require ip 10.8.0.0/24
        Require valid-user
    </RequireAll>
</Location>

RequireAll दोन्ही अटी मागतो: टनेल श्रेणीतील स्रोत पत्ता आणि रिपॉझिटरी स्वीकारणारा वापरकर्ता। Subversion URL साठी फक्त-VPN चा अर्थ हाच असावा। mod_authz_core संदर्भ कंटेनरचे नियम दस्तऐवजीकरण करतो। ब्लॉक रिपॉझिटरीच्या विद्यमान Location मध्ये ठेवा आणि आधीच काम करणाऱ्या DAV निर्देशांना त्यांच्या जागी ठेवा, कारण हा तुकडा AuthType, पासवर्ड फाइल किंवा पाथ-स्तरीय अधिकृतता यापैकी काहीही बदलत नाही।

स्रोत तपासणी mod_authz_host मधून येते, म्हणून दुसरे काही डीबग करण्यापूर्वी ते लोड झाले आहे याची खात्री करा: apachectl -M | grep authz_host।

Apache ज्या पत्त्याचे मूल्यांकन करतो तो सॉकेट पत्ता आहे

Require ip कनेक्शनसाठी Apache ने नोंदवलेल्या पत्त्याशी तुलना करतो, आणि तो क्लायंटला स्वतःकडे आहे असे वाटणारा पत्ता नसतो।

VPN ने आपले पत्ते भाषांतराशिवाय राउट केल्यास Apache टनेलचा पत्ता पाहतो आणि 10.8.0.0/24 जुळतो। गेटवेने भाषांतर केल्यास Apache गेटवे पाहतो आणि नियम शांतपणे कशाशीही जुळत नाही; होस्टच्या पुढे TLS संपवणाऱ्या लोड बॅलन्सरच्या मागेही तेच घडते। त्या प्रकरणासाठी mod_remoteip आहे। बॅलन्सरसाठी RemoteIPTrustedProxy सह RemoteIPHeader X-Forwarded-For नोंदवलेला पत्ता बदलतो, आणि तेव्हाच श्रेणीकडे तुलना करण्यासाठी काही असते।

कोणत्याही फॉरवर्डिंग हेडरवर विश्वास ठेवणे नियमच नसण्यापेक्षा वाईट आहे। कोणताही क्लायंट 10.8.0.9 असलेला X-Forwarded-For पाठवू शकतो आणि विश्वासार्ह हॉपला कधीही जोडला न गेलेला श्रेणी-तपासणी पूर्ण करू शकतो।

लिसनर आणि रिपॉझिटरी धोरण स्तरांमध्ये लावा

बाइंडिंग हे वेगळे नियंत्रण आहे आणि बहुतेक वेळा सोपे। Listen 10.8.0.1:443 कोणते सॉकेट अस्तित्वात आहेत हे ठरवते, आणि कधीही न उघडलेल्या सॉकेटवर विनंती होस्ट निवडू शकत नाही। किंमत स्टार्टअप क्रम आहे: Apache सुरू होताना टनेल इंटरफेस बंद असेल, तर बाइंडिंग अयशस्वी होते आणि सेवा वर येत नाही। ते युनिट क्रमाशी जोडा, किंवा टनेलपासून स्वतंत्रपणे अस्तित्वात असलेल्या पत्त्यावर बाइंड करा।

पाथ परवानग्या AuthzSVNAccessFile मध्ये राहतात। साइटसाठी वैध खाते प्रकल्प पाथवर लिहिण्याच्या परवानगीइतकेच अधिकार नाही, आणि नेटवर्क नियम ते बदलत नाही।

ब्लॉक समाविष्ट फाइलमध्ये असताना विभाग-विलयनाकडे लक्ष द्या। Apache नेस्टेड विभागांमध्ये अधिकृतता कंटेनर विलीन करतो आणि सर्वात विशिष्ट जुळणारा विभाग आवश्यकता जोडण्याऐवजी बदलू शकतो, त्यामुळे संकुचित विभागाने स्वतःचा नियम ठरवल्यावर /svn वरील नियम /svn/repo/trunk पर्यंत पोहोचणार नाही।

पूर्ण म्हणण्यापूर्वी दोन्ही नकार सिद्ध करा

एक नाही, चार विनंत्या तपासा। VPN मध्ये वैध खात्यासह तुम्हाला रिपॉझिटरीची यादी मिळायला हवी। VPN मध्ये चुकीच्या पासवर्डसह यादीऐवजी 401 मिळायला हवे। VPN बाहेरून वैध क्रेडेन्शियलसह 403 मिळायला हवे, आणि पर्यायी होस्टनावावरील तीच सार्वजनिक विनंतीही त्याच प्रकारे अयशस्वी व्हायला हवी।

प्रत्येक प्रकरणासाठी एक आदेश पुरतो: curl -sI -u user:pass https://svn.example.com/svn/repo/, नंतर स्टेटस ओळ वाचा। कार्यरत प्रकरण खऱ्या क्लायंटद्वारेही पुन्हा करा, कारण svn info त्या DAV पद्धतींचा सराव करते ज्या कमिट आणि अद्यतने वापरतील।

चारपैकी कोणताही निकाल तुम्ही इच्छित धोरणाशी जुळत नसेल, तर कॉन्फिगरेशन पूर्ण झालेले नाही, आणि होस्टचे नाव बदलल्याने ते बदलणार नाही।