Ограничување на Subversion домаќин на VPN корисници со Apache 2.4

Насочувањето на виртуелен домаќин на Subversion кон VPN адреса го менува тоа кој сајт одговара на барањето, а не кој има дозвола да го испрати. Проверката за пристап се случува подоцна, според правилата во делот што се совпадна со URL-то, и името на домаќинот никогаш не влегува во таа одлука. Ако ServerName беше вашата единствена промена, складиштето е исто толку достапно како вчера. Во конфигурацијата треба да се одговори на две одделни прашања: кој приклучок ја прими врската и каква идентитет носеше барањето.

Што всушност одлучува ServerName

Виртуелно хостирање засновано на име ја споредува главата Host со записите ServerName и ServerAlias, избира еден домаќин и му дозволува да го обработи барањето. Самата врска претходно била прифатена од приклучок Listen што му припаѓа на серверот, а не на домаќинот. Затоа име што изгледа приватно не нуди никаква заштита: секој клиент што ќе го достигне приклучокот може да ја испрати таа глава Host. Името е клуч за насочување, а клучевите за насочување ги избира повикувачот.

Можете да го видите мапирањето без погодување. apachectl -S печати секој домаќин, неговиот порт и имињата и означува кој е стандарден за адресата.

RequireAll е контејнерот што ги прави двете проверки задолжителни

Apache 2.4 ги завиткува наредбите Require на еден дел во имплицитен RequireAny, па две голи наредби значат дека која било од нив е доволна. Додајте го контејнерот и значењето се превртува:

<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 бара двата услови: изворна адреса во опсегот на тунелот и корисник што складиштето го прифаќа. Тоа треба да значи само-VPN за Subversion URL. Референцата за mod_authz_core ги документира правилата на контејнерот. Оставете го блокот во постоечкиот Location за складиштето и оставете ги на место наредбите DAV што веќе работат, бидејќи овој фрагмент не заменува ниту AuthType, ниту датотеката со лозинки, ниту авторизација на ниво на патека.

Проверката на изворот доаѓа од mod_authz_host, затоа потврдете дека е вчитан пред да отстранувате грешки во нешто друго: apachectl -M | grep authz_host.

Адресата што Apache ја оценува е адресата на приклучокот

Require ip споредува со адресата што Apache ја запишал за врската, а тоа не е секогаш адресата што клиентот мисли дека ја има.

Кога VPN ги насочува своите адреси без превод, Apache ја гледа адресата на тунелот и 10.8.0.0/24 се совпаѓа. Кога порта преведува, Apache ја гледа портата и правилото тивко не се совпаѓа со ништо; истото се случува зад балансер што завршува TLS пред домаќинот. За тој случај постои mod_remoteip. RemoteIPHeader X-Forwarded-For заедно со RemoteIPTrustedProxy за балансерот ја заменува запишаната адреса и само тогаш опсегот има со што да се споредува.

Да се верува на произволна глава за препраќање е полошо отколку воопшто да нема правило. Секој клиент може да испрати X-Forwarded-For со 10.8.0.9 и да задоволи проверка на опсег што никогаш не била закотвена на доверлив скок.

Слојте ги слушателот и политиката на складиштето

Врзувањето е одделна контрола и често поедноставната. Listen 10.8.0.1:443 одлучува кои приклучоци постојат, а барање не може да избере домаќин на приклучок што никогаш не бил отворен. Цената е редот на стартување: ако интерфејсот на тунелот е исклучен кога Apache стартува, врзувањето не успева и услугата не се крева. Спрегнете го со редот на единиците или врзете го на адреса што постои независно од тунелот.

Дозволите за патека остануваат во AuthzSVNAccessFile. Валидна сметка за сајтот не е исто овластување како правото за пишување на патека на проект, и мрежното правило тоа не го менува.

Внимавајте на спојувањето на делови кога блокот е во вклучена датотека. Apache ги спојува контејнерите за авторизација низ вгнездени делови и најконкретниот совпаднат дел може да го замени барањето наместо да го дополни, па правилото на /svn може да не стигне до /svn/repo/trunk кога потесен дел дефинира свој.

Докажете ги двете одбивања пред да го наречете готово

Тестирајте четири барања, не едно. Во VPN со валидна сметка треба да ја добиете листата на складиштето. Во VPN со погрешна лозинка треба да добиете 401 наместо листа. Однадвор на VPN со валидни акредитиви треба да добиете 403, а истото јавно барање до алтернативно име на домаќин мора да не успее на ист начин.

Една наредба по случај е доволна: curl -sI -u user:pass https://svn.example.com/svn/repo/, потоа прочитајте ја линијата за статус. Повторете го работниот случај и преку вистинскиот клиент, бидејќи svn info ги вежба DAV методите што ќе ги користат commit и ажурирањата.

Ако кој било од четирите резултати не се согласува со политиката што ја сакавте, конфигурацијата не е завршена и преименувањето на домаќинот нема да го смени тоа.