ਜਿੱਥੇ ਬ੍ਰਾਊਜ਼ਰ ਦਾ 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 ਜੋ ਵੀ ਕਰਦਾ ਹੈ ਉਸ ਤੋਂ ਵੱਖ ਕਰਦੀ ਹੈ। ਹੋਸਟਨਾਮ ਨੂੰ ਆਪਣੇ ਐਂਡਪੌਇੰਟ ਨਾਲ ਬਦਲੋ ਅਤੇ ਇਹ ਜੋ ਸਬਜੈਕਟ ਅਤੇ ਲੜੀ ਛਾਪਦੀ ਹੈ ਉਹ ਪੜ੍ਹੋ।
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 ਪਾਸਵਰਡ ਰੀਸੈਟ ਨਾ ਕਰੋ, ਕਿਉਂਕਿ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਕਦੇ ਨਹੀਂ ਮੰਗੇ ਗਏ।