Apache 2.4 ಬಳಸಿ Subversion ಹೋಸ್ಟ್ ಅನ್ನು VPN ಬಳಕೆದಾರರಿಗೆ ಸೀಮಿತಗೊಳಿಸಿ

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 ಎರಡೂ ಷರತ್ತುಗಳನ್ನು ಕೇಳುತ್ತದೆ: ಸುರಂಗ ಶ್ರೇಣಿಯೊಳಗಿನ ಮೂಲ ವಿಳಾಸ ಮತ್ತು ಸಂಗ್ರಹವು ಸ್ವೀಕರಿಸುವ ಬಳಕೆದಾರ. Subversion URL ಗೆ ಕೇವಲ-VPN ಎಂದರೆ ಇದೇ ಅರ್ಥವಾಗಬೇಕು. 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 ಇದೆ. ಬ್ಯಾಲೆನ್ಸರ್ಗಾಗಿ RemoteIPTrustedProxy ಜೊತೆಗೆ RemoteIPHeader X-Forwarded-For ದಾಖಲಾದ ವಿಳಾಸವನ್ನು ಬದಲಿಸುತ್ತದೆ, ಮತ್ತು ಆಗ ಮಾತ್ರ ಶ್ರೇಣಿಗೆ ಹೋಲಿಸಲು ಏನಾದರೂ ಇರುತ್ತದೆ.

ಯಾವುದೇ ಫಾರ್ವರ್ಡಿಂಗ್ ಹೆಡರ್ ಅನ್ನು ನಂಬುವುದು ಯಾವುದೇ ನಿಯಮವಿಲ್ಲದಿರುವುದಕ್ಕಿಂತ ಕೆಟ್ಟದು. ಯಾವುದೇ ಕ್ಲೈಂಟ್ 10.8.0.9 ಹೊಂದಿರುವ X-Forwarded-For ಕಳುಹಿಸಿ, ವಿಶ್ವಾಸಾರ್ಹ ಹಾಪ್ಗೆ ಎಂದಿಗೂ ಲಂಗರು ಹಾಕದ ಶ್ರೇಣಿ ಪರಿಶೀಲನೆಯನ್ನು ಪೂರೈಸಬಹುದು.

ಶ್ರೋತ ಮತ್ತು ಸಂಗ್ರಹ ನೀತಿಯನ್ನು ಪದರಗಳಾಗಿ ಮಾಡಿ

ಬೈಂಡಿಂಗ್ ಪ್ರತ್ಯೇಕ ನಿಯಂತ್ರಣ ಮತ್ತು ಹೆಚ್ಚಾಗಿ ಸರಳವಾದದ್ದು. 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 ವಿಧಾನಗಳನ್ನು ಅಭ್ಯಾಸ ಮಾಡುತ್ತದೆ.

ನಾಲ್ಕರಲ್ಲಿ ಯಾವುದೇ ಫಲಿತಾಂಶ ನೀವು ಉದ್ದೇಶಿಸಿದ ನೀತಿಗೆ ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ, ಸಂರಚನೆ ಮುಗಿದಿಲ್ಲ, ಮತ್ತು ಹೋಸ್ಟ್ನ ಹೆಸರು ಬದಲಾಯಿಸುವುದರಿಂದ ಅದು ಬದಲಾಗುವುದಿಲ್ಲ.