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 પદ્ધતિઓનો અભ્યાસ કરે છે જે કમિટ અને અપડેટ્સ વાપરશે.

જો ચારમાંથી કોઈપણ પરિણામ તમે ઇચ્છેલી નીતિ સાથે ન મેળ ખાય, તો રૂપરેખાંકન પૂર્ણ થયું નથી, અને હોસ્ટનું નામ બદલવાથી તે બદલાશે નહીં.