Limigi Subversion-gastiganton al VPN-uzantoj per Apache 2.4

ServerName elektas virtualan gastiganton; ĝi ne limigas, kiu konektiĝas. Postulu la VPN-gamon kaj realan uzanton de la deponejo, poste pruvu ambaŭ rifuzojn.

Montri virtualan Subversion-gastiganton al VPN-adreso ŝanĝas, kiu retejo respondas al peto, ne kiu rajtas sendi ĝin. La alirkontrolo okazas poste, laŭ la reguloj en la sekcio, kiu kongruis kun la URL, kaj gastigantnomo neniam eniras tiun decidon. Se ServerName estis via sola ŝanĝo, la deponejo estas same atingebla kiel hieraŭ. Du apartaj demandoj devas esti responditaj en la agordo: kiu ingo akceptis la konekton, kaj kiun identecon la peto portis.

Kion ServerName efektive decidas

Nom-bazita virtuala gastigado komparas la kaplinion Host kun rikordoj ServerName kaj ServerAlias, elektas unu gastiganton kaj lasas ĝin prilabori la peton. La konekton mem akceptis pli frue ingo Listen, kiu apartenas al la servilo, ne al la gastiganto. Tial nomo, kiu aspektas privata, ofertas neniun protekton: ĉiu kliento, kiu atingas la ingon, povas sendi tiun kaplinion Host. La nomo estas enkursigila ŝlosilo, kaj enkursigilajn ŝlosilojn elektas la alvokanto.

Vi povas vidi la mapadon sen diveni. apachectl -S presas ĉiun gastiganton, ĝian pordon kaj ĝiajn nomojn, kaj markas, kiu estas la defaŭlta por la adreso.

RequireAll estas la ujo, kiu faras ambaŭ kontrolojn devigaj

Apache 2.4 volvas la Require-direktivojn de unu sekcio en implicitan RequireAny, do du nudaj direktivoj signifas, ke sufiĉas iu ajn el ili. Aldonu la ujon kaj la signifo renversiĝas:

<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 bezonas ambaŭ kondiĉojn: fontan adreson ene de la tunela gamo kaj uzanton, kiun la deponejo akceptas. Tion devus signifi nur-VPN por Subversion-URL. La referenco de mod_authz_core dokumentas la regulojn de la ujo. Konservu la blokon ene de la ekzistanta Location por la deponejo kaj lasu la DAV-direktivojn, kiuj jam funkcias, surloke, ĉar ĉi tiu fragmento anstataŭigas nek AuthType nek la pasvortdosieron nek rajtigon je voja nivelo.

La fonta testo venas de mod_authz_host, do konfirmu, ke ĝi estas ŝargita antaŭ ol sencimigi ion alian: apachectl -M | grep authz_host.

La adreso, kiun Apache pritaksas, estas la inga adreso

Require ip komparas kun la adreso, kiun Apache registris por la konekto, kaj tio ne ĉiam estas la adreso, kiun la kliento kredas havi.

Kiam la VPN enkursigas siajn adresojn sen traduko, Apache vidas la tunelan adreson kaj 10.8.0.0/24 kongruas. Kiam enirejo tradukas, Apache vidas la enirejon kaj la regulo silente kongruas kun nenio; la samo okazas malantaŭ ŝarĝobalancilo, kiu finas TLS antaŭ la gastiganto. mod_remoteip ekzistas por tiu kazo. RemoteIPHeader X-Forwarded-For kune kun RemoteIPTrustedProxy por la balancilo anstataŭigas la registritan adreson, kaj nur tiam la gamo havas ion por kompari.

Fidi arbitran plusendan kaplinion estas pli malbone ol havi tute neniun regulon. Ĉiu kliento povas sendi X-Forwarded-For enhavantan 10.8.0.9 kaj plenumi gamkontrolon, kiu neniam estis ankrita al fidinda hopo.

Tavoligu la aŭskultanton kaj la deponejan politikon

Bindado estas aparta kontrolo kaj ofte la pli simpla. Listen 10.8.0.1:443 decidas, kiuj ingoj ekzistas, kaj peto ne povas elekti gastiganton sur ingo, kiu neniam malfermiĝis. La kosto estas starta ordo: se la tunela interfaco estas malaktiva kiam Apache startas, la bindado malsukcesas kaj la servo ne ekfunkcias. Paru ĝin kun unita ordo, aŭ bindu al adreso, kiu ekzistas sendepende de la tunelo.

Vojaj permesoj restas en AuthzSVNAccessFile. Valida konto por la retejo ne estas la sama permeso kiel skriba aliro al projekta vojo, kaj la reta regulo tion ne ŝanĝas.

Atentu sekcian kunfandadon, kiam la bloko troviĝas en inkluzivita dosiero. Apache kunfandas rajtigajn ujojn tra nestitaj sekcioj kaj la plej specifa kongrua sekcio povas anstataŭigi la postulon anstataŭ aldoni al ĝi, do regulo sur /svn eble ne atingas /svn/repo/trunk, post kiam pli mallarĝa sekcio difinas sian propran.

Pruvu ambaŭ rifuzojn antaŭ ol nomi ĝin finita

Testu kvar petojn, ne unu. Ene de la VPN kun valida konto vi devus ricevi la liston de la deponejo. Ene de la VPN kun malĝusta pasvorto vi devus ricevi 401 anstataŭ liston. De ekstere de la VPN kun validaj legitimiloj vi devus ricevi 403, kaj la sama publika peto al alterna gastigantnomo devas malsukcesi same.

Unu komando por kazo sufiĉas: curl -sI -u user:pass https://svn.example.com/svn/repo/, poste legu la statlinion. Ripetu ankaŭ la funkcian kazon per la reala kliento, ĉar svn info ekzercas la DAV-metodojn, kiujn uzos commit-oj kaj ĝisdatigoj.

Se iu el la kvar rezultoj malkongruas kun la politiko, kiun vi intencis, la agordo ne estas finita, kaj renomado de la gastiganto tion ne ŝanĝos.

Rilataj artikoloj