ಕಾರ್ಪೊರೇಟ್ VPN ಹಿಂದೆ ಆ್ಯಪ್ ವಿನಂತಿಗಳು ವಿಫಲವಾಗುತ್ತವೆ, ಆದರೆ ಬ್ರೌಸರ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ

ನೀವು ಬ್ರೌಸರ್‌ನಲ್ಲಿ ಆಂತರಿಕ ಪೋರ್ಟಲ್ ತೆರೆಯುತ್ತೀರಿ, ಅದು ಲೋಡ್ ಆಗುತ್ತದೆ. ಅದೇ ಹೋಸ್ಟ್ ಅನ್ನು ಕರೆಯುವ ಆ್ಯಪ್ ಅನ್ನು ರನ್ ಮಾಡುತ್ತೀರಿ, ಅದು ವಿಫಲವಾಗುತ್ತದೆ, ಯಾವ ಪದರದ ಹೆಸರನ್ನೂ ಹೇಳದ ಸಂದೇಶದೊಂದಿಗೆ. ಟನೆಲ್ ಬ್ರೌಸರ್ ಅನ್ನು ಹೊತ್ತೊಯ್ಯುತ್ತಿದೆ, ಆದ್ದರಿಂದ ಟನೆಲ್ ಮೊದಲ ಶಂಕಿತನಲ್ಲ. ನಿಮ್ಮ ವಿನಂತಿ ಮತ್ತು ಸೇವೆಯ ನಡುವೆ ನಾಲ್ಕು ವಸ್ತುಗಳಿವೆ, ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ಬೇರೆ ಗುರುತು ಬಿಡುತ್ತದೆ. ನಾನು ಅನುಸರಿಸುವ ಕ್ರಮ ಇದು: VPN ಕ್ಲೈಂಟ್‌ನ ಸೆಟ್ಟಿಂಗ್ಸ್ ಪುಟದಿಂದ ಅಲ್ಲ, ಆ್ಯಪ್ ನಿಜವಾಗಿ ಕಳುಹಿಸುವ ವಿನಂತಿಯಿಂದ ಪ್ರಾರಂಭ.

ಆ್ಯಪ್ ನಿಜವಾಗಿ ಕಳುಹಿಸುವ ವಿನಂತಿಯನ್ನು ನೋಡಿ

ಕಾನ್ಫಿಗರೇಶನ್ ಮುಟ್ಟುವ ಮೊದಲು ಆ್ಯಪ್ ಏನು ಮಾಡುತ್ತದೆ ಎಂದು ಅದೇ ಹೇಳಲಿ. ಪ್ರಾಕ್ಸಿಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ ಒಂದು ವಿನಂತಿಯ ಸೆರೆಹಿಡಿಯುವಿಕೆ ಮತ್ತು ಸರಳ ಪೋರ್ಟ್ ಪರೀಕ್ಷೆ ನಿಮಗೆ ಎರಡು ಮೂಲರೇಖೆಗಳನ್ನು ಕೊಡುತ್ತವೆ, ಮುಂದಿನ ಹಂತಗಳನ್ನು ಅವುಗಳೊಂದಿಗೆ ಹೋಲಿಸಲಾಗುತ್ತದೆ. ಪ್ರಾಕ್ಸಿ ಆಫ್ ಇದ್ದಾಗ ವಿನಂತಿ ಯಶಸ್ವಿಯಾದರೆ, ನಾಲ್ಕರಲ್ಲಿ ಮೂರು ಪದರಗಳು ಮುಗಿದಿವೆ.

env | grep -i proxy            # Linux/macOS
netsh winhttp show proxy       # Windows, machine-wide
curl -sv --noproxy '*' https://svc.internal/
nc -vz svc.internal 8080

ಕೊನೆಯ ಎರಡನ್ನು ಅದೇ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ರನ್ ಮಾಡಿ ಮತ್ತು ಅವು ಎಲ್ಲಿ ಬೇರೆಯಾಗುತ್ತವೆ ಎಂದು ನೋಡಿ. ಕೆಲಸ ಮಾಡುವ ಬ್ರೌಸರ್ ಜೊತೆಗೆ ಕೆಲಸ ಮಾಡುವ curl ಜೊತೆಗೆ ಕೆಲಸ ಮಾಡದ ಆ್ಯಪ್ ಸಮಸ್ಯೆಯನ್ನು ಆ್ಯಪ್ ಸೇರಿಸುವ ಒಂದಕ್ಕೆ ಸಂಕುಚಿಸುತ್ತವೆ: ಪ್ರಾಕ್ಸಿ, ಸಾಗಣೆ ಅಥವಾ ಸಂದೇಶದ ಗಾತ್ರ.

