In Subversion-host beheine ta VPN-brûkers mei Apache 2.4

ServerName kiest in firtuele host; it beheint net wa't ferbynt. Freegje it VPN-berik en in echte bewarplak-brûker, en bewize dan beide wegerings.

In firtuele Subversion-host nei in VPN-adres wize feroaret hokker side in fersyk beantwurdet, net wa't tastien is om ien te stjoeren. De tagongskontrôle bart letter, neffens de regels yn 'e seksje dy't by de URL paste, en in hostnamme komt nea yn dy beslissing. As ServerName jo iennichste feroaring wie, is it bewarplak krekt like berikber as juster. Twa aparte fragen moatte yn 'e konfiguraasje beantwurde wurde: hokker socket de ferbining oannaam en hokker identiteit it fersyk droech.

Wat ServerName eins beslút

Namme-basearre firtuele hosting ferliket de Host-kop mei ServerName- en ServerAlias-ynfieringen, kiest ien host en lit dy it fersyk ôfhandelje. De ferbining sels waard earder oannaam troch in Listen-socket dy't by de tsjinner heart, net by de host. Dêrom biedt in namme dy't privee liket gjin beskerming: elke klant dy't de socket berikke kin, kin dy Host-kop stjoere. De namme is in routingkaai, en routingkaaien wurde keazen troch de oanropper.

Jo kinne de mapping sûnder rieden sjen. apachectl -S printsiket elke host, syn poarte en syn nammen, en markearret hokker de standert foar it adres is.

RequireAll is de kontener dy't beide kontrôles ferplichtet

Apache 2.4 wikkelet de Require-rjochtlinen fan ien seksje yn in ymplisite RequireAny, dus twa bleate rjochtlinen betsjutte dat ien fan beide genôch is. Foegje de kontener ta en de betsjutting keart 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 fereasket beide betingsten: in boarneadres binnen it tunnelberik en in brûker dy't it bewarplak akseptearret. Dat moat allinnich-VPN betsjutte foar in Subversion-URL. De mod_authz_core-referinsje dokumintearret de kontenerregels. Hâld it blok binnen de besteande Location foar it bewarplak en lit de DAV-rjochtlinen dy't al wurkje stean, want dit fragmint ferfangt noch AuthType, noch it wachtwurdbestân, noch autorisaasje op paadnivo.

De boarnetest komt fan mod_authz_host, dus befêstigje dat it laden is foardat jo wat oars debugge: apachectl -M | grep authz_host.

It adres dat Apache evaluearret is it socketadres

Require ip ferliket mei it adres dat Apache foar de ferbining registrearre, en dat is net altyd it adres dat de klant tinkt te hawwen.

As it VPN syn adressen sûnder oersetting rûtelet, sjocht Apache it tunneladres en 10.8.0.0/24 past. As in gateway oerset, sjocht Apache de gateway en de regel past stilwei neat; itselde bart efter in load balancer dy't TLS foar de host ôfslút. Foar dat gefal bestiet mod_remoteip. RemoteIPHeader X-Forwarded-For tegearre mei RemoteIPTrustedProxy foar de balancer ferfangt it registrearre adres, en pas dan hat it berik wat om mei te ferliken.

In willekeurige trochstjoerkop fertrouwe is slimmer as hielendal gjin regel hawwe. Elke klant kin X-Forwarded-For mei 10.8.0.9 stjoere en in berikkontrôle befredigje dy't nea oan in fertroude hop ferankere wie.

Liz it lústerder en it bewarplakbelied yn lagen

Bining is in aparte kontrôle en faak de ienfâldichste. Listen 10.8.0.1:443 beslút hokker sockets bestean, en in fersyk kin gjin host kieze op in socket dy't nea iepene waard. De priis is startoarder: as de tunnelinterface del is as Apache startet, mislearret de bining en komt de tsjinst net omheech. Keppelje it oan unit-oarder, of bin oan in adres dat ûnôfhinklik fan de tunnel bestiet.

Paadrjochten bliuwe yn AuthzSVNAccessFile. In jildich akkount foar de side is net deselde tastimming as skriuwtagong ta in projektpaad, en de netwurkregel feroaret dat net.

Pas op foar seksjefoeging as it blok yn in ynfoege bestân sit. Apache foeget autorisaasjekonteners oer nêste seksjes gear en de meast spesifike passende seksje kin de eask ferfange ynstee fan deroan ta te foegjen, dus in regel op /svn berikt miskien net /svn/repo/trunk sadree't in nauwere seksje syn eigen definiearret.

Bewize beide wegerings foardat jo it klear neame

Test fjouwer fersiken, net ien. Binnen it VPN mei in jildich akkount moatte jo de bewarplaklist krije. Binnen it VPN mei in ferkeard wachtwurd moatte jo 401 krije ynstee fan in list. Fan bûten it VPN mei jildige bewizen moatte jo 403 krije, en itselde iepenbiere fersyk tsjin in alternatyf hostnamme moat itselde mislearje.

Ien opdracht per gefal is genôch: curl -sI -u user:pass https://svn.example.com/svn/repo/, lês dan de statusrigel. Werhelje it wurkjende gefal ek troch de echte klant, want svn info oefenet de DAV-metoaden dy't commits en fernijingen brûke sille.

As ien fan de fjouwer resultaten net oerienkomt mei it belied dat jo bedoelden, is de konfiguraasje net klear, en it omneamen fan de host sil dat net feroarje.

Relatearre artikelen