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 विधिहरूको अभ्यास गर्छ।

चारमध्ये कुनै पनि नतिजा तपाईंले चाहेको नीतिसँग नमिलेमा कन्फिगरेसन पूरा भएको छैन, र होस्टको नाम बदल्दा त्यो बदलिँदैन।

सम्बन्धित लेखहरू