Apache AllowCONNECT ಮತ್ತು HTTPS ಗಮ್ಯಸ್ಥಾನ ಪೋರ್ಟ್‌ಗಳು

ನಿಮ್ಮ Apache ಪ್ರಾಕ್ಸಿ ಪೋರ್ಟ್ 3128 ನಲ್ಲಿ ಕೇಳುತ್ತದೆ. ಒಂದು ಕ್ಲೈಂಟ್ ಅದನ್ನು ಯಶಸ್ವಿಯಾಗಿ ತಲುಪುತ್ತದೆ, ಆದರೆ ಪೋರ್ಟ್ 8443 ನಲ್ಲಿನ HTTPS ಸೇವೆ ವಿಫಲವಾಗುತ್ತದೆ. ಪ್ರಾಕ್ಸಿಯ ಕೇಳುವ ಪೋರ್ಟ್ ಬದಲಾಯಿಸುವುದು ಆ ನಿರ್ದಿಷ್ಟ ವ್ಯತ್ಯಾಸವನ್ನು ಪರಿಹರಿಸುವ ಸಾಧ್ಯತೆ ಕಡಿಮೆ.

ಕ್ಲೈಂಟ್ ಮೊದಲು ಪ್ರಾಕ್ಸಿ ಶ್ರೋತೃಕ್ಕೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ. ನಂತರ ಅದರ CONNECT ವಿನಂತಿ ಪ್ರತ್ಯೇಕ ಗಮ್ಯಸ್ಥಾನ ಹೋಸ್ಟ್ ಮತ್ತು ಪೋರ್ಟ್ ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ. Apache ಮೊದಲ ಸಂಪರ್ಕವನ್ನು ಸ್ವೀಕರಿಸಿ ಎರಡನೇ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ತಿರಸ್ಕರಿಸಬಹುದು.

AllowCONNECT ಅನ್ನು ಗಮ್ಯಸ್ಥಾನ ನೀತಿಯಾಗಿ ಓದಿ

Apache 2.4 ಗಾಗಿ, mod_proxy_connect ಒಳಬರುವ CONNECT ವಿನಂತಿಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಅದರ AllowCONNECT ಸೂಚನೆಯು ಆ ವಿನಂತಿಗಳಿಗೆ ಲಭ್ಯವಿರುವ ಗಮ್ಯಸ್ಥಾನ ಪೋರ್ಟ್‌ಗಳನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ. ದಾಖಲಿತ ಡೀಫಾಲ್ಟ್ 443 ಮತ್ತು 563 ಆಗಿದೆ.

AllowCONNECT 443 8443

ಈ ಉದಾಹರಣೆ ಆ ಎರಡು ಗಮ್ಯಸ್ಥಾನ ಪೋರ್ಟ್‌ಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ಇದು ಡೀಫಾಲ್ಟ್ ಆಯ್ಕೆಯನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ; ಇದು 8443 ಅನ್ನು ಸೇರಿಸುವುದಿಲ್ಲ ಮತ್ತು ಎಲ್ಲಾ ಡೀಫಾಲ್ಟ್ ಪೋರ್ಟ್‌ಗಳನ್ನು ಸದ್ದಿಲ್ಲದೆ ಉಳಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ. ಸೂಚನೆಯನ್ನು ಅನ್ವಯವಾಗುವ ಸರ್ವರ್ ಅಥವಾ ವರ್ಚುವಲ್-ಹೋಸ್ಟ್ ಸಂರಚನೆಯಲ್ಲಿ ಬಳಸಿ.

ಇರಿಸಿಕೊಳ್ಳಿ ಪ್ರಾಕ್ಸಿಯ ಕ್ಲೈಂಟ್ ಅಧಿಕಾರ ನಿಯಮಗಳನ್ನು ಜಾಗದಲ್ಲೇ. ಅನುಮತಿಸಲಾದ ಗಮ್ಯಸ್ಥಾನ ಪೋರ್ಟ್ ಯಾವ ಕ್ಲೈಂಟ್ ಸೇವೆಯನ್ನು ಬಳಸಬಹುದು ಎಂಬುದನ್ನು ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ಅಗತ್ಯವಿದ್ದಾಗ ಗಮ್ಯಸ್ಥಾನ-ಹೋಸ್ಟ್ ನಿರ್ಬಂಧಕ್ಕೆ ಅದು ಪರ್ಯಾಯವಲ್ಲ.

ರಿವರ್ಸ್-ಪ್ರಾಕ್ಸಿ ಉದಾಹರಣೆ ಬೇರೆ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ

Apache ಮತ್ತು HTTPS ಗಾಗಿ ಹುಡುಕಾಟ ಫಲಿತಾಂಶಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಸ್ಥಿರ ಬ್ಯಾಕೆಂಡ್‌ಗೆ ಮುಂದಕ್ಕೆ ರವಾನಿಸುವ ಸಾರ್ವಜನಿಕ ವೆಬ್‌ಸೈಟ್ ಅನ್ನು ತೋರಿಸುತ್ತವೆ. ಆ ಸಂರಚನೆಯು ಬ್ರೌಸರ್ ಆಯ್ಕೆಮಾಡಿದ ವೆಬ್‌ಸೈಟ್‌ಗೆ CONNECT ಟನೆಲ್ ತೆರೆಯಲು ಫಾರ್ವರ್ಡ್ ಪ್ರಾಕ್ಸಿಗೆ ಕೇಳುವ ರೀತಿ ಅಲ್ಲ. ಅದರ ರೂಟಿಂಗ್ ಸೂಚನೆಗಳನ್ನು ನಕಲಿಸುವುದು ಮೂಲ ಪ್ರಾಕ್ಸಿ ಸಮಸ್ಯೆಯನ್ನು ಮುಟ್ಟದೆ ಬಿಡಬಹುದು.

ವಿಫಲತೆಯನ್ನು ರೋಗನಿರ್ಣಯ ಮಾಡುವಾಗ, ಕ್ಲೈಂಟ್ ತಲುಪಿದ ಶ್ರೋತೃ, ವಿನಂತಿಸಿದ CONNECT ಅಧಿಕಾರ ಮತ್ತು ಪ್ರಾಕ್ಸಿಯ ಪ್ರತ್ಯುತ್ತರವನ್ನು ದಾಖಲಿಸಿ. CONNECT ಯಶಸ್ವಿಯಾಗಿ ನಂತರ TLS ವಿಫಲವಾದರೆ, ಗಮ್ಯಸ್ಥಾನ-ಪೋರ್ಟ್ ಅನುಮತಿ ತನ್ನ ಪಾತ್ರವನ್ನು ಈಗಾಗಲೇ ನಿರ್ವಹಿಸಿದೆ. ಮುಂದುವರಿಯಿರಿ TLS ವಿಫಲತೆಯೊಂದಿಗೆ AllowCONNECT ಅನ್ನು ಪದೇ ಪದೇ ವಿಸ್ತರಿಸುವ ಬದಲು.