ಆ್ಯಪ್ ಯಾರೂ ಕಾನ್ಫಿಗರ್ ಮಾಡದ ಪ್ರಾಕ್ಸಿಯನ್ನು ವಾರಸುದಾರರಾಗಿ ಪಡೆದಿದೆ

ಹೆಚ್ಚಿನ HTTP ಸ್ಟ್ಯಾಕ್‌ಗಳು ಡಿಫಾಲ್ಟ್ ಆಗಿ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ನಿಂದ ಪ್ರಾಕ್ಸಿ ಕಾನ್ಫಿಗರೇಶನ್ ಓದುತ್ತವೆ. ಕಾರ್ಪೊರೇಟ್ VPN ಕ್ಲೈಂಟ್ ಸಾಮಾನ್ಯವಾಗಿ ತನ್ನ ಪ್ರವೇಶ ಪ್ರೊಫೈಲ್‌ನ ಭಾಗವಾಗಿ ಒಂದನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ವಿನಂತಿಗಳು ಡೆವಲಪರ್ ಕೋಡ್‌ನಲ್ಲಿ ಎಂದೂ ಉಲ್ಲೇಖಿಸದ ಪ್ರಾಕ್ಸಿಯ ಮೂಲಕ ಹೊರಡುತ್ತವೆ. .NET ನಲ್ಲಿ ಡಿಫಾಲ್ಟ್ ಹ್ಯಾಂಡ್ಲರ್ IE/WinHTTP ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಂದ ಎಳೆದುಕೊಳ್ಳುತ್ತದೆ; Java -Dhttp.proxyHost ಓದುತ್ತದೆ; Node ಗೆ ಲೈಬ್ರರಿ ಸೇರಿಸುವವರೆಗೆ ಒಳಗೊಂಡ ಪ್ರಾಕ್ಸಿ ಬೆಂಬಲವಿಲ್ಲ. ವೈಫಲ್ಯ ಅಪರೂಪಕ್ಕೆ ಸ್ವಚ್ಛ ನಿರಾಕರಣೆ, ಆದ್ದರಿಂದ ಜನರು ಸರ್ವರ್‌ನತ್ತ ನೋಡಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ.

ಪರೀಕ್ಷೆಗೆ ಒಂದು ವಿನಂತಿಯ ವೆಚ್ಚ: ಒಂದು ಹ್ಯಾಂಡ್ಲರ್‌ನಲ್ಲಿ ಪ್ರಾಕ್ಸಿಯನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಆಫ್ ಮಾಡಿ ಮತ್ತು ಹೋಲಿಸಿ.

var handler = new HttpClientHandler { UseProxy = false };
using var client = new HttpClient(handler);

ಅದು ಯಶಸ್ವಿಯಾದರೆ, ಸರಿಪಡಿಸುವಿಕೆ ಟನೆಲ್‌ನಲ್ಲಲ್ಲ, ಆ್ಯಪ್‌ನ ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿದೆ. ಯೋಜನೆಯ ಪ್ರತಿ ರನ್‌ಟೈಮ್‌ಗೂ ಆಡಿಟ್ ಪುನರಾವರ್ತಿಸಿ, ಏಕೆಂದರೆ ಪ್ರತಿಯೊಂದೂ ಬೇರೆ ಮೂಲ ಓದುತ್ತದೆ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೇ ಮುರಿದಿರಬಹುದು.

ನೀವು ಆಯ್ಕೆ ಮಾಡಿದ ಪೋರ್ಟ್ ನೀತಿ ಅನುಮತಿಸುವ ಪೋರ್ಟ್ ಅಲ್ಲ

