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 രീതികൾ പരിശീലിപ്പിക്കുന്നു.

നാല് ഫലങ്ങളിൽ ഏതെങ്കിലും നിങ്ങൾ ഉദ്ദേശിച്ച നയവുമായി പൊരുത്തപ്പെടുന്നില്ലെങ്കിൽ, കോൺഫിഗറേഷൻ പൂർത്തിയായിട്ടില്ല, ഹോസ്റ്റിന്റെ പേര് മാറ്റുന്നത് അത് മാറ്റില്ല.