ಬ್ರೌಸರ್‌ನ HTTPS ಯಶಸ್ವಿಯಾಗುವಲ್ಲಿ SSTP ವಿಫಲವಾಗುತ್ತದೆ: ಏಕೆ
SSTP ಪೋರ್ಟ್ 443 ರಲ್ಲಿ TLS ಒಳಗೆ ಚಲಿಸುತ್ತದೆ, ಆದರೆ ಅದು ವೆಬ್ ವಿನಂತಿಯಲ್ಲ. TCP, TLS ಗುರುತು, SSTP ವಿನಿಮಯ ಮತ್ತು PPP ದೃಢೀಕರಣವನ್ನು ಪ್ರತ್ಯೇಕ ಹಂತಗಳಾಗಿ ಪರೀಕ್ಷಿಸಿ.
ಬ್ರೌಸರ್ VPN ಹೋಸ್ಟ್‌ಹೆಸರನ್ನು HTTPS ಮೂಲಕ ಯಾವುದೇ ದೂರಿಲ್ಲದೆ ತೆರೆಯುತ್ತದೆ, ಮತ್ತು SSTP ಕ್ಲೈಂಟ್ ಇನ್ನೂ ಸಂಪರ್ಕಿಸಲು ನಿರಾಕರಿಸುತ್ತದೆ. ಆ ಜೋಡಿಯಲ್ಲಿ ವಿರೋಧಾಭಾಸವಿಲ್ಲ. SSTP TLS ಅನ್ನು ಹೊರ ಸಾಗಣೆಯಾಗಿ ಬಳಸಿ ನಂತರ ಅದೇ ಸಂಪರ್ಕದ ಒಳಗೆ ತನ್ನ ವಿನಂತಿ ಮತ್ತು PPP ಪೇಲೋಡ್ ಅನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಪುಟದ ಯಶಸ್ವಿ ಲೋಡ್ ಒಂದೇ ಸಣ್ಣ ವಿಷಯವನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ: ಹೋಸ್ಟ್ ಪೋರ್ಟ್ 443 ರಲ್ಲಿ GET ಗೆ ಉತ್ತರಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಬೇರೆ ಪ್ರಶ್ನೆ ಕೇಳುತ್ತಿದೆ, ಮತ್ತು ಸರ್ವರ್ ಅದಕ್ಕೆ ಕೆಟ್ಟದಾಗಿ ಉತ್ತರಿಸಬಹುದು.
ಪುಟ ಲೋಡ್ ಆಗುತ್ತದೆ ಮತ್ತು ಸುರಂಗ ಆಗುವುದಿಲ್ಲ
ಜನರು ಬ್ರೌಸರ್ ಪರೀಕ್ಷೆಗೆ ಹೋಗುತ್ತಾರೆ ಏಕೆಂದರೆ ಅದು ವೇಗವಾಗಿದೆ, ನಂತರ ಫಲಿತಾಂಶವನ್ನು ಸರ್ವರ್ ತಲುಪಬಹುದಾದ ಮತ್ತು ಸಂರಚಿಸಲಾದ ಎಂಬ ಪುರಾವೆಯಾಗಿ ತೆಗೆದುಕೊಳ್ಳುತ್ತಾರೆ. ಇದು ವಿಳಾಸ ಪಟ್ಟಿ ತೆರೆದ ಮಾರ್ಗಕ್ಕೆ GET ಬಗ್ಗೆ ಪುರಾವೆ, ಅಷ್ಟೇ. VPN ಸಂಭಾಷಣೆ ಅದೇ TLS ಹ್ಯಾಂಡ್‌ಶೇಕ್ ನಂತರ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಆದರೆ ಕಳುಹಿಸುತ್ತದೆ ವೆಬ್ ಪುಟ ಎಂದಿಗೂ ಬಳಸದ ವಿಧಾನ ಮತ್ತು ಮಾರ್ಗವನ್ನು. ಆದ್ದರಿಂದ ಬ್ರೌಸರ್‌ಗೆ 200 ಉತ್ತರವು SSTP ಎಂಡ್‌ಪಾಯಿಂಟ್ ಇದೆಯೇ ಎಂಬ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.
ಎರಡು ಅವಲೋಕನಗಳನ್ನು ಬೇರ್ಪಡಿಸಿ ಮತ್ತು ಹುಡುಕಾಟ ಚಿಕ್ಕದಾಗುತ್ತದೆ. ಸಾಗಣೆ ಮತ್ತು ಪ್ರಮಾಣಪತ್ರ ಸರಪಳಿ ಕೆಲಸ ಮಾಡುತ್ತವೆ, ಮತ್ತು ಅವುಗಳ ಮೇಲಿನ ಪ್ರೋಟೋಕಾಲ್ ವಿನಿಮಯದಲ್ಲಿ ಏನೋ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ. ಇದು ಮುರಿದ ಪೋರ್ಟ್ ಅಥವಾ ಅವಧಿ ಮುಗಿದ ಪ್ರಮಾಣಪತ್ರಕ್ಕಿಂತ ಬೇರೆ ತನಿಖೆ, ಮತ್ತು ಬೇರೆ ಸಾಕ್ಷ್ಯ ಬೇಕು.
SSTP ಕ್ಲೈಂಟ್ ನಿಜವಾಗಿ ಏನು ಕಳುಹಿಸುತ್ತದೆ
ಕ್ಲೈಂಟ್ /sra_{GUID}/ ಮಾರ್ಗಕ್ಕೆ SSTP_DUPLEX_POST ವಿಧಾನದೊಂದಿಗೆ HTTP ವಿನಂತಿ ಕಳುಹಿಸಿ, ನಂತರ ಸಂಪರ್ಕದ ಬಾಡಿಯನ್ನು PPP ಚೌಕಟ್ಟುಗಳನ್ನು ಸಾಗಿಸುವ ದ್ವಿಮುಖ ಸ್ಟ್ರೀಮ್ ಆಗಿ ತೆರೆದಿಡುತ್ತದೆ. ಅನುಸರಣ ಸರ್ವರ್ HTTP/1.1 200 ಎಂದು ಉತ್ತರಿಸಿ ವೆಬ್ ಸರ್ವರ್‌ನಂತೆ ವರ್ತಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ. ಬೇರೆ ಯಾವುದೇ ವಿಷಯ ಒಂದು ಸಹಿ: 405 ಅಥವಾ 404 ಎಂದರೆ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಇಲ್ಲ, 301 ಅಥವಾ 302 ಎಂದರೆ ಏನೋ ವಿನಂತಿಯನ್ನು ಮರುನಿರ್ದೇಶಿಸುತ್ತಿದೆ, ಮತ್ತು ತಕ್ಷಣದ FIN ಎಂದರೆ ಪ್ರಾಕ್ಸಿ ಅಥವಾ ಸರ್ವರ್ ಸ್ಟ್ರೀಮ್ ಮುಚ್ಚಿದೆ.
ಆದ್ದರಿಂದ ಗುರಿ TLS ಪ್ರಮಾಣಪತ್ರ ಜೋಡಿಸಿದ ವೆಬ್ ಸರ್ವರ್ ಅಲ್ಲ, SSTP ಸರ್ವರ್ ಆಗಿರಬೇಕು. ವಿಧಾನ, ಮಾರ್ಗ ಮತ್ತು ದೀರ್ಘಕಾಲಿಕ ಬಾಡಿ ಪ್ರೋಟೋಕಾಲ್ ಅವಶ್ಯಕತೆಗಳು, ಆದ್ದರಿಂದ ರಿವರ್ಸ್ ಪ್ರಾಕ್ಸಿ ಅವುಗಳನ್ನು ಸಂರಚನೆಯಿಂದ ಮಾತ್ರ ಸೇರಿಸಲಾಗದು. ಸಾಮಾನ್ಯ HTTPS ಅನ್ನು ಪರಿಪೂರ್ಣವಾಗಿ ರವಾನಿಸುವ ಪ್ರಾಕ್ಸಿ ಕೂಡ ತನಗೆ ಗೊತ್ತಿಲ್ಲದ ವಿಧಾನವನ್ನು ನಿರಾಕರಿಸಬಹುದು.
ಪ್ರಾಕ್ಸಿ ಅಥವಾ ವೆಬ್ ಸರ್ವರ್ ಸ್ಟ್ರೀಮ್ ಎಲ್ಲಿ ಮುರಿಯುತ್ತದೆ
ಮಧ್ಯಸ್ಥನು ಏನನ್ನಾದರೂ ರವಾನಿಸುವ ಮೊದಲು HTTP ವಿನಂತಿ ಸಾಲನ್ನು ಪರಿಶೀಲಿಸುತ್ತಾನೆ, ಮತ್ತು ಅಸಾಮಾನ್ಯ ಮಾರ್ಗವಿರುವ ಕಸ್ಟಮ್ ವಿಧಾನ ಅವನ ನಿಯಮಗಳಲ್ಲಿ ವಿಫಲವಾಗಬಹುದು. ಕೆಲವು ಸಾಧನಗಳು ಸಾಮಾನ್ಯ ಪುಟವನ್ನು ನೀಡುತ್ತವೆ ಆದರೆ ಸುರಂಗವನ್ನು ನಿರಾಕರಿಸುತ್ತವೆ ಅಥವಾ ಅಡ್ಡಿಪಡಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಕ್ಲೈಂಟ್ ಸ್ವಚ್ಛ ನಿರಾಕರಣೆಯ ಬದಲು ಪ್ರಾರಂಭವಾಗಿ ನಂತರ ಸಾಯುವ ಸಂಪರ್ಕವನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ. ಇತರರು ವಿನಂತಿಯನ್ನು ಸ್ವೀಕರಿಸಿ ನಂತರ PPP ಕೀಪ್‌ಅಲೈವ್‌ಗಳು ತಡೆಯಲಾಗದ ಬಾಡಿ ಅಥವಾ ನಿಷ್ಕ್ರಿಯತೆಯ ಟೈಮೌಟ್ ಅನ್ನು ಅನ್ವಯಿಸುತ್ತವೆ. ಕ್ಲೈಂಟ್ ಕಡೆಯಿಂದ ಎರಡೂ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ, ಆದ್ದರಿಂದ ಯಾವ ಹಂತ ವಿಫಲವಾಯಿತು ಎಂಬುದು ದೋಷ ಪಠ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚು ಮುಖ್ಯ.
ವೆಬ್‌ಸೈಟ್ ಮತ್ತು SSTP ನಡುವೆ ಪೋರ್ಟ್ 443 ಹಂಚುವುದು ರೂಟಿಂಗ್ ಆಯ್ಕೆ, ಪ್ರತಿ ಹಾಪ್ ಎರಡೂ ಸಂಭಾಷಣೆಗಳನ್ನು ಒಂದೇ ರೀತಿ ನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬ ಭರವಸೆ ಅಲ್ಲ. ಮಾರ್ಗದಲ್ಲಿ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್, ಫೈರ್‌ವಾಲ್ ಅಥವಾ TLS ಟರ್ಮಿನೇಟರ್ ಇದ್ದರೆ, VPN ಸಂರಚನೆಯನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಅದನ್ನು ಸಂಶಯಿತ ಪಟ್ಟಿಗೆ ಸೇರಿಸಿ.
ಹಂತಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ
ಪರಿಶೀಲನೆಗಳನ್ನು ಕ್ರಮವಾಗಿ ಚಲಾಯಿಸಿ ಮತ್ತು ಮೊದಲ ವೈಫಲ್ಯದಲ್ಲಿ ನಿಲ್ಲಿಸಿ, ಏಕೆಂದರೆ ಪ್ರತಿ ಹಂತ ಬೇರೆ ಪದರವನ್ನು ಹೊರಗಿಡುತ್ತದೆ. ಕೆಳಗಿನ TLS ಪ್ರೋಬ್ ಪ್ರಮಾಣಪತ್ರದ ಗುರುತನ್ನು SSTP ಮಾಡುವ ಎಲ್ಲದರಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ. ಹೋಸ್ಟ್‌ಹೆಸರನ್ನು ನಿಮ್ಮ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ನೊಂದಿಗೆ ಬದಲಿಸಿ ಮತ್ತು ಅದು ಮುದ್ರಿಸುವ subject ಮತ್ತು ಸರಪಳಿಯನ್ನು ಓದಿ.
openssl s_client -connect vpn.example.com:443 -servername vpn.example.comನಂತರ ಕ್ಲೈಂಟ್ ದೋಷದಿಂದ ಊಹಿಸುವ ಬದಲು ಉಳಿದ ಸಾಕ್ಷ್ಯವನ್ನು ಹಂತಗಳಿಗೆ ಹೊಂದಿಸಿ. ಕೆಳಗಿನ ಕೋಷ್ಟಕ ಟಿಕೆಟ್‌ನಲ್ಲಿ ಉಲ್ಲೇಖಿಸಲು ಚೆಕ್‌ಲಿಸ್ಟ್, ಒಂದು ವೈಫಲ್ಯವನ್ನು ಮುಂದಿನದರಿಂದ ಬೇರ್ಪಡಿಸುವ ಸಹಿಯೊಂದಿಗೆ.
| Stage | What it proves | Failure signature |
|---|---|---|
| TCP to 443 | A listener exists and the path is open | Timeout or connection refused |
| TLS with SNI | The certificate matches the name you use | Name mismatch or untrusted chain |
| SSTP_DUPLEX_POST exchange | The endpoint is an SSTP server | 405, 404, 301 or an early FIN |
| PPP authentication | The user credential was accepted | Auth failure after a 200 response |
| Inner routing | A permitted destination is reachable | Tunnel up, no reply from the target |
ಟಿಕೆಟ್‌ನಲ್ಲಿ "ಸಂಪರ್ಕಿಸಲಾಗದು" ಎಂದು ಬರೆಯುವ ಬದಲು ಕೊನೆಯ ಯಶಸ್ವಿ ಹಂತವನ್ನು ದಾಖಲಿಸಿ. MS-SSTP ವಿಶೇಷಣ TLS ಹ್ಯಾಂಡ್‌ಶೇಕ್ ನಂತರ ಬರುವ ವಿನಂತಿ ಮತ್ತು PPP ವಿನಿಮಯವನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ಮತ್ತು ಬ್ರೌಸರ್ ಪರೀಕ್ಷೆ ಅವುಗಳಲ್ಲಿ ಯಾವುದನ್ನೂ ಬದಲಿಸಲಾಗದ ಕಾರಣದ ಉಲ್ಲೇಖ ಅದು.
ಮೊದಲು ಗುರುತು, ನಂತರ PPP
TLS ಗುರುತು ಮತ್ತು PPP ದೃಢೀಕರಣ ಅನುಕ್ರಮವಾದವು, ಪರ್ಯಾಯವಲ್ಲ, ಮತ್ತು ಅವುಗಳನ್ನು ಗೊಂದಲ ಮಾಡುವುದು ಜನರನ್ನು ತಪ್ಪು ಸರ್ವರ್ ಸೆಟ್ಟಿಂಗ್‌ಗೆ ಕಳುಹಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಮೊದಲು ಸರ್ವರ್ ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ಅದರ ಉದ್ದೇಶಿತ ಉದ್ದೇಶವನ್ನು ಮೌಲ್ಯೀಕರಿಸಿ, ನಂತರ PPP ತನ್ನ ಸ್ಥಿತಿಯನ್ನು ಸಮಾಲೋಚಿಸಿ ಬಳಕೆದಾರರನ್ನು ಸವಾಲು-ಪ್ರತಿಕ್ರಿಯೆ ವಿಧಾನ ಅಥವಾ EAP ನೊಂದಿಗೆ ದೃಢೀಕರಿಸುತ್ತದೆ. ಪ್ರಮಾಣಪತ್ರ ಸಮಸ್ಯೆ ನಿರಾಕರಿಸಿದ ಪಾಸ್‌ವರ್ಡ್‌ಗಿಂತ ಬೇರೆ ದೋಷ ನೀಡುತ್ತದೆ, ಮತ್ತು ಯಾವುದೇ ದೋಷವು ಇನ್ನೊಂದು ಒಳಗೊಳ್ಳುವ ಹಂತವನ್ನು ವಿವರಿಸುವುದಿಲ್ಲ.
ಹೋಸ್ಟ್‌ಹೆಸರನ್ನು ವಿಳಾಸದೊಂದಿಗೆ ಬದಲಿಸುವುದು, ಅಥವಾ ಪ್ರಮಾಣಪತ್ರ ಎಚ್ಚರಿಕೆಯನ್ನು ದಾಟಿ ಕ್ಲಿಕ್ ಮಾಡುವುದು, ವಿಫಲವಾಗುತ್ತಿರುವ ಹಂತವನ್ನು ಗುರುತಿಸುತ್ತಿದ್ದ ಪರಿಶೀಲನೆಯನ್ನು ಸರಿಪಡಿಸುವ ಬದಲು ತೆಗೆದುಹಾಕುತ್ತದೆ. ಎಚ್ಚರಿಕೆಯನ್ನು ಇಟ್ಟುಕೊಂಡು ಓದಿ. HTTP ವಿನಿಮಯ ಎಂದಿಗೂ SSTP ವರ್ತನೆಯನ್ನು ತಲುಪದಿದ್ದಾಗ PPP ಪಾಸ್‌ವರ್ಡ್ ಮರುಹೊಂದಿಸಬೇಡಿ, ಏಕೆಂದರೆ ರುಜುವಾತು ಎಂದಿಗೂ ಕೇಳಲಾಗಿಲ್ಲ.