TLS ಪರಿಶೀಲಿಸುವ ಪ್ರಾಕ್ಸಿಯ ಹಿಂದೆ SSTP: ಸೆಷನ್ ಎಲ್ಲಿ ಮುರಿಯುತ್ತದೆ

ನಿಮ್ಮ ಬ್ರೌಸರ್ ಕಾರ್ಪೊರೇಟ್ ಇಂಟ್ರಾನೆಟ್ ಅನ್ನು ಲೋಡ್ ಮಾಡುತ್ತದೆ, ಪ್ರಾಕ್ಸಿ ಪ್ರಮಾಣಪತ್ರವು ನಂಬಲರ್ಹವಾಗಿದೆ, ಆದರೂ SSTP ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕದ ಅಂತ್ಯದ ಹತ್ತಿರ ಕುಸಿಯುತ್ತದೆ. ಈ ಮಾದರಿ ತಪ್ಪು ಪಾಸ್ವರ್ಡ್ ಅಲ್ಲ, ಬದಲಿಗೆ ವೆಬ್ ವಿನಂತಿ ಮತ್ತು ಸುರಂಗ ಸೆಷನ್ ನಡುವಿನ ವ್ಯತ್ಯಾಸವನ್ನು ಸೂಚಿಸುತ್ತದೆ. TCP ನಿಂದ ಮೇಲಕ್ಕೆ ಸಂಪರ್ಕವನ್ನು ಸಾಗಿಸಿ ವಿಫಲವಾಗುವ ಮೊದಲ ಹಂತವನ್ನು ದಾಖಲಿಸಿ. ಪ್ರಾಕ್ಸಿಯೇ ಕಾರಣವೇ ಎಂದು ದೋಷ ಕೋಡ್ ಅಲ್ಲ, ಹಂತವೇ ಹೇಳುತ್ತದೆ.

ಕ್ಲೈಂಟ್ ನಿಲ್ಲುವ ಸ್ಥಳದಿಂದ ಪ್ರಾರಂಭಿಸಿ

ಕ್ಲೈಂಟ್ ನಿಗದಿತ ಕ್ರಮದ ಮೂಲಕ ಸಾಗುತ್ತದೆ: ಪೋರ್ಟ್ 443 ಗೆ TCP ಸಂಪರ್ಕ, TLS ಹ್ಯಾಂಡ್ಶೇಕ್, ಪ್ರಮಾಣಪತ್ರ ಮೌಲ್ಯೀಕರಣ, SSTP ನ HTTP ವಿನಿಮಯ, PPP ಮಾತುಕತೆ ಮತ್ತು ದೃಢೀಕರಣ, ನಂತರ IP ಸಂರಚನೆ. ಪ್ರತಿ ಹಂತದ ವೈಫಲ್ಯ ಬೇರೆ ಗುರುತನ್ನು ಬಿಡುತ್ತದೆ, ಮತ್ತು ಅವನ್ನು ಗೊಂದಲಿಸುವುದು ನಿಮ್ಮನ್ನು ತಪ್ಪು ಸಂರಚನಾ ಪುಟಕ್ಕೆ ಕರೆದೊಯ್ಯುತ್ತದೆ.

TCP ವೈಫಲ್ಯ ಎಂದರೆ ಯಾವುದೇ TLS ಬೈಟ್ ಕಾಣಿಸಿಕೊಳ್ಳುವ ಮೊದಲು ಸಮಯ ಮೀರಿಕೆ ಅಥವಾ ಮರುಹೊಂದಿಕೆ. TLS ವೈಫಲ್ಯ ಎಂದರೆ ಎಚ್ಚರಿಕೆ ಅಥವಾ ಹ್ಯಾಂಡ್ಶೇಕ್ ಸಮಯ ಮೀರಿಕೆ. ಪ್ರಮಾಣಪತ್ರ ವೈಫಲ್ಯ ಸರಪಳಿ ಅಥವಾ ಹೆಸರಿನ ಬಗ್ಗೆ ಎಚ್ಚರಿಕೆ ನೀಡುತ್ತದೆ. HTTP ವೈಫಲ್ಯ ಯಶಸ್ವಿ ಹ್ಯಾಂಡ್ಶೇಕ್ ನಂತರ ಬರುತ್ತದೆ, ಹೆಚ್ಚಾಗಿ ಸ್ಥಿತಿ ಕೋಡ್ ಅಥವಾ ತಕ್ಷಣ ಮುಚ್ಚುವಿಕೆಯ ರೂಪದಲ್ಲಿ. PPP ವೈಫಲ್ಯ ಸುರಂಗ ತಾಂತ್ರಿಕವಾಗಿ ಸ್ಥಾಪನೆಯಾದ ನಂತರ ಬರುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದು ದೃಢೀಕರಣ ಸಮಸ್ಯೆಯಂತೆ ಕಾಣುತ್ತದೆ.

