Limitahan ang isang host ng Subversion sa mga user ng VPN gamit ang Apache 2.4

Ang pagturo ng virtual host ng Subversion sa isang address ng VPN ay nagbabago kung aling site ang sumasagot sa isang kahilingan, hindi kung sino ang pinapayagang magpadala nito. Ang pagsusuri ng access ay nangyayari mamaya, ayon sa mga patakaran sa seksyong tumugma sa URL, at ang pangalan ng host ay hindi kailanman pumapasok sa desisyong iyon. Kung ang ServerName ang tanging binago mo, ang repository ay kasing-abot gaya kahapon. Dalawang magkahiwalay na tanong ang dapat sagutin sa configuration: aling socket ang tumanggap ng koneksyon at anong pagkakakilanlan ang dala ng kahilingan.

Ano ba talaga ang itinatakda ng ServerName

Ang virtual hosting na nakabatay sa pangalan ay naghahambing ng header na Host sa mga entry ng ServerName at ServerAlias, pumipili ng isang host at hinahayaan itong hawakan ang kahilingan. Ang koneksyon mismo ay tinanggap nang mas maaga ng isang socket na Listen na pag-aari ng server, hindi ng host. Kaya ang pangalang mukhang pribado ay walang ibinibigay na proteksyon: sinumang client na makarating sa socket ay makapagpapadala ng header na Host. Ang pangalan ay isang susi ng routing, at ang mga susi ng routing ay pinipili ng tumatawag.

Makikita mo ang mapping nang hindi nanghuhula. Ipinapakita ng apachectl -S ang bawat host, port at mga pangalan nito, at minamarkahan kung alin ang default para sa address.

Ang RequireAll ang container na nagpapataw ng parehong pagsusuri

Binabalot ng Apache 2.4 ang mga direktiba ng Require ng isang seksyon sa isang implicit na RequireAny, kaya dalawang hubad na direktiba ay nangangahulugang sapat na ang isa. Idagdag ang container at mababaligtad ang kahulugan:

<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>

Kailangan ng RequireAll ang dalawang kundisyon: address ng pinagmulan sa loob ng saklaw ng tunnel at user na tinatanggap ng repository. Iyon ang dapat ibig sabihin ng VPN-lamang para sa isang URL ng Subversion. Idinodokumento ng reperensya ng mod_authz_core ang mga patakaran ng container. Iwanan ang bloke sa loob ng umiiral na Location ng repository at hayaang manatili ang mga direktiba ng DAV na gumagana na, dahil hindi pinapalitan ng tipas na ito ang AuthType, ang file ng password, o ang awtorisasyon sa antas ng landas.

Ang pagsubok ng pinagmulan ay nagmumula sa mod_authz_host, kaya tiyakin na nakaload ito bago mag-debug ng iba pa: apachectl -M | grep authz_host.

Ang address na sinusuri ng Apache ay ang address ng socket

Inihahambing ng Require ip ang address na itinala ng Apache para sa koneksyon, at hindi ito palaging ang address na inaakala ng client na mayroon siya.

Kapag ang VPN ay nagruruta ng mga address nito nang walang pagsasalin, nakikita ng Apache ang address ng tunnel at tumutugma ang 10.8.0.0/24. Kapag may gateway na nagsasalin, nakikita ng Apache ang gateway at tahimik na walang tinutugma ang patakaran; ganoon din ang nangyayari sa likod ng load balancer na nagtatapos ng TLS sa harap ng host. Para sa kasong iyon may mod_remoteip. Pinapalitan ng RemoteIPHeader X-Forwarded-For kasama ng RemoteIPTrustedProxy para sa balancer ang naitalang address, at doon lang may maikukumpara ang saklaw.

Ang pagtitiwala sa anumang header ng pagpapasa ay mas masama kaysa sa walang patakaran. Sinumang client ay makapagpapadala ng X-Forwarded-For na naglalaman ng 10.8.0.9 at makakatugon sa pagsusuri ng saklaw na hindi kailanman nakaangkla sa isang pinagkakatiwalaang hop.

Pagpatungin ang listener at ang patakaran ng repository

Ang pag-binding ay hiwalay na kontrol at kadalasan ang pinakasimple. Itinatakda ng Listen 10.8.0.1:443 kung aling mga socket ang umiiral, at hindi makakapili ang isang kahilingan ng host sa socket na hindi kailanman binuksan. Ang halaga ay ang pagkakasunod-sunod ng pagsisimula: kung nakababa ang interface ng tunnel kapag nagsimula ang Apache, mabibigo ang binding at hindi babangon ang serbisyo. Ipares ito sa pagkakasunod-sunod ng unit, o i-bind sa address na umiiral nang hiwalay sa tunnel.

Ang mga pahintulot sa landas ay nananatili sa AuthzSVNAccessFile. Ang balidong account para sa site ay hindi kaparehong bigay ng pahintulot sa pagsulat sa landas ng proyekto, at hindi ito binabago ng patakaran ng network.

Mag-ingat sa pagsasanib ng seksyon kapag ang bloke ay nasa kasamang file. Sinasanib ng Apache ang mga container ng awtorisasyon sa mga nested na seksyon at maaaring palitan ng pinakaspesipikong tugmang seksyon ang pangangailangan sa halip na idagdag ito, kaya maaaring hindi maabot ng patakaran sa /svn ang /svn/repo/trunk kapag may mas makitid na seksyon na nagtakda ng sarili nito.

Patunayan ang dalawang pagtanggi bago sabihing tapos na

Subukan ang apat na kahilingan, hindi isa. Sa loob ng VPN na may balidong account dapat makuha mo ang listahan ng repository. Sa loob ng VPN na may maling password dapat makuha mo ang 401 sa halip na listahan. Mula sa labas ng VPN na may balidong kredensyal dapat makuha mo ang 403, at ang parehong pampublikong kahilingan sa alternatibong pangalan ng host ay dapat mabigo sa parehong paraan.

Sapat na ang isang utos kada kaso: curl -sI -u user:pass https://svn.example.com/svn/repo/, pagkatapos basahin ang linya ng status. Ulitin din ang gumaganang kaso sa tunay na client, dahil sinusubukan ng svn info ang mga pamamaraang DAV na gagamitin ng commit at ng mga update.

Kung ang alinman sa apat na resulta ay hindi tugma sa patakarang nilalayon mo, hindi pa tapos ang configuration, at hindi iyon mababago ng pagpapalit ng pangalan ng host.