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 विधियों का अभ्यास करता है जिनका उपयोग कमिट और अद्यतन करेंगे।

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