Subversion ostalaria VPN erabiltzaileetara mugatu Apache 2.4 erabiliz

ServerName-ek ostalari birtuala aukeratzen du; ez du nork konektatzen duen mugatzen. Eskatu VPN barrutia eta biltegiko benetako erabiltzailea, eta gero frogatu bi ukapenak.

Subversion ostalari birtuala VPN helbide batera bideratzeak aldatu egiten du zein gunek erantzuten duen eskaera bati, ez nork duen bidaltzeko baimena. Sarbide-egiaztapena geroago egiten da, URL-arekin bat etorri zen ataleko arauen arabera, eta ostalariaren izenak ez du inoiz erabaki horretan parte hartzen. ServerName izan bazen zure aldaketa bakarra, biltegia atzo bezain irisgarria da. Bi galdera bereizi erantzun behar dira konfigurazioan: zein socketek onartu zuen konexioa eta zer identitate zeraman eskaerak.

Zer erabakitzen du ServerName-ek benetan

Izenetan oinarritutako ostalari birtualak Host goiburua ServerName eta ServerAlias sarrerekin alderatzen du, ostalari bat aukeratzen du eta hark eskaera kudeatzea uzten du. Konexioa bera lehenago onartu zuen zerbitzariarena den Listen socket batek, ez ostalariarena. Horregatik itxura pribatuko izen batek ez du babesik ematen: socketera iristen den edozein bezerok bidal dezake Host goiburu hori. Izena bideratze-gakoa da, eta bideratze-gakoak deitzen duenak aukeratzen ditu.

Mapaketa asmatu gabe ikus dezakezu. apachectl -S-ek ostalari bakoitza, haren portua eta izenak inprimatzen ditu, eta helbiderako zein den lehenetsia markatzen du.

RequireAll da bi egiaztapenak derrigorrezko egiten dituen edukiontzia

Apache 2.4-k atal bateko Require direktibak RequireAny inplizitu batean biltzen ditu, beraz bi direktiba hutsak horietako nahikoa dela esan nahi du. Gehitu edukiontzia eta esanahia alderantzizten da:

<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-ek bi baldintzak behar ditu: iturri-helbidea tuneleko barrutiaren barruan eta biltegiak onartzen duen erabiltzailea. Hori gertatu beharko litzateke Subversion URL baterako VPN-soilik. mod_authz_core erreferentziak edukiontziaren arauak dokumentatzen ditu. Mantendu blokea biltegiko lehendik dagoen Location barruan eta utzi jada funtzionatzen duten DAV direktibak lekuan, zati honek ez baitu ez AuthType ez pasahitz-fitxategia ez bide-mailako baimena ordezkatzen.

Iturriaren proba mod_authz_host-etik dator, beraz egiaztatu kargatuta dagoela beste ezer araztu aurretik: apachectl -M | grep authz_host.

Apache-k ebaluatzen duen helbidea socketaren helbidea da

Require ip-k Apache-k konexiorako erregistratu zuen helbidearekin alderatzen du, eta hori ez da beti bezeroak duela uste duen helbidea.

VPN-ak bere helbideak itzulpenik gabe bideratzen dituenean, Apache-k tuneleko helbidea ikusten du eta 10.8.0.0/24 bat dator. Atebide batek itzultzen duenean, Apache-k atebidea ikusten du eta arauak isilpean ez du ezer bat egiten; gauza bera gertatzen da ostalariaren aurrean TLS amaitzen duen karga-balantzagailu baten atzean. Kasu horretarako mod_remoteip dago. RemoteIPHeader X-Forwarded-For-ek, balantzagailuarentzako RemoteIPTrustedProxy-rekin batera, erregistratutako helbidea ordezkatzen du, eta orduan soilik du barrutiak alderatzeko zerbait.

Edonolako birbidalketa-goiburua fidatzea inolako araurik ez izatea baino okerragoa da. Edozein bezerok 10.8.0.9 duen X-Forwarded-For bidal dezake eta inoiz jauzi fidagarri bati ainguratu gabeko barruti-egiaztapena bete.

Geruzatu entzulea eta biltegiko politika

Lotzea kontrol bereizia da eta sarritan errazagoa. Listen 10.8.0.1:443-ek erabakitzen du zein socket dauden, eta eskaera batek ezin du inoiz ireki ez zen socket batean ostalaririk aukeratu. Kostua abiarazte-ordena da: Apache abiatzean tunelaren interfazea behera badago, lotzeak huts egiten du eta zerbitzua ez da altxatzen. Parekatu unitateen ordenarekin, edo lotu tunelaren menpe ez dagoen helbide batera.

Bide-baimenak AuthzSVNAccessFile-n geratzen dira. Gunerako kontu baliozkoa ez da proiektu-bide baterako idazteko baimenaren berbera, eta sare-arauak ez du hori aldatzen.

Kontuz atalen bateratzearekin, blokea barne hartutako fitxategi batean dagoenean. Apache-k baimen-edukiontziak atal habiaratuetan zehar bateratzen ditu eta bat datorren atal zehatzenak baldintza ordeztu dezake, gehitu beharrean, beraz /svn-ko arauak agian ez du /svn/repo/trunk-ra iritsiko atal estuago batek berea definitzen duenean.

Frogatu bi ukapenak amaitu dela esan aurretik

Probatu lau eskaera, ez bat. VPN barruan kontu baliozkoarekin biltegiaren zerrenda lortu behar duzu. VPN barruan pasahitz okerrarekin 401 lortu behar duzu zerrenda baten ordez. VPN kanpotik kredentzial baliozkoekin 403 lortu behar duzu, eta ostalari-izen alternatibo bati egindako eskaera publiko berak modu berean huts egin behar du.

Kasuko komando bat nahikoa da: curl -sI -u user:pass https://svn.example.com/svn/repo/, gero irakurri egoera-lerroa. Errepikatu funtzionatzen duen kasua benetako bezeroarekin ere, svn info-ek commit-ek eta eguneratzeek erabiliko dituzten DAV metodoak praktikatzen baititu.

Lau emaitzetatik edozein zure asmoa zen politikarekin bat ez badator, konfigurazioa ez da amaitu, eta ostalariari izena aldatzeak ez du hori aldatuko.

Erlazionatutako artikuluak