Beperk ’n Subversion-gasheer tot VPN-gebruikers met Apache 2.4

ServerName kies ’n virtuele gasheer; dit beperk nie wie kan konekteer nie. Eis die VPN-reeks en ’n egte bewaarplek-gebruiker, en bewys dan albei weierings.

Om ’n Subversion virtuele gasheer na ’n VPN-adres te wys, verander watter werf ’n versoek beantwoord, nie wie toegelaat word om een te stuur nie. Die toegangscontrole gebeur later, teen die reëls in die afdeling wat by die URL pas, en ’n gasheernaam tree nooit daardie besluit binne nie. As ServerName jou enigste verandering was, is die bewaarplek net so bereikbaar soos gister. Twee afsonderlike vrae moet in die konfigurasie beantwoord word: watter sokkel die verbinding aanvaar het, en watter identiteit die versoek gedra het.

Wat ServerName werklik bepaal

Naamgebaseerde virtuele gasheerwerk vergelyk die Host-kop met ServerName- en ServerAlias-inskrywings, kies een gasheer en laat daardie gasheer die versoek hanteer. Die verbinding self is vroeër deur ’n Listen-sokkel aanvaar wat aan die bediener behoort, nie aan die gasheer nie. Daarom bied ’n privaat-klinkende naam geen beskerming nie: enige kliënt wat die sokkel kan bereik, kan daardie Host-kop stuur. Die naam is ’n routeringsleutel, en routeringsleute word deur die oproeper gekies.

Jy kan die kartering sonder raaiwerk sien. apachectl -S druk elke gasheer, sy poort en sy name, en merk watter een die verstek vir die adres is.

RequireAll is die houer wat albei kontroles verpligtend maak

Apache 2.4 omhul die Require-richtlyne van ’n enkele afdeling in ’n implisiete RequireAny, so twee kaal richtlyne beteken enige een is genoeg. Voeg die houer by en die betekenis keer om:

<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 vereis albei voorwaardes: ’n bronadres binne die tonnel-reeks en ’n gebruiker wat die bewaarplek aanvaar. Dit is wat slegs-VPN vir ’n Subversion-URL behoort te beteken. Die mod_authz_core-verwysing dokumenteer die houerreëls. Hou die blok binne die bestaande Location vir die bewaarplek en laat die DAV-richtlyne wat reeds werk in plek, want hierdie fragment vervang nie AuthType of die wagwoordlêer of padvlak-magtiging nie.

Die brontoets kom van mod_authz_host, so bevestig dit is gelaai voordat jy enigiets anders ontfout: apachectl -M | grep authz_host.

Die adres wat Apache evalueer, is die sokkeladres

Require ip vergelyk met die adres wat Apache vir die verbinding aangeteken het, wat nie altyd die adres is wat die kliënt dink hy het nie.

Wanneer die VPN sy adresse sonder vertaling roeteer, sien Apache die tonneladres en 10.8.0.0/24 pas. Wanneer ’n gateway die adresse vertaal, sien Apache die gateway en die reël pas stilweg niks; dieselfde gebeur agter ’n lasbalanseerder wat TLS voor die gasheer termineer. mod_remoteip bestaan vir daardie geval. RemoteIPHeader X-Forwarded-For saam met RemoteIPTrustedProxy vir die balanseerder vervang die aangetekende adres, en eers dan het die reeks iets om mee te vergelyk.

Om enige aanstuur-kop te vertrou is erger as om glad geen reël te hê nie. Enige kliënt kan X-Forwarded-For met 10.8.0.9 daarin stuur en ’n reekskontrole bevredig wat nooit aan ’n vertroude sprong geanker was nie.

Laag die luisteraar en die bewaarplek-beleid

Binding is ’n afsonderlike beheer en dikwels die eenvoudigste. Listen 10.8.0.1:443 besluit watter sokkels bestaan, en ’n versoek kan nie ’n gasheer op ’n sokkel kies wat nooit oopgemaak is nie. Die prys is opstartorde: as die tonnelkoppelvlak af is wanneer Apache begin, misluk die binding en kom die diens nie op nie. Koppel dit aan eenheidorde, of bind aan ’n adres wat onafhanklik van die tonnel bestaan.

Padmagtigings bly in AuthzSVNAccessFile. ’n Geldige rekening vir die werf is nie dieselfde toestemming as skryftoegang tot ’n projekpad toe nie, en die netwerkreël verander dit nie.

Let op afdelingsamesmelting wanneer die blok in ’n ingeslote lêer sit. Apache smelt magtigingshouers oor geneste afdelings saam en die mees spesifieke passende afdeling kan die vereiste vervang eerder as om dit by te voeg, so ’n reël op /svn bereik dalk nie /svn/repo/trunk sodra ’n nouer afdeling sy eie definieer nie.

Bewys albei weierings voordat jy dit klaar noem

Toets vier versoeke, nie een nie. Binne die VPN met ’n geldige rekening behoort jy die bewaarplek-lys te kry. Binne die VPN met ’n verkeerde wagwoord behoort jy 401 te kry eerder as ’n lys. Van buite die VPN met geldige geloofsbriewe behoort jy 403 te kry, en dieselfde openbare versoek teen ’n alternatiewe gasheernaam moet dieselfde misluk.

Een opdrag per geval is genoeg: curl -sI -u user:pass https://svn.example.com/svn/repo/, lees dan die statuslyn. Herhaal die werkende geval ook deur die werklike kliënt, want svn info oefen die DAV-metodes wat commit en update sal gebruik.

As enige van die vier resultate verskil van die beleid wat jy bedoel het, is die konfigurasie nie klaar nie, en om die gasheer te hernoem sal dit nie verander nie.

Verwante artikels