ರೂಟ್ ಮಾಡಿದ ಹೋಸ್ಟ್ ಅನುಮತಿಸಿದ ಸೇವೆ ಅಲ್ಲ. ಕಾರ್ಪೊರೇಟ್ ನೀತಿ ಸಾಮಾನ್ಯವಾಗಿ ಹೊರಹೋಗುವ ವೆಬ್ ಪೋರ್ಟ್‌ಗಳನ್ನು ಅನುಮತಿಸಿ ಉಳಿದವನ್ನು ಬಿಡುತ್ತದೆ, ಆದ್ದರಿಂದ 8080 ಅಥವಾ 1883 ನಲ್ಲಿನ ಸೇವೆ ತಲುಪಲಾಗದಂತಿದ್ದರೆ 443 ಚೆನ್ನಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಬ್ರೌಸರ್ ಇಲ್ಲಿ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ: ಅದು ವ್ಯಾಖ್ಯಾನದಂತೆ 443 ಬಳಸುತ್ತದೆ.

ಅದೇ ಸೇವೆಯನ್ನು 443 ಹಿಂದೆ ಪ್ರಕಟಿಸಿ ಮತ್ತು ವಿನಾಯಿತಿ ಕೇಳುವ ಮೊದಲು ಹೆಸರಿನಿಂದ ಅದನ್ನು ತಲುಪಿ. ವಿನಾಯಿತಿ ನಿಜವಾಗಿಯೂ ಬೇಕಾದರೆ, ಅದನ್ನು ಒಂದು ಮೂಲ ಶ್ರೇಣಿ ಮತ್ತು ಒಂದು ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಸೀಮಿತಗೊಳಿಸಿ ಮತ್ತು ಅದನ್ನು ಸೇವೆಯ ವ್ಯಾಖ್ಯಾನದ ಭಾಗವೆಂದು ಪರಿಗಣಿಸಿ, ಯಾರೋ ಒಬ್ಬರ ವೈಯಕ್ತಿಕ ಪರಿಹಾರವಲ್ಲ.

ಮಾರ್ಗವು ಮರುಹೊಂದಿಸುವ ಕಚ್ಚಾ TCP

ದೀರ್ಘಕಾಲ ಬದುಕುವ ಕಚ್ಚಾ TCP ಸಂಪರ್ಕಗಳು ಅತ್ಯಂತ ಗೊಂದಲಮಯವಾಗಿ ವಿಫಲವಾಗುವ ಪದರ. ವೆಬ್ ಸಂಚಾರವನ್ನು ಅನುಮತಿಸುವ ಮಾರ್ಗವೂ ಸಹ ಅಸಾಮಾನ್ಯ ಹೊರಹೋಗುವ TCP ಅನ್ನು ಮರುಹೊಂದಿಸಬಹುದು ಅಥವಾ ಮತ್ತೆ ಬರೆಯಬಹುದು, ಮತ್ತು ಕ್ಲೈಂಟ್ ಅಡಚಣೆಯಂತೆ ಓದುವ ಸಾಕೆಟ್ ದೋಷವನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ. ಸಂದೇಶ ಮತ್ತು ಈವೆಂಟ್ ಸೇವೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಇಂತಹ ನೆಟ್‌ವರ್ಕ್‌ಗಾಗಿಯೇ WebSocket ಸಾಗಣೆಯನ್ನು ಒದಗಿಸುತ್ತವೆ, ಮತ್ತು ಬದಲಾಯಿಸುವುದು ಕ್ಲೈಂಟ್‌ನ ಆಯ್ಕೆ, ಟನೆಲ್‌ನ ಬದಲಾವಣೆ ಅಲ್ಲ.

ಸಾಗಣೆಯನ್ನು ಬದಲಾಯಿಸಿ, ಮತ್ತೆ ಪರೀಕ್ಷಿಸಿ ಮತ್ತು ಅದೇ ರನ್ನಲ್ಲಿ ಬೇರೆ ಏನನ್ನೂ ಬದಲಾಯಿಸಬೇಡಿ. ಆ ಒಂದು ಚರ ಪರೀಕ್ಷೆ ಮರುಹೊಂದಿಕೆ ಮಾರ್ಗದಿಂದ ಬಂತೋ ಸೇವೆಯಿಂದ ಬಂತೋ ಎಂದು ಹೇಳುತ್ತದೆ.

ದೊಡ್ಡ ಪೇಲೋಡ್‌ಗಳಲ್ಲಿ ಮಾತ್ರ ಮುಚ್ಚುವ ಸಂಪರ್ಕಗಳು

ಯಶಸ್ವಿಯಾಗಿ ನಂತರ ಸುಮಾರು ಒಂದು ಸೆಕೆಂಡಿನ ಬಳಿಕ ಸಾಯುವ ವಿನಂತಿ, ಆದರೆ ದೇಹ ದೊಡ್ಡದಿದ್ದಾಗ ಮಾತ್ರ, ಮಧ್ಯದಲ್ಲಿ ಎಲ್ಲೋ ಇರುವ ಗಾತ್ರ ಮಿತಿಯತ್ತ ಸೂಚಿಸುತ್ತದೆ. ಸಂದೇಶದ ಬೈಟ್‌ಗಳನ್ನು ಎಣಿಸುವ ಮಧ್ಯವರ್ತಿ ಸಂಪರ್ಕವನ್ನು ವರ್ಗಾವಣೆಯ ಮಧ್ಯದಲ್ಲಿ ಬಿಡಬಹುದು, ಮತ್ತು ಕ್ಲೈಂಟ್ ಸಮಯ ಮೀರಿಕೆಯ ಬದಲು ಅಸಹಜ ಮುಚ್ಚುವಿಕೆಯನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ.

ಪೇಲೋಡ್ ಅನ್ನು ಆ್ಯಪ್ ಪದರದಲ್ಲಿ ತುಂಡುಗಳಾಗಿ ಮಾಡಿ. ಅದನ್ನು MTU ಕೆಲಸದಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿಡಿ: ಟನೆಲ್‌ನ ಪ್ಯಾಕೆಟ್ ಗಾತ್ರವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು ಸಾಮಾನ್ಯ TCP ಸೆಷನ್‌ಗಳು ಸ್ಥಿರ ಬೈಟ್ ಎಣಿಕೆಯಲ್ಲಿ ನಿಲ್ಲುವಾಗ ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಮಧ್ಯವರ್ತಿ ತುಂಬಾ ದೊಡ್ಡದೆಂದು ಭಾವಿಸುವ ಸಂದೇಶಕ್ಕೆ ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ.

ಒಂದೇ ಹಂತದಲ್ಲಿ ನಾಲ್ಕನ್ನು ಹೇಗೆ ಬೇರ್ಪಡಿಸುವುದು

ಮೂರು ಅವಲೋಕನಗಳು ಬಹುಪಾಲು ಪ್ರಕರಣಗಳನ್ನು ಇತ್ಯರ್ಥಪಡಿಸುತ್ತವೆ. ವೈಫಲ್ಯ ತಕ್ಷಣ ಸಂಭವಿಸುತ್ತದೆಯೇ ಅಥವಾ ದೊಡ್ಡ ದೇಹದೊಂದಿಗೆ ಮಾತ್ರವೇ? ಪ್ರಾಕ್ಸಿ ಆಫ್ ಇದ್ದಾಗ ಅದೇ ವಿನಂತಿ ಯಶಸ್ವಿಯಾಗುತ್ತದೆಯೇ? ಪೋರ್ಟ್ ಅಥವಾ ಸಾಗಣೆ ಬದಲಾಯಿಸಿದಾಗ ಫಲಿತಾಂಶ ಬದಲಾಗುತ್ತದೆಯೇ? ಮುಂದಿನ ಬದಲಾವಣೆಗೆ ಮೊದಲು ಉತ್ತರಗಳನ್ನು ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ಕಾರ್ಪೊರೇಟ್ VPN ಜೊತೆಗೆ ವಾರಸುದಾರ ಪ್ರಾಕ್ಸಿ ಜೊತೆಗೆ ಆ್ಯಪ್‌ನ ಡಿಫಾಲ್ಟ್ ಒಟ್ಟಿಗೆ ಮೂರು ಸಂಭಾವ್ಯ ಕಾರಣಗಳನ್ನು ಕೊಡುತ್ತವೆ.

ಪ್ರತಿ ಪರೀಕ್ಷೆಗೆ ಒಂದು ಚರವನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ ಮತ್ತು ನೀವು ಬಳಸಿದ ಗಮ್ಯಸ್ಥಾನ ಹೋಸ್ಟ್ ಅನ್ನು ದಾಖಲಿಸಿ. ಆ ಮೂಲರೇಖೆ ಇಲ್ಲದಿದ್ದರೆ ಮುಂದಿನ ವ್ಯಕ್ತಿ ನಾಲ್ಕೂ ಹಂತಗಳನ್ನು ಮತ್ತೆ ಪ್ರಾರಂಭದಿಂದ ಪುನರಾವರ್ತಿಸುತ್ತಾರೆ.