ಮೊದಲ ದೋಷ ಸಾಲಿನ ಬದಲು ಕ್ಲೈಂಟ್ ಲಾಗ್ನಲ್ಲಿ ಕೊನೆಯ ಯಶಸ್ವಿ ಹಂತವನ್ನು ಓದಿ. ದೋಷ ಸಾಲು ಸಾಮಾನ್ಯವಾಗಿ ಪರಿಣಾಮವನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ಆದರೆ ಹಂತದ ಗಡಿ ನಿರಾಕರಿಸಿದ ಘಟಕವನ್ನು ಹೆಸರಿಸುತ್ತದೆ.

SSTP ನೆಟ್ವರ್ಕ್ನಿಂದ ಏನನ್ನು ಸಾಗಿಸಬೇಕೆಂದು ಕೇಳುತ್ತದೆ

SSTP TCP 443 ನಲ್ಲಿ TLS ಮೇಲೆ ಚಲಿಸುತ್ತದೆ ಮತ್ತು ನಂತರ SSTP ವಿಶೇಷಣದಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ SSTP_DUPLEX_POST ಎಂಬ HTTP ವಿನಂತಿಯನ್ನು /sra_{GUID}/ ರೂಪದ ಮಾರ್ಗಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ. ವಿನಂತಿ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಅಪರಿಮಿತ ವಿಷಯ ಉದ್ದವನ್ನು ಘೋಷಿಸುತ್ತದೆ ಮತ್ತು ಸೆಷನ್ ನ ಇಡೀ ಅವಧಿಯಲ್ಲಿ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ತೆರೆದಿಡುತ್ತದೆ. PPP ಫ್ರೇಮ್ಗಳು ಆ ಸ್ಟ್ರೀಮ್ ಒಳಗೆ ಚಲಿಸುತ್ತವೆ.

ಆದ್ದರಿಂದ ಸಾಮಾನ್ಯ ಬ್ರೌಸಿಂಗ್ ನಿರ್ವಹಿಸುವ ಪ್ರಾಕ್ಸಿಯೂ ವಿಫಲವಾಗಬಹುದು. ಸೀಮಿತ ಬಾಡಿ ಇರುವ GET ಅಥವಾ POST ಅನ್ನು ಬಫರ್ ಮಾಡಿ, ಪರಿಶೀಲಿಸಿ ಮುಂದೆ ಕಳುಹಿಸಬಹುದು; ಎಂದಿಗೂ ಮುಗಿಯದ ಬಾಡಿ ಇರುವ ಡ್ಯುಪ್ಲೆಕ್ಸ್ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಸಾಧ್ಯವಿಲ್ಲ. ಬಾಡಿ ಪೂರ್ಣಗೊಳ್ಳಲು ಕಾಯುವ ಪ್ರಾಕ್ಸಿ ಶಾಶ್ವತವಾಗಿ ಕಾಯುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಕೊನೆಗೆ ಸಮಯ ಮೀರಿಕೆಗೆ ಒಳಗಾಗುತ್ತದೆ.

ವಿಧಾನ ಫಿಲ್ಟರಿಂಗ್ ಮತ್ತು ದೃಢೀಕರಣ ತಮ್ಮದೇ ವೈಫಲ್ಯ ವಿಧಾನಗಳನ್ನು ಸೇರಿಸುತ್ತವೆ. ಪ್ರಾಕ್ಸಿ ವಿನಂತಿಗೆ ರುಜುವಾತುಗಳನ್ನು ಕೇಳಿದರೆ, ಬ್ರೌಸರ್ ಉತ್ತರಿಸಿದರೂ VPN ಕ್ಲೈಂಟ್ ಉತ್ತರಿಸದೇ ಇರಬಹುದು. ಅದು ವಿಧಾನವನ್ನು ತೆಗೆದುಹಾಕಿದರೆ ಅಥವಾ ಮತ್ತೆ ಬರೆದರೆ, ಗೇಟ್ವೇ PPP ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲೇ ವಿನಂತಿಯನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ.

