VPN ಸೈಟ್‌ನ 403 ಪ್ರಾಕ್ಸಿ ವೈಫಲ್ಯ ಏಕೆ ಅಲ್ಲ
ಮೂಲದಿಂದ 403, ನಿರಾಕರಿಸಲಾದ CONNECT ಮತ್ತು 407 ಸವಾಲು ಬೇರೆ ಬೇರೆ ಗಡಿಗಳನ್ನು ಸೂಚಿಸುತ್ತವೆ. ಮೊದಲು ಪ್ರಾಕ್ಸಿಯ ನಿರ್ಗಮನ ಮಾರ್ಗವನ್ನು ಬ್ರೌಸರ್‌ನ VPN ವಿಳಾಸದೊಂದಿಗೆ ಹೋಲಿಸಿ.
ಬಳಕೆದಾರರು VPN ಕಡಿತಗೊಳಿಸುತ್ತಾರೆ, ಆಂತರಿಕ ಸೈಟ್‌ನಲ್ಲಿ 403 ಎದುರಿಸುತ್ತಾರೆ ಮತ್ತು ಪ್ರಾಕ್ಸಿ ಕೆಟ್ಟಿದೆ ಎಂದು ವರದಿ ಮಾಡುತ್ತಾರೆ. ಆ ಪುಟವನ್ನು ಮೂರು ಪ್ರತ್ಯೇಕ ವಿಷಯಗಳು ಉತ್ಪಾದಿಸಬಹುದು: ಮೂಲವು ವಿನಂತಿಯನ್ನು ನಿರಾಕರಿಸಿತು, ಫಾರ್ವರ್ಡ್ ಪ್ರಾಕ್ಸಿ ಸುರಂಗ ತೆರೆಯಲು ನಿರಾಕರಿಸಿತು, ಅಥವಾ ಪ್ರಾಕ್ಸಿ ತನ್ನದೇ ರುಜುವಾತುಗಳನ್ನು ಕೇಳಿತು. ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಬೇರೆ ಪ್ರಶ್ನೆಗೆ ಸರಿಯಾದ ಉತ್ತರ, ಮತ್ತು ಅವನ್ನು ಒಂದು ಸಾಮಾನ್ಯ ವೈಫಲ್ಯ ಪುಟಕ್ಕೆ ಚಪ್ಪಟೆಗೊಳಿಸುವುದು ನಿಮ್ಮ ಬಳಿ ಇರುವ ಏಕೈಕ ಸಾಕ್ಷ್ಯವನ್ನು ನಾಶಮಾಡುತ್ತದೆ. ನಿರಾಕರಣೆಯನ್ನು ಅದನ್ನು ಉಂಟುಮಾಡಿದ ಘಟಕದ ಪ್ರಕಾರ ಜೋಡಿಸಿ, ನಂತರ ಪ್ರತಿ ಘಟಕವು ನಿಜವಾಗಿ ಬಳಸುವ ನೆಟ್‌ವರ್ಕ್ ಮಾರ್ಗವನ್ನು ಹೋಲಿಸಿ.
403 ಉತ್ಪಾದಿಸಿದ ಘಟಕವನ್ನು ಹೆಸರಿಸಿ
HTTP ಸ್ಥಿತಿ ಕೋಡ್ ಅದನ್ನು ಕಳುಹಿಸಿದ ಪಕ್ಷಕ್ಕೆ ಸೇರಿದೆ. ಮೂಲವು 403 ಹಿಂತಿರುಗಿಸಿದಾಗ, ಅದು ವಿನಂತಿಯನ್ನು ವಿಶ್ಲೇಷಿಸಿ, ಕರೆಗಾರನ ಬಳಿ ಸಂಪನ್ಮೂಲ ಇಲ್ಲದಿರಬಹುದು ಎಂದು ನಿರ್ಧರಿಸಿದೆ, ಇದು ಅಧಿಕಾರದ ಉತ್ತರ, ಸಾರಿಗೆ ಸಮಸ್ಯೆ ಅಲ್ಲ. ಫಾರ್ವರ್ಡ್ ಪ್ರಾಕ್ಸಿ CONNECT ಗೆ 403 ಉತ್ತರಿಸಿದಾಗ, ಅದು ಸುರಂಗವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿರ್ಮಿಸಲು ನಿರಾಕರಿಸಿತು, ಮತ್ತು ಮೇಲಿನ ಯಾರನ್ನೂ ಎಂದೂ ಸಂಪರ್ಕಿಸಲಿಲ್ಲ. ಅದು 407 ಉತ್ತರಿಸಿದಾಗ, ತನ್ನದೇ ರುಜುವಾತುಗಳನ್ನು ಬಯಸುತ್ತದೆ, ಅವುಗಳಿಗೆ ಅಪ್ಲಿಕೇಶನ್ ಲಾಗಿನ್‌ನೊಂದಿಗೆ ಯಾವುದೇ ಸಂಬಂಧವಿಲ್ಲ.
| What you observe | What it means |
|---|---|
| Origin replies 403 | The origin understood the request and denied it |
| Proxy refuses CONNECT with 403 | The proxy declined to open that tunnel |
| Proxy replies 407 | Proxy authentication is required first |
| Gateway replies 502 or 504 | Upstream failure or timeout, not a permission decision |
RFC 9110 ಈ ಪಾತ್ರಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ, ಪ್ರಾಕ್ಸಿ-ನಿರ್ದಿಷ್ಟ ಸವಾಲು ಸೇರಿದಂತೆ. ಮುಖ್ಯ ಭಾಗ ಓದುವ ಮೊದಲು ಪ್ರತಿಕ್ರಿಯೆಯ ಸ್ವಂತ ಸ್ಥಿತಿ ಮತ್ತು ಯಾವುದೇ Proxy-Authenticate ಹೆಡರ್ ಓದಿ, ಏಕೆಂದರೆ ಸ್ನೇಹಪರ HTML ದೋಷ ಪುಟ ಸಾಮಾನ್ಯವಾಗಿ ಯಾವ ಘಟಕ ಬರೆದಿದೆ ಎಂಬುದನ್ನು ಮರೆಮಾಡುತ್ತದೆ.
CONNECT ಸುರಂಗ ಬೈಟ್ ರಿಲೇನಿಂದ ಏನನ್ನು ಮರೆಮಾಡುತ್ತದೆ
ಪ್ರಾಕ್ಸಿ CONNECT ಗೆ 200 ಹಿಂತಿರುಗಿಸಿದ ನಂತರ ಅದು ಬೈಟ್‌ಗಳನ್ನು ರವಾನಿಸುತ್ತಿದೆ ಮತ್ತು ಬ್ರೌಸರ್ ಮೂಲದೊಂದಿಗೆ ತನ್ನದೇ TLS ಸೆಷನ್ ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ. ಆದ್ದರಿಂದ ಬೈಟ್ ರವಾನಿಸುವ ಪ್ರಾಕ್ಸಿ ಆ ಸೆಷನ್ ಒಳಗಿನ ಗೂಢಲಿಪೀಕೃತ 403 ಓದಲಾರದು, ಮತ್ತು ಅದು ಎಂದೂ ನಿರಾಕರಣೆಯ ಲೇಖಕನಾಗುವುದಿಲ್ಲ. ಸುರಂಗ ತೆರೆಯುವ ಮೊದಲಿನ ನಿರಾಕರಣೆ ಸಂಪೂರ್ಣವಾಗಿ ಬೇರೆ ಘಟನೆ, ಒಂದು ಪದರ ಕೆಳಗೆ ಉತ್ಪಾದನೆಯಾಗುತ್ತದೆ.
TLS ಮುಗಿಸುವ ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ ಬೇರೆ ಸ್ಥಾನದಲ್ಲಿದೆ: ಅದು TLS ಗಡಿಯ ಮಾಲೀಕ, HTTP ವಿಶ್ಲೇಷಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಕಾನೂನುಬದ್ಧವಾಗಿ ಮರುಬರೆಯಬಹುದು ಅಥವಾ ಪ್ರತಿಬಂಧಿಸಬಹುದು. ಆ ಸಾಮರ್ಥ್ಯ ಸಂರಚನೆಯ ಆಯ್ಕೆ, ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರಾಕ್ಸಿಯ ಗುಣವಲ್ಲ, ಮತ್ತು ಅದು ಅಪ್ಲಿಕೇಶನ್‌ನ ಪ್ರವೇಶ ನೀತಿಯನ್ನು ಬೈಪಾಸ್ ಮಾಡಲು ಅಧಿಕಾರ ನೀಡುವುದಿಲ್ಲ. ಪ್ರತಿಕ್ರಿಯೆ ಓದುವುದು ಸಾಮರ್ಥ್ಯ; ಕರೆಗಾರ ಏನನ್ನು ನೋಡಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವುದು ಮೂಲದ ಕೆಲಸವೇ ಉಳಿಯುತ್ತದೆ.
ಪ್ರಾಯೋಗಿಕ ಪರಿಣಾಮವೆಂದರೆ 403 ಅನ್ನು ಅರ್ಥೈಸುವ ಮೊದಲು ನೀವು ಮೂರು ಆಕಾರಗಳಲ್ಲಿ ಯಾವುದನ್ನು ನಡೆಸುತ್ತೀರಿ ಎಂಬುದನ್ನು ತಿಳಿಯಬೇಕು. ಸ್ಟ್ರೀಮ್ ಪ್ರಾಕ್ಸಿಗೆ HTTP ತಪಾಸಣೆ ನಿಯಮಗಳನ್ನು ಸೇರಿಸುವುದು ಅದಕ್ಕೆ ಗೋಚರತೆ ನೀಡುವುದಿಲ್ಲ, ಮತ್ತು ಬೈಟ್ ರಿಲೇ ಮೂಲದ ನಿರಾಕರಣೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ ಎಂದು ನಿರೀಕ್ಷಿಸುವುದು ನಿಮ್ಮನ್ನು ತಪ್ಪು ಲಾಗ್‌ಗೆ ಕಳುಹಿಸುತ್ತದೆ.
ಪ್ರಾಕ್ಸಿಯ ನಿರ್ಗಮನ ಮಾರ್ಗವನ್ನು ಬ್ರೌಸರ್‌ನ ಸುರಂಗ ವಿಳಾಸದೊಂದಿಗೆ ಹೋಲಿಸಿ
VPN ಗೆ ಸಂಪರ್ಕಗೊಂಡ ಬ್ರೌಸರ್ ಪ್ರತ್ಯೇಕ ಪ್ರಾಕ್ಸಿ ಸರ್ವರ್ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಆ ಸುರಂಗಕ್ಕೆ ಸರಿಸುವುದಿಲ್ಲ. ಮೂಲವು ಪ್ರಾಕ್ಸಿಯ ನಿರ್ಗಮನ ವಿಳಾಸ ಎಂಬುದನ್ನು ನೋಡುತ್ತದೆ, ಮತ್ತು ಪ್ರಾಕ್ಸಿ ಇನ್ನೂ ಸ್ಥಳೀಯ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗದ ಮೂಲಕ ಹೊರಹೋದರೆ, ಸಂರಕ್ಷಿತ ಸೈಟ್ ನಂಬಲು ಎಂದೂ ಸಂರಚಿಸದ ವಿಳಾಸವನ್ನು ನೋಡುತ್ತದೆ. ಲ್ಯಾಪ್‌ಟಾಪ್‌ನ ಒಳಗಿನ VPN ವಿಳಾಸ ಆ ಮೂಲಕ್ಕೆ ಅದೃಶ್ಯ. ಕೆಲಸ ಮಾಡುವ ಸುರಂಗವೂ ಉಳಿದವರಿಗೆ ಸರಿಯಾಗಿ ವರ್ತಿಸುವ ಸೈಟ್‌ನಿಂದ 403 ನೀಡುವುದಕ್ಕೆ ಇದೇ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ಕಾರಣ.
ವಿಳಾಸಗಳು ಗೊಂದಲಗೊಳ್ಳದಂತೆ ಎರಡೂ ಮಾರ್ಗಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ.
curl -sS -o /dev/null -w 'status=%{http_code}\n' --noproxy '*' https://198.51.100.20/private
curl -sS -o /dev/null -w 'status=%{http_code}\n' -x http://203.0.113.10:3128 https://198.51.100.20/privateಮೊದಲ ವಿನಂತಿ ನಿಮ್ಮ ಸ್ವಂತ ವಿಳಾಸಕ್ಕೆ ಮೂಲ ಏನು ಉತ್ತರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ, ಎರಡನೆಯದು ಪ್ರಾಕ್ಸಿಯ ವಿಳಾಸಕ್ಕೆ ಏನು ಉತ್ತರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ. ಹೊಂದಿಕೆಯಾಗುವ 403 ಜೋಡಿ ಮೂಲದ ಅಧಿಕಾರ ನಿಯಮಗಳನ್ನು ಸೂಚಿಸುತ್ತದೆ; 200 ನಂತರ 403 ಬಂದರೆ ಪ್ರಾಕ್ಸಿ ಮಾರ್ಗವನ್ನು ಸೂಚಿಸುತ್ತದೆ. VPN ಪೂಲ್ ಸೇರಿದೆ ಎಂದು ಊಹಿಸುವ ಬದಲು ನಿಯಮಗಳ ಗುಂಪು ನಿಜವಾಗಿ ಯಾವ ಮೂಲ ವಿಳಾಸಗಳನ್ನು ಒಪ್ಪುತ್ತದೆ ಎಂದು ಮೂಲದ ಮಾಲೀಕರನ್ನು ಕೇಳಿ.
ಗಡಿಯನ್ನು ಪ್ರತ್ಯೇಕಿಸುವ ವಿನಂತಿಯೊಂದಿಗೆ ಪ್ರತಿ ಗಡಿಯನ್ನು ಪರೀಕ್ಷಿಸಿ
ಪ್ರಾಕ್ಸಿ ಪದರವನ್ನು ಅಪ್ಲಿಕೇಶನ್ ಕಾರಣಗಳಿಗಾಗಿ ನಿರಾಕರಿಸಲಾಗದ ವಿಷಯವನ್ನು ಕೇಳುವ ಮೂಲಕ ಪ್ರತ್ಯೇಕಿಸಿ. ಪ್ರಾಕ್ಸಿಗೆ ತಲುಪಲು ಅನುಮತಿ ಇರುವ ಹೋಸ್ಟ್‌ಗೆ CONNECT, ಔಟ್‌ಪುಟ್ ಎಸೆದು, ಸುರಂಗ ಪ್ರವೇಶವು ಎಲ್ಲಾದರೂ ಕೆಲಸ ಮಾಡುತ್ತದೆಯೇ ಎಂದು ಹೇಳುತ್ತದೆ.
curl -sSv -o /dev/null -x http://203.0.113.10:3128 https://198.51.100.20/ 2>&1 | grep -E 'CONNECT|HTTP/1.1|Proxy-Authenticate'
ಅದು CONNECT ಗೆ 200 ಮತ್ತು ನಂತರ TLS ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಮುದ್ರಿಸಿದರೆ, ಪ್ರಾಕ್ಸಿ ಪ್ರವೇಶ ಸರಿಯಾಗಿದೆ ಮತ್ತು ನಂತರದ 403 ಮೂಲದಿಂದ ಬಂದಿದೆ. ಅದು 407 ಮುದ್ರಿಸಿದರೆ, --proxy-user ನೊಂದಿಗೆ ಪ್ರಾಕ್ಸಿ ರುಜುವಾತುಗಳನ್ನು ಒದಗಿಸಿ ಮತ್ತು ಸೈಟ್ ಬಗ್ಗೆ ಯಾವುದೇ ತೀರ್ಮಾನಕ್ಕೆ ಬರುವ ಮೊದಲು ಪುನರಾವರ್ತಿಸಿ. ಅದು CONNECT ಸಾಲಿನಲ್ಲಿ 403 ಮುದ್ರಿಸಿದರೆ, ಪ್ರಾಕ್ಸಿಯ ಸ್ವಂತ ಅನುಮತಿ ಪಟ್ಟಿಯೇ ಪರಿಶೀಲಿಸಬೇಕಾದ ಗಡಿ, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಇದರಲ್ಲಿ ಒಳಗೊಂಡಿಲ್ಲ.
ರುಜುವಾತುಗಳನ್ನು ಶೆಲ್ ಇತಿಹಾಸ ಮತ್ತು ಅಂಟಿಸಿದ ಟ್ರಾನ್ಸ್‌ಕ್ರಿಪ್ಟ್‌ಗಳಿಂದ ದೂರವಿಡಿ. ಆದೇಶ ಸಾಲಿನಲ್ಲಿ ಟೈಪ್ ಮಾಡಿದ ಪ್ರಾಕ್ಸಿ ಪಾಸ್‌ವರ್ಡ್ ಇತರ ಸ್ಥಳೀಯ ಬಳಕೆದಾರರಿಗೆ ಗೋಚರಿಸುತ್ತದೆ, ಮತ್ತು ರುಜುವಾತುಗಳೊಂದಿಗೆ ಸೆರೆಹಿಡಿದ CONNECT ಕುರುಹು ಯಾವುದೇ ಕುರುಹು ಇಲ್ಲದಿರುವುದಕ್ಕಿಂತ ಕೆಟ್ಟದು.
ಪುಟವನ್ನು ಮರುಬರೆಯುವ ಬದಲು ತೀರ್ಪನ್ನು ಓದಬಲ್ಲದಾಗಿ ಇರಿಸಿ
ಯಾವ ಘಟಕ ನಿರಾಕರಿಸಿತು ಎಂದು ತಿಳಿದ ನಂತರ ಆ ಉತ್ತರವನ್ನು ಸಂರಕ್ಷಿಸಿ. ಮೂಲದ 403 ಅನ್ನು 504 ಟೈಮೌಟ್ ಎಂದು ಮರುಲೇಬಲ್ ಮಾಡುವ, ಅಥವಾ ಅದನ್ನು ಯಶಸ್ಸಿನ ಪುಟದಿಂದ ಬದಲಾಯಿಸುವ ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ ಅಧಿಕಾರದ ನಿರ್ಧಾರವನ್ನು ಲಭ್ಯತೆಯ ಕಥೆಯ ಹಿಂದೆ ಮರೆಮಾಡಿ ಮುಂದಿನ ಪ್ರತಿಸ್ಪಂದಕನನ್ನು ತಪ್ಪು ತಂಡಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ. ಕಸ್ಟಮ್ ದೋಷ ಪುಟಗಳು ಸ್ಥಿತಿಯನ್ನು ಉಳಿಸಿಕೊಂಡು ಸಂದರ್ಭ ಸೇರಿಸಿದಾಗ ಸರಿ.
ಕ್ಯಾಶಿಂಗ್ ಕೂಡ ಅದೇ ಕಾಳಜಿಗೆ ಅರ್ಹ. RFC 9111 ಹಂಚಿದ ಕ್ಯಾಶ್‌ಗಳು ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಹೇಗೆ ಮರುಬಳಸಬಹುದು ಎಂಬುದನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ, ಮತ್ತು ಒಬ್ಬ ಕರೆಗಾರನಿಗೆ ಉತ್ಪಾದಿಸಿದ ನಿರಾಕರಣೆಯನ್ನು ಅನುಮತಿ ಎಂಬಂತೆ ಇನ್ನೊಬ್ಬರಿಗೆ ನೀಡಬಾರದು. ನಿರಾಕರಣೆ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸಿದರೆ, ಅವನ್ನು ಖಾಸಗಿ ಮತ್ತು ಸೀಮಿತವಾಗಿ ಇರಿಸಿ, ಮತ್ತು ಮೇಲಿನ ಸಂಚಾರ ಕಡಿಮೆ ಮಾಡಲು ಮಾತ್ರ ಸಾರ್ವಜನಿಕ ತಾಜಾತನ ನಿಯಮವನ್ನು ಎಂದೂ ಸೇರಿಸಬೇಡಿ.
ಘಟಕ, ಅದು ಉತ್ಪಾದಿಸಿದ ಸ್ಥಿತಿ ಮತ್ತು ಮೂಲವು ನೋಡಿದ ಮೂಲ ವಿಳಾಸವನ್ನು ಹೆಸರಿಸುವ ಲಿಖಿತ ತೀರ್ಪಿನೊಂದಿಗೆ ಮುಗಿಸಿ. ನಿಖರ ವಿನಂತಿ, ಜಾರಿಯಲ್ಲಿರುವ ಪ್ರಾಕ್ಸಿ ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಮತ್ತು ಸಮಯವನ್ನು ದಾಖಲಿಸಿ, ಇದರಿಂದ ಮುಂದಿನ ವರದಿಯನ್ನು ಸ್ಮೃತಿಯಿಂದ ಮತ್ತೆ ಪಡೆಯುವ ಬದಲು ಅದೇ ಸಾಕ್ಷ್ಯಗಳೊಂದಿಗೆ ಹೋಲಿಸಬಹುದು. ಆ ದಾಖಲೆ ಮುಂದಿನ ವರದಿಗೆ ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಉತ್ತರಿಸುತ್ತದೆ ಮತ್ತು ಅದೇ 403 ಮತ್ತೆ VPN ಅಡಚಣೆ ಎಂದು ನಿರ್ಣಯಿಸುವುದನ್ನು ತಡೆಯುತ್ತದೆ.