Avgrens ein Subversion-vert til VPN-brukarar med Apache 2.4

ServerName vel ein virtuell vert; det avgrensar ikkje kven som koplar til. Krev VPN-området og ein ekte depotbrukar, og prov deretter begge avvisingane.

Å peike ein virtuell Subversion-vert mot ei VPN-adresse endrar kva nettstad som svarar på ein førespurnad, ikkje kven som har lov til å sende han. Tilgangskontrollen skjer seinare, etter reglane i seksjonen som passa med URL-en, og eit vertsnamn inngår aldri i den avgjerda. Viss ServerName var den einaste endringa di, er depotet nøyaktig like tilgjengeleg som i går. To separate spørsmål må svarast på i konfigurasjonen: kva socket som tok imot sambandet, og kva identitet førespurnaden bar.

Kva ServerName faktisk avgjer

Namnebasert virtuell hosting samanliknar Host-headeren med ServerName- og ServerAlias-oppføringar, vel éin vert og lèt han handsame førespurnaden. Sjalve sambandet vart teke imot tidlegare av ein Listen-socket som høyrer til tenaren, ikkje verten. Derfor gir eit namn som ser privat ut inga vern: kvar klient som når socketen, kan sende den Host-headeren. Namnet er ein rutingsnøkkel, og rutingsnøklar vert valde av den som kallar.

Du kan sjå tilordninga utan å gisse. apachectl -S skriv ut kvar vert, porten og namna, og merkjer kva som er standard for adressa.

RequireAll er beholdaren som gjer begge kontrollane obligatoriske

Apache 2.4 pakkar Require-direktiva i éin seksjon inn i ein implisitt RequireAny, så to bare direktiv tyder at eitt av dei er nok. Legg til beholdaren, og tydinga snur:

<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 krev begge vilkåra: ei kjeldeadresse innanfor tunnelområdet og ein brukar som depotet godtek. Det er kva berre-VPN bør tyde for ein Subversion-URL. Referansen for mod_authz_core dokumenterer behaldarreglane. Hald blokka inne i den eksisterande Location for depotet og lat DAV-direktiva som allereie verkar, stå på plass, fordi dette fragmentet korkje erstattar AuthType eller passordfila eller autorisasjon på stinivå.

Kjeldetesten kjem frå mod_authz_host, så stadfest at det er lasta før du feilsøkjer noko anna: apachectl -M | grep authz_host.

Adressa Apache vurderer, er socketadressa

Require ip samanliknar med adressa Apache registrerte for sambandet, og det er ikkje alltid adressa klienten trur han har.

Når VPN-en ruter adressene sine utan omsetjing, ser Apache tunneladressa, og 10.8.0.0/24 passar. Når ein gateway omset, ser Apache gatewayen, og regelen passar stille på ingenting; det same skjer bak ein lastbalansar som avsluttar TLS framfor verten. For det tilfellet finst mod_remoteip. RemoteIPHeader X-Forwarded-For saman med RemoteIPTrustedProxy for balansaren erstattar den registrerte adressa, og først då har området noko å samanlikne med.

Å stole på ein vilkårleg videresendingsheader er verre enn å ikkje ha nokon regel i det heile. Kvar klient kan sende X-Forwarded-For med 10.8.0.9 og oppfylle ein områdekontroll som aldri var forankra i eit klarert hopp.

Legg lyttaren og depotpolitikken i lag

Binding er ein separat kontroll og ofte den enklaste. Listen 10.8.0.1:443 avgjer kva socketar som finst, og ein førespurnad kan ikkje velje ein vert på ein socket som aldri vart opna. Prisen er oppstartsrekkjefølgje: er tunnelgrensesnittet nede når Apache startar, mislukkast bindinga, og tenesta kjem ikkje opp. Kopla henne til einingsekvens, eller bind til ei adresse som finst uavhengig av tunnelen.

Stitilgangar blir i AuthzSVNAccessFile. Ein gyldig konto for nettstaden er ikkje same tildeling som skrivetilgang til ein prosjektsti, og nettverksregelen endrar ikkje det.

Fylg med på seksjonssamanføying når blokka ligg i ei inkludert fil. Apache flettar autorisasjonsbehaldarar på tvers av nøsta seksjonar, og den mest spesifikke samsvarande seksjonen kan erstatte kravet i staden for å leggje til, så ein regel på /svn når kanskje ikkje /svn/repo/trunk når ein smalare seksjon definerer sin eigen.

Prov begge avvisingane før du kallar det ferdig

Test fire førespurnader, ikkje éin. Inne i VPN-en med ein gyldig konto bør du få depotlista. Inne i VPN-en med feil passord bør du få 401 i staden for ei liste. Utanfor VPN-en med gyldige påloggingsdata bør du få 403, og den same offentlege førespurnaden mot eit alternativt vertsnamn må mislukkast på same måte.

Éin kommando per tilfelle er nok: curl -sI -u user:pass https://svn.example.com/svn/repo/, og les deretter statuslinja. Gjenta også tilfellet som verkar, gjennom den ekte klienten, fordi svn info øver på DAV-metodane som commits og oppdateringar vil bruke.

Viss noko av dei fire resultata er usamde med policyen du hadde til hensikt, er konfigurasjonen ikkje ferdig, og å gje verten nytt namn endrar ikkje det.

Relaterte artiklar