ಪರಿಶೀಲನೆ ಗುರುತನ್ನು ಏಕೆ ಬದಲಿಸುತ್ತದೆ

TLS ಪರಿಶೀಲಿಸುವ ಪ್ರಾಕ್ಸಿ ಕ್ಲೈಂಟ್ ನ TLS ಸಂಪರ್ಕವನ್ನು ಕೊನೆಗೊಳಿಸಿ ಗೇಟ್ವೇಗೆ ಪ್ರತ್ಯೇಕ ಸಂಪರ್ಕವನ್ನು ತೆರೆಯುತ್ತದೆ. ಆದ್ದರಿಂದ ಕ್ಲೈಂಟ್ ಗೇಟ್ವೇಯದಲ್ಲ, ಪ್ರಾಕ್ಸಿಯ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಮೌಲ್ಯೀಕರಿಸುತ್ತದೆ, ಮತ್ತು ಗೇಟ್ವೇ ಪ್ರಾಕ್ಸಿಯನ್ನು ತನ್ನ ಸಹಯೋಗಿ ಎಂದು ನೋಡುತ್ತದೆ. ಸಂಸ್ಥೆ ತನ್ನದೇ ಮೂಲವನ್ನು ಹಂಚಿದಾಗ, ಬ್ರೌಸರ್ ಮತ್ತು VPN ಕ್ಲೈಂಟ್ ಎರಡೂ ಆ ಸರಪಳಿಯನ್ನು ಸ್ವೀಕರಿಸಬಹುದು, ಹಾಗಾಗಿ ಹ್ಯಾಂಡ್ಶೇಕ್ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ ಮತ್ತು ಸಮಸ್ಯೆ ಮುಂದಿನ ಹಂತಕ್ಕೆ ಹೋಗುತ್ತದೆ.

ಯಶಸ್ವಿ ಮೌಲ್ಯೀಕರಣ ಎಂದರೆ ಪ್ರಾಕ್ಸಿ ಸೆಷನ್ ಅನ್ನು ಸಾಗಿಸಬಲ್ಲದು ಎಂದಲ್ಲ. ಅದು ಇನ್ನೂ ಬಫರಿಂಗ್ ಇಲ್ಲದೆ ಅಪರಿಮಿತ ದ್ವಿಮುಖ POST ಅನ್ನು ರವಾನಿಸಬೇಕು ಮತ್ತು ಎರಡೂ ಸಂಪರ್ಕಗಳನ್ನು ಗಂಟೆಗಳ ಕಾಲ ಜೀವಂತವಾಗಿಡಬೇಕು. ಅನೇಕ ಪರಿಶೀಲನಾ ಉತ್ಪನ್ನಗಳು ವಿನಂತಿ-ಪ್ರತಿಕ್ರಿಯೆ ಸಂಚಾರಕ್ಕಾಗಿ ನಿರ್ಮಿಸಲಾಗಿವೆ ಮತ್ತು ಈ ಪ್ರಕರಣವನ್ನು ಕೆಟ್ಟದಾಗಿ ಅಥವಾ ಸಂಪೂರ್ಣವಾಗಿ ನಿರ್ವಹಿಸುವುದಿಲ್ಲ.

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

ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಬದಲಿಸುವ ಮೊದಲು ನೀಡುಗರನ್ನು ಗುರುತಿಸಿ

ಎಂಡ್ಪಾಯಿಂಟ್ಗೆ ಯಾವ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತದೆ ಮತ್ತು ಯಾರು ಅದಕ್ಕೆ ಸಹಿ ಹಾಕಿದ್ದಾರೆ ಎಂದು ಕೇಳಿ. ಕೆಳಗಿನ ಆದೇಶಗಳು VPN ಸೆಷನ್ ಪ್ರಾರಂಭಿಸದೆ ಸರಪಳಿ ಮತ್ತು ನೀಡುಗರನ್ನು ತೋರಿಸುತ್ತವೆ:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts
curl -vI https://vpn.example.com/

ನೀಡುಗರು ಸಾರ್ವಜನಿಕ CA ಆಗಿದ್ದರೆ, ಈ ಹೋಸ್ಟ್ಗೆ ಸಂಪರ್ಕವನ್ನು ತಡೆಯುತ್ತಿಲ್ಲ ಮತ್ತು ವೈಫಲ್ಯ ಬೇರೆಡೆ ಇದೆ. ನೀಡುಗರು ಸಂಸ್ಥೆಯ ಸ್ವಂತ CA ಆಗಿದ್ದರೆ, ಪರಿಶೀಲನೆ ಸಕ್ರಿಯವಾಗಿದೆ ಮತ್ತು ಗೇಟ್ವೇಯನ್ನು ಪ್ರಾಕ್ಸಿ ಮೂಲಕ ತಲುಪಲಾಗುತ್ತದೆ. ಕೇವಲ ಹೆಸರಿನಿಂದ ತೀರ್ಮಾನಿಸುವ ಮೊದಲು ಫಿಂಗರ್ಪ್ರಿಂಟ್ ಅನ್ನು ನೆಟ್ವರ್ಕ್ ತಂಡ ನಿರೀಕ್ಷಿಸುವುದರೊಂದಿಗೆ ಹೋಲಿಸಿ.

ಅದೇ ಹೋಸ್ಟ್ಗೆ ಬ್ರೌಸರ್ ಪರೀಕ್ಷೆ ಪ್ರಾಕ್ಸಿ GET ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. ಅದು SSTP ವಿಧಾನ, ವಿನಂತಿ URI ಅಥವಾ ಬಾಡಿಯ ಆಯುಷ್ಯದ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಕೆಲಸ ಮಾಡುವ ಇಂಟ್ರಾನೆಟ್ ಪುಟವನ್ನು ಸುರಂಗ ಮಾರ್ಗಕ್ಕೆ ಬೆಂಬಲವಿದೆ ಎಂಬ ಸಾಕ್ಷ್ಯವೆಂದು ಪರಿಗಣಿಸಬೇಡಿ.

ಬೆಂಬಲಿತ ಮಾರ್ಗವನ್ನು ಆರಿಸಿ

ನೆಟ್ವರ್ಕ್ ಮಾಲೀಕರಿಗೆ ಒಂದು ನಿರ್ದಿಷ್ಟ ಪ್ರಶ್ನೆ ಕೇಳಿ: ಪ್ರಾಕ್ಸಿ ಈ ಗೇಟ್ವೇಗೆ ಪೋರ್ಟ್ 443 ನಲ್ಲಿ ಬಫರ್ ಇಲ್ಲದ ಡ್ಯುಪ್ಲೆಕ್ಸ್ POST ಅನ್ನು ಅನುಮತಿಸುತ್ತದೆಯೇ? ಹೌದು ಎಂದರೆ ಪ್ರಾಕ್ಸಿಯಲ್ಲಿ ವಿನಾಯಿತಿ ಅಥವಾ VPN ಹೋಸ್ಟ್ಗೆ ದಾಖಲಿತ ಬೈಪಾಸ್. ಇಲ್ಲ ಎಂದರೆ ಪರಿಶೀಲಿಸಿದ ಮಾರ್ಗ SSTP ಅನ್ನು ಸಾಗಿಸಲಾರದು, ಮತ್ತು ಬೆಂಬಲಿತ ಪರಿಹಾರ ಕ್ಲೈಂಟ್ ತಿದ್ದುಪಡಿಯಲ್ಲ, ಬದಲಿಗೆ ಬೇರೆ ಮಾರ್ಗ ಅಥವಾ ಪ್ರೋಟೋಕಾಲ್.

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

ಫಲಿತಾಂಶವನ್ನು ದಾಖಲಿಸಿ: ನೀಡುಗರು, ವಿಫಲ ಹಂತ, ಪ್ರಾಕ್ಸಿ ನಿಯಮ ಮತ್ತು ಆಯ್ಕೆಮಾಡಿದ ಮಾರ್ಗ. ಮುಂದಿನ ವ್ಯಕ್ತಿ ಅದೇ 98 ಪ್ರತಿಶತದ ನಿಲುಗಡೆಯನ್ನು ನೋಡಿದಾಗ ಇಡೀ ಸಂಚಾರವನ್ನು ಪುನರಾವರ್ತಿಸುವ ಬದಲು ಒಂದು ಸತ್ಯವನ್ನು ಪರಿಶೀಲಿಸಬಹುದು.