SSTP ਨੇ ਪੋਰਟ 443 ਲੈ ਲਿਆ: Apache ਕਿਉਂ ਸ਼ੁਰੂ ਨਹੀਂ ਹੁੰਦਾ

ਜਿਸ ਦੁਪਹਿਰ ਕੋਈ ਆ ਰਹੇ VPN ਕਨੈਕਸ਼ਨ ਚਾਲੂ ਕਰਦਾ ਹੈ, ਉਸ ਦੁਪਹਿਰ Apache 443 ’ਤੇ ਜਵਾਬ ਦੇਣਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇਸਦਾ ਗਲਤੀ ਲਾਗ ਪਿੱਛੇ ਦੀ ਰਾਖਵੀਂ ਕੀਮਤ ਦੀ ਥਾਂ bind ਨੂੰ ਦੋਸ਼ ਦਿੰਦਾ ਹੈ। Windows Routing and Remote Access ਉਸੇ ਪਲ SSTP ਚਾਲੂ ਕਰਦਾ ਹੈ, ਅਤੇ SSTP ਲਿਸਨਰ ਕਿਸੇ ਵੀ ਕਲਾਇੰਟ ਦੇ ਪ੍ਰਮਾਣਿਤ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ HTTP ਸਟੈਕ ਰਾਹੀਂ TCP 443 ਦਾ ਦਾਅਵਾ ਕਰਦਾ ਹੈ। ਇਹ ਦਾਅਵਾ ਉਦੋਂ ਵੀ ਲਾਗੂ ਰਹਿੰਦਾ ਹੈ ਜਦੋਂ ਪ੍ਰਮਾਣ ਪੱਤਰ ਨਹੀਂ ਹੁੰਦਾ, ਨਾਮ ਗਲਤ ਹੁੰਦਾ ਹੈ ਜਾਂ ਹਰ handshake ਰੱਦ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਜਿਸ VPN ਵਿੱਚ ਕੋਈ ਲਾਗਇਨ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਉਹ ਵੀ ਪੋਰਟ ’ਤੇ ਹੀ ਰਹਿੰਦਾ ਹੈ। ਪਹਿਲਾਂ ਸੁਣਨ ਵਾਲੀ ਸਾਰਣੀ ਪੜ੍ਹੋ; 443 ਰੱਖਣ ਵਾਲਾ PID ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਹੇਠਾਂ ਦਿੱਤੇ ਉਪਾਵਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਤੁਹਾਡੇ ਲਈ ਖੁੱਲ੍ਹਾ ਹੈ।

ਰਾਖਵਾਂ ਕਰਨਾ ਟੁੱਟੇ ਪ੍ਰਮਾਣ ਪੱਤਰ ਤੋਂ ਵੱਧ ਚਿਰ ਰਹਿੰਦਾ ਹੈ

SSTP PPP ਨੂੰ TLS ਸੈਸ਼ਨ ਦੇ ਅੰਦਰ ਲਪੇਟਦਾ ਹੈ, ਇਸੇ ਲਈ ਇਸ ਨੂੰ 443 ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਇਸੇ ਲਈ ਇਹ ਦੂਜੀਆਂ ਸੁਰੰਗਾਂ ਛੱਡਣ ਵਾਲੀਆਂ ਪ੍ਰਾਕਸੀ ਰਾਹੀਂ ਲੰਘਦਾ ਹੈ। ਲਿਸਨਰ ਉਹ socket ਨਹੀਂ ਜੋ VPN ਸੇਵਾ ਆਪਣੇ ਲਈ ਖੋਲ੍ਹਦੀ ਹੈ: SstpSvc ਇਸਨੂੰ ਕਰਨਲ HTTP ਡਰਾਈਵਰ ਕੋਲ ਰਜਿਸਟਰ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਸੇਵਾ ਚੱਲਣ ਤੱਕ ਪੋਰਟ ਰਾਖਵਾਂ ਰਹਿੰਦਾ ਹੈ। ਉਹ ਰਜਿਸਟਰੇਸ਼ਨ ਕਦੇ ਪ੍ਰਮਾਣ ਪੱਤਰ ਨੂੰ ਨਹੀਂ ਪੁੱਛਦੀ, ਭਾਵ ਮਿਆਦ ਪੁੱਗਿਆ ਨਾਮ, ਨਾ ਮਿਲਦਾ subject ਜਾਂ ਪ੍ਰਮਾਣ ਪੱਤਰ ਬਿਲਕੁਲ ਨਾ ਹੋਣਾ 443 ਨੂੰ ਕਬਜ਼ੇ ਵਿੱਚ ਹੀ ਰੱਖਦਾ ਹੈ। ਫਿਰ ਫੇਲ੍ਹਤਾਂ ਦੋ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਵੰਡੀਆਂ ਜਾਂਦੀਆਂ ਹਨ: ਰੱਦ ਕੀਤੇ handshake RasSstp ਹੇਠ System ਲਾਗ ਵਿੱਚ ਜਾਂਦੇ ਹਨ, ਜਦੋਂ ਕਿ ਵੈੱਬ ਸਰਵਰ ਸਿਰਫ਼ ਇਹ ਦੱਸ ਸਕਦਾ ਹੈ ਕਿ ਉਹ bind ਨਹੀਂ ਕਰ ਸਕਿਆ।

netstat -aon | findstr :443
tasklist /svc /fi "PID eq <pid>"

ਪਹਿਲੀ ਲਾਈਨ ਮਾਲਕ PID ਵਾਪਸ ਕਰਦੀ ਹੈ; ਦੂਜੀ ਉਸਦੇ ਪਿੱਛੇ ਦੀ ਸੇਵਾ ਦਾ ਨਾਮ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਜਵਾਬ ਆਮ ਤੌਰ ’ਤੇ HTTP ਸੇਵਾ ਜਾਂ RRAS ਸਟੈਕ ਹੁੰਦਾ ਹੈ। ਜਦੋਂ tasklist ਸਾਂਝੀ ਹੋਸਟ ਪਰੋਸੈਸ ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਪਰੋਸੈਸ ਦੇ ਨਾਮ ਤੋਂ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਸੇਵਾ ਕਾਲਮ ਪੜ੍ਹੋ।

RasSstp ਚੇਤਾਵਨੀਆਂ ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ ਪੜ੍ਹਨ ਯੋਗ ਹਨ, ਕਿਉਂਕਿ ਉਹ ਫੇਲ੍ਹ ਹੋਏ handshake ਦਾ ਵਰਣਨ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਟਕਰਾਅ ਪੈਦਾ ਕਰਨ ਵਾਲੀ ਰਾਖਵੀਂ ਕੀਮਤ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀਆਂ। ਹਰ ਕਲਾਇੰਟ ਨੂੰ ਰੱਦ ਕਰਨ ਵਾਲਾ VPN ਟਰਮਿਨਲ ਵੀ ਪੋਰਟ ਰੱਖਦਾ ਹੈ। ਲਾਗ ਨੂੰ ਪਹਿਲਾ ਨਹੀਂ, ਦੂਜਾ ਸਵਾਲ ਮੰਨੋ।

IIS ਡਰਾਈਵਰ ਸਾਂਝਾ ਕਰਦਾ ਹੈ, Apache socket ਖੋਲ੍ਹਦਾ ਹੈ

IIS ਆਪਣੇ bindings ਉਸੇ ਕਰਨਲ ਡਰਾਈਵਰ ਨੂੰ ਦਿੰਦਾ ਹੈ ਜੋ SSTP ਵਰਤਦਾ ਹੈ, ਅਤੇ ਉਹ ਡਰਾਈਵਰ ਆ ਰਹੇ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਹੋਸਟ ਨਾਮ ਅਤੇ URL ਅਗੇਤਰ ਅਨੁਸਾਰ ਵੱਖ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਦੋਵੇਂ ਸੇਵਾਵਾਂ ਨੂੰ 443 ਚਾਹੀਦਾ ਹੈ ਇਹ ਕਿਹਾ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਕੋਈ ਵੀ ਫੇਲ੍ਹ ਨਹੀਂ ਹੁੰਦੀ। Apache ਅਤੇ nginx ਉਲਟਾ ਕਰਦੇ ਹਨ: ਉਹ ਆਪਣੇ socket ’ਤੇ bind ਕਾਲ ਕਰਦੇ ਹਨ, ਅਤੇ ਪਤਾ ਪਹਿਲਾਂ ਹੀ ਕਬਜ਼ੇ ਵਿੱਚ ਹੋਣ ਕਰਕੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਮਨ੍ਹਾ ਕਰ ਦਿੰਦਾ ਹੈ। ਦੋਵਾਂ ਸੰਰਚਨਾਵਾਂ ਵਿੱਚ ਕੁਝ ਵੀ ਗਲਤ ਨਹੀਂ; ਫਰਕ ਕਿਹੜੀ API ਪੋਰਟ ਰੱਖਦੀ ਹੈ ਵਿੱਚ ਹੈ। ਇਸੇ ਲਈ VPN ਚਾਲੂ ਕਰਨ ਨਾਲ ਇੱਕ ਹੋਸਟ ਦੀ ਇੱਕ ਸਾਈਟ ਡਿੱਗਦੀ ਹੈ ਅਤੇ ਦੂਜੇ ਹੋਸਟ ਦੀ ਉਹੀ ਸਾਈਟ ਅਛੂਤ ਰਹਿੰਦੀ ਹੈ।

ਇਹ ਅਸਮਾਨਤਾ ਮੁਰੰਮਤ ਦਾ ਰੂਪ ਤੈਅ ਕਰਦੀ ਹੈ। ਜੇ IIS ਪਹਿਲਾਂ ਹੀ ਅੱਗੇ ਦਾ ਦਰਵਾਜ਼ਾ ਹੈ, ਟਕਰਾਅ ਅਗੇਤਰਾਂ, bindings ਅਤੇ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਦਾ ਸਵਾਲ ਬਣ ਜਾਂਦਾ ਹੈ। ਜੇ Apache ਅੱਗੇ ਦਾ ਦਰਵਾਜ਼ਾ ਹੈ, ਤਾਂ ਜਾਂ ਤਾਂ ਉਹ 443 ਤੋਂ ਹਟਦਾ ਹੈ ਜਾਂ SSTP ਲਿਸਨਰ ਹਟਦਾ ਹੈ, ਅਤੇ ਅਗਲਾ ਭਾਗ ਦੋਵੇਂ ਕਦਮ ਕਵਰ ਕਰਦਾ ਹੈ।

ਚੁਣੋ ਕਿ ਕਿਹੜੀ ਸੇਵਾ 443 ਰੱਖੇਗੀ

ਲਿਸਨਰ ਦਾ ਪੋਰਟ ਇੱਕ ਹੀ ਰਜਿਸਟਰੀ ਮੁੱਲ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, Sstpsvc ਪੈਰਾਮੀਟਰ ਕੁੰਜੀ ਹੇਠ ਦਸ਼ਮਲਵ DWORD। ਮੁੱਲ ਬਦਲੋ, Routing and Remote Access ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰੋ, ਅਤੇ ਸੁਣਨ ਵਾਲੀ ਸਾਰਣੀ ਤੋਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਪੁਰਾਣਾ ਪੋਰਟ ਖਾਲੀ ਹੈ।

reg query "HKLM\SYSTEM\CurrentControlSet\Services\Sstpsvc\Parameters" /v ListenerPort
reg add "HKLM\SYSTEM\CurrentControlSet\Services\Sstpsvc\Parameters" /v ListenerPort /t REG_DWORD /d 4443 /f
Restart-Service RemoteAccess

ਅਜਿਹਾ ਪੋਰਟ ਚੁਣੋ ਜੋ ਹੋਸਟ ’ਤੇ ਕਿਸੇ ਹੋਰ ਨੂੰ ਨਹੀਂ ਚਾਹੀਦਾ, ਅਤੇ ਇਸਨੂੰ ਦਸ਼ਮਲਵ ਵਿੱਚ ਲਿਖੋ: reg add DWORD ਨੂੰ ਲਿਖੇ ਅਨੁਸਾਰ ਹੀ ਸੰਭਾਲਦਾ ਹੈ, ਇਸ ਲਈ ਹੈਕਸਾਡੈਸਿਮਲ ਸਮਝਿਆ ਮੁੱਲ ਕਿਸੇ ਹੋਰ ਪੋਰਟ ਵਜੋਂ ਉਤਰਦਾ ਹੈ। ਜੇ ਕਿਊਰੀ ਕਹੇ ਕਿ ਮੁੱਲ ਮੌਜੂਦ ਨਹੀਂ, ਤਾਂ ਦੂਜੀ ਲਾਈਨ ਉਸਨੂੰ ਬਣਾਉਂਦੀ ਹੈ। Restart-Service RemoteAccess ਜੁੜੇ ਹੋਏ ਸਾਰਿਆਂ ਨੂੰ ਕੱਢ ਦਿੰਦਾ ਹੈ, ਜਿਸਨੂੰ ਯੋਜਨਾ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ। ਫਿਰ ਸੁਣਨ ਵਾਲੀ ਜਾਂਚ ਦੁਬਾਰਾ ਚਲਾਓ, ਕਿਉਂਕਿ 443 ’ਤੇ ਪੁਰਾਣੀ ਐਂਟਰੀ ਦਾ ਅਰਥ ਹੈ ਸੇਵਾ ਨੇ ਆਪਣੀ ਪੁਰਾਣੀ ਰਜਿਸਟਰੇਸ਼ਨ ਰੱਖੀ ਹੈ।

ਲਿਸਨਰ ਹਟਾਉਣ ਦੀ ਕੀਮਤ ਰਜਿਸਟਰੀ ਸੋਧ ਨਹੀਂ ਦਿਖਾਉਂਦੀ। ਆਮ SSTP ਕਲਾਇੰਟ 443 ’ਤੇ ਕਾਲ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਹਰ ਕਲਾਇੰਟ ਪਰੋਫਾਈਲ ਨੂੰ ਨਵਾਂ ਪੋਰਟ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਰਾਹ ਦੀ ਜਾਂਚ ਕਰਨ ਵਾਲੇ ਕਿਸੇ ਨੂੰ ਵੀ ਪ੍ਰਵਾਹ ਵੈੱਬ ਬੇਨਤੀ ਵਰਗਾ ਨਹੀਂ ਲੱਗਦਾ। HTTPS ਵਰਗਾ ਟ੍ਰੈਫਿਕ ਸਿਰਫ਼ ਸਹਿਣ ਵਾਲੇ ਨੈੱਟਵਰਕ ’ਤੇ ਇਹ SSTP ਚੁਣਨ ਦਾ ਬਹੁਤਾ ਕਾਰਨ ਹਟਾ ਦਿੰਦਾ ਹੈ। ਛੋਟੀ, ਪ੍ਰਬੰਧਿਤ ਕਲਾਇੰਟ ਅਬਾਦੀ ਇਸਨੂੰ ਪਚਾ ਲੈਂਦੀ ਹੈ; ਜਨਤਕ ਜਾਂ BYOD ਵਰਤੋਂਕਾਰ ਅਧਾਰ ਨਹੀਂ।

ਦੂਜਾ ਕਦਮ 443 IIS ਕੋਲ ਰੱਖਦਾ ਹੈ ਅਤੇ Apache ਨੂੰ ਪ੍ਰਾਕਸੀ ਅੱਗੇ ਭੇਜਣ ਵਾਲਾ backend ਮੰਨਦਾ ਹੈ। ਇਹ SSTP ਦਾ ਡਿਫਾਲਟ ਬਚਾਉਂਦਾ ਹੈ ਅਤੇ ਪੋਰਟ ਲਈ ਇੱਕ ਮਾਲਕ ਛੱਡਦਾ ਹੈ, ਪਰ ਅੱਗੇ ਭੇਜੇ ਹੈਡਰ, ਐਪਲੀਕੇਸ਼ਨ ਵੱਲੋਂ ਹੁਣ ਸਿੱਧਾ ਨਾ ਦਿਖਣ ਵਾਲਾ ਕਲਾਇੰਟ ਪਤਾ ਅਤੇ ਪ੍ਰਾਕਸੀ ਵਾਸਤਵ ਵਿੱਚ ਭੇਜਦਾ ਪ੍ਰੋਟੋਕਾਲ ਬੋਲਣਾ ਪੈਣ ਵਾਲਾ backend ਦੀ ਕੀਮਤ ’ਤੇ।

ਮਾਲਕ, ਪ੍ਰਮਾਣ ਪੱਤਰ ਅਤੇ handshake ਨੂੰ ਕ੍ਰਮ ਵਿੱਚ ਸਾਬਤ ਕਰੋ

ਪੂਰਾ ਹੋਇਆ TCP ਕਨੈਕਸ਼ਨ ਸਿਰਫ਼ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਲਿਸਨਰ ਹੈ, ਹੋਰ ਕੁਝ ਨਹੀਂ, ਇਸ ਲਈ ਸੁਰੰਗ ਅਜੇ ਵੀ ਫੇਲ੍ਹ ਹੁੰਦਿਆਂ ਪੋਰਟ ਸਕੈਨ ਸਿਹਤਮੰਦ ਲੱਗ ਸਕਦਾ ਹੈ। ਚਾਰ ਪੜਾਅ ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਨਾਲ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਜਿਸ ਪੜਾਅ ਨੂੰ ਤੁਸੀਂ ਨਹੀਂ ਤੋੜਿਆ ਉਸ ’ਤੇ ਕੇਂਦ੍ਰਿਤ ਮੁਰੰਮਤ ਆਮ ਤੌਰ ’ਤੇ ਟਕਰਾਅ ਨੂੰ ਡੂੰਘਾ ਕਰਦੀ ਹੈ। ਉਹਨਾਂ ਨੂੰ ਕ੍ਰਮ ਨਾਲ ਕਰੋ ਅਤੇ ਜਿੱਥੇ ਜਵਾਬ ਵੱਖ ਹੁੰਦਾ ਹੈ ਉੱਥੇ ਰੁਕੋ।

netstat -aon | findstr :443
certutil -store My
Get-WinEvent -LogName System -ProviderName RasSstp -MaxEvents 20

ਪਹਿਲੀ ਲਾਈਨ 443 ਰੱਖਣ ਵਾਲੇ PID ਦਾ ਨਾਮ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਉਹ ਤੁਹਾਡੇ ਵੱਲੋਂ ਹੁਣੇ ਸੰਰਚਿਤ ਕੀਤੀ ਸੇਵਾ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਦੂਜੀ ਮਸ਼ੀਨ ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਨੂੰ ਉਹਨਾਂ ਦੇ subjects ਨਾਲ ਸੂਚੀਬੱਧ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਕਲਾਇੰਟ ਪਰੋਫਾਈਲ ਦੇ ਪਤੇ ਨਾਲ ਨਾ ਮਿਲਦਾ ਨਾਮ ਤੁਰੰਤ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ। ਘਟਨਾ ਕਿਊਰੀ ਹਾਲੀਆ SSTP ਰਿਕਾਰਡ ਵਾਪਸ ਕਰਦੀ ਹੈ, ਅਤੇ PPP ਪ੍ਰਮਾਣੀਕਰਨ ਤੱਕ ਕਦੇ ਨਾ ਪਹੁੰਚਣ ਵਾਲਾ handshake ਪ੍ਰਮਾਣਿਤ ਹੋ ਕੇ ਫਿਰ ਰੱਦ ਹੋਏ ਨਾਲੋਂ ਵੱਖਰਾ ਰਿਕਾਰਡ ਛੱਡਦਾ ਹੈ। ਆਖਰੀ ਪੜਾਅ ਸਿਰਫ਼ ਕਲਾਇੰਟ ’ਤੇ ਦਿਸਦਾ ਹੈ, ਜਿੱਥੇ ਐਂਟਰੀ ਜਾਂ ਤਾਂ ਜੁੜਿਆ ਦੱਸਦੀ ਹੈ ਜਾਂ PPP ਗਲਤੀ ਦਾ ਨਾਮ ਲੈਂਦੀ ਹੈ।

ਜਦੋਂ ਇੱਕ ਹੀ ਹੋਸਟ ਨੂੰ ਦੋਵੇਂ ਕੰਮ ਕਰਨੇ ਪੈਣ, ਤਾਂ 443 ਦਾ ਮਾਲਕ ਜਾਣ-ਬੁੱਝ ਕੇ ਚੁਣੋ ਅਤੇ ਚੋਣ ਲਿਖ ਰੱਖੋ, ਕਿਉਂਕਿ ਨਹੀਂ ਤਾਂ ਕੋਈ ਸੁਵਿਧਾ ਚਾਲੂ ਕਰਨ ਵਾਲਾ ਅਗਲਾ ਵਿਅਕਤੀ ਇਹ ਟਕਰਾਅ ਦੁਬਾਰਾ ਲੱਭੇਗਾ। ਭੂਮਿਕਾਵਾਂ ਨੂੰ ਵੱਖ ਰੱਖਣਾ ਹੀ ਸਭ ਤੋਂ ਸਾਫ਼ ਜਵਾਬ ਹੈ: ਜਨਤਕ ਵੈੱਬ ਸਰਵਰ ਅਤੇ ਦੂਰਸਥ ਪਹੁੰਚ ਟਰਮਿਨਲ ਦੇ ਪੈਚ, ਪ੍ਰਮਾਣ ਪੱਤਰ ਅਤੇ ਮੁੜ-ਸ਼ੁਰੂਆਤ ਦੇ ਚੱਕਰ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਉਹ ਚੱਕਰ ਆਪਣੇ ਹੀ ਸਮਾਂ-ਸਾਰਣੀ ਅਨੁਸਾਰ ਮਿਲਦੇ ਹਨ। ਕਿਸੇ ਵੀ ਹਾਲਤ ਵਿੱਚ, ਸੁਣਨ ਵਾਲੀ ਜਾਂਚ, ਰਜਿਸਟਰੀ ਮਾਰਗ ਅਤੇ ਚੁਣਿਆ ਪੋਰਟ ਹੈਂਡਓਵਰ ਨੋਟ ਵਿੱਚ ਛੱਡੋ।