Kufizoni një host Subversion te përdoruesit VPN me Apache 2.4

Drejtimi i një hosti virtual Subversion te një adresë VPN ndryshon se cila faqe i përgjigjet një kërkese, jo se kujt i lejohet ta dërgojë atë. Kontrolli i aksesit bëhet më vonë, sipas rregullave në seksionin që përputhej me URL-në, dhe emri i hostit nuk hyn kurrë në atë vendim. Nëse ServerName ishte ndryshimi juaj i vetëm, depoja është po aq e aksesueshme sa dje. Dy pyetje të ndara duhet të përgjigjen në konfigurim: cila socket e pranoi lidhjen dhe çfarë identiteti mbante kërkesa.

Çfarë vendos në të vërtetë ServerName

Hostimi virtual i bazuar në emër krahason kokën Host me hyrjet ServerName dhe ServerAlias, zgjedh një host dhe e lë atë të trajtojë kërkesën. Vetë lidhja ishte pranuar më parë nga një socket Listen që i përket serverit, jo hostit. Prandaj një emër që duket privat nuk ofron asnjë mbrojtje: çdo klient që arrin socketin mund të dërgojë atë kokë Host. Emri është një çelës rrugëtimi, dhe çelësat e rrugëtimit zgjidhen nga ai që thërret.

Mund ta shihni hartëzimin pa hamendësuar. apachectl -S shtyp çdo host, portën dhe emrat e tij, dhe shënon cili është parazgjedhur për adresën.

RequireAll është kontejneri që i bën të dyja kontrollet të detyrueshme

Apache 2.4 i mbështjell direktivat Require të një seksioni në një RequireAny të nënkuptuar, kështu që dy direktiva të zhveshura nënkuptojnë se mjafton njëra prej tyre. Shtoni kontejnerin dhe kuptimi përmbyset:

<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 kërkon të dyja kushtet: një adresë burimi brenda intervalit të tunelit dhe një përdorues që depoja e pranon. Kjo është ajo që duhet të nënkuptojë vetëm-VPN për një URL Subversion. Referenca e mod_authz_core dokumenton rregullat e kontejnerit. Mbajeni bllokun brenda Location ekzistues të depos dhe lërini direktivat DAV që tashmë funksionojnë në vendin e tyre, sepse ky fragment nuk zëvendëson as AuthType, as skedarin e fjalëkalimeve, as autorizimin në nivel shtegu.

Testi i burimit vjen nga mod_authz_host, prandaj konfirmoni se është ngarkuar përpara se të korrigjoni çdo gjë tjetër: apachectl -M | grep authz_host.

Adresa që vlerëson Apache është adresa e socketit

Require ip krahason me adresën që Apache regjistroi për lidhjen, dhe kjo nuk është gjithmonë adresa që klienti mendon se ka.

Kur VPN rrugëton adresat e tij pa përkthim, Apache sheh adresën e tunelit dhe 10.8.0.0/24 përputhet. Kur një portë përkthen, Apache sheh portën dhe rregulli nuk përputhet në heshtje me asgjë; e njëjta gjë ndodh pas një balancuesi që përfundon TLS përpara hostit. Për atë rast ekziston mod_remoteip. RemoteIPHeader X-Forwarded-For së bashku me RemoteIPTrustedProxy për balancuesin zëvendëson adresën e regjistruar, dhe vetëm atëherë intervali ka me çfarë të krahasohet.

Të besosh një kokë përcjelljeje arbitrare është më keq sesa të mos kesh fare rregull. Çdo klient mund të dërgojë X-Forwarded-For që përmban 10.8.0.9 dhe të plotësojë një kontroll intervali që nuk ishte ankoruar kurrë në një hop të besuar.

Shtresoni dëgjuesin dhe politikën e depos

Lidhja është një kontroll i veçantë dhe shpesh më i thjeshti. Listen 10.8.0.1:443 vendos cilat socket ekzistojnë, dhe një kërkesë nuk mund të zgjedhë një host në një socket që nuk u hap kurrë. Çmimi është rendi i nisjes: nëse ndërfaqja e tunelit është poshtë kur Apache niset, lidhja dështon dhe shërbimi nuk ngrihet. Çiftojeni me rendin e njësive, ose lidheni me një adresë që ekziston pavarësisht tunelit.

Lejet e shtegut mbeten në AuthzSVNAccessFile. Një llogari e vlefshme për faqen nuk është e njëjta leje si aksesi i shkrimit në një shteg projekti, dhe rregulli i rrjetit nuk e ndryshon atë.

Kujdes me bashkimin e seksioneve kur blloku ndodhet në një skedar të përfshirë. Apache bashkon kontejnerët e autorizimit përmes seksioneve të ndërlidhura dhe seksioni më specifik që përputhet mund të zëvendësojë kërkesën në vend që t'i shtohet, kështu që një rregull në /svn mund të mos arrijë në /svn/repo/trunk sapo një seksion më i ngushtë përcakton të vetin.

Provoni të dy refuzimet përpara se ta quani të përfunduar

Provoni katër kërkesa, jo një. Brenda VPN me një llogari të vlefshme duhet të merrni listën e depos. Brenda VPN me një fjalëkalim të gabuar duhet të merrni 401 në vend të një liste. Nga jashtë VPN me kredenciale të vlefshme duhet të merrni 403, dhe e njëjta kërkesë publike ndaj një emri hosti alternativ duhet të dështojë në të njëjtën mënyrë.

Një komandë për rast është e mjaftueshme: curl -sI -u user:pass https://svn.example.com/svn/repo/, pastaj lexoni rreshtin e statusit. Përsëritni edhe rastin që funksionon përmes klientit të vërtetë, sepse svn info ushtron metodat DAV që do të përdorin commit-et dhe përditësimet.

Nëse ndonjë nga katër rezultatet nuk përputhet me politikën që kishit ndërmend, konfigurimi nuk është përfunduar, dhe riemërtimi i hostit nuk do ta ndryshojë atë.