SMB ਸਾਂਝੇਦਾਰੀ ਸਿਰਫ਼ VPN ਰਾਹੀਂ ਅਸਫਲ ਹੁੰਦੀ ਹੈ: ਦਸਤਖ਼ਤ ਜਾਂ ਸਬਨੈੱਟ ਟਕਰਾਅ?
LAN ਉੱਤੇ ਚੱਲਣ ਵਾਲੀ ਸਾਂਝੇਦਾਰੀ ਸਿਰਫ਼ ਟਨਲ ਰਾਹੀਂ ਅਸਫਲ ਹੋ ਸਕਦੀ ਹੈ। ਦਸਤਖ਼ਤ ਦੀ ਅਸਵੀਕਾਰਤਾ, ਓਵਰਲੈਪ ਹੁੰਦਾ ਸਬਨੈੱਟ ਅਤੇ ਪੁਰਾਣਾ SMB ਸੈਸ਼ਨ ਵੱਖ ਕਰੋ।
ਦਫ਼ਤਰ ਵਿੱਚ ਚੱਲਣ ਵਾਲੀ ਅਤੇ ਘਰ ਵਿੱਚ ਟਾਈਮ ਆਊਟ ਹੋਣ ਵਾਲੀ ਮੈਪ ਕੀਤੀ ਡਰਾਈਵ ਆਪਣੇ ਆਪ ਵਿੱਚ ਲਗਭਗ ਕੋਈ ਲਾਹੇਵੰਦ ਜਾਣਕਾਰੀ ਨਹੀਂ ਦਿੰਦੀ। ਟਨਲ ਸਪਸ਼ਟ ਤੌਰ ’ਤੇ ਪੈਕੇਟ ਲੈ ਕੇ ਜਾ ਰਿਹਾ ਹੈ, ਵਰਨਾ ਸਰਵਰ ਤੱਕ ਕੁਝ ਨਾ ਪਹੁੰਚਦਾ। ਜੋ ਅਸਫਲ ਹੋਇਆ ਉਹ ਤਿੰਨ ਪਰਤਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ: ਨਾਮ ਗਲਤ ਪਤੇ ’ਤੇ ਹੱਲ ਹੋਇਆ, ਕਲਾਇੰਟ ਨੇ ਸੈਸ਼ਨ ’ਤੇ ਦਸਤਖ਼ਤ ਕਰਨ ਤੋਂ ਇਨਕਾਰ ਕੀਤਾ, ਜਾਂ ਪੁਰਾਣਾ ਸੈਸ਼ਨ ਉਸ ਕਨੈਕਸ਼ਨ ਤੋਂ ਵੱਧ ਜੀਵਿਆ ਜੋ ਇਸਨੂੰ ਚੁੱਕ ਰਿਹਾ ਸੀ। ਹਰ ਇੱਕ ਦੀ ਮੁਰੰਮਤ ਵੱਖਰੀ ਹੈ, ਅਤੇ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਦੋ ਕਲਾਇੰਟ ਵੱਲ ਹਨ।
ਤਿੰਨ ਖਰਾਬੀਆਂ ਇੱਕੋ ਗਲਤੀ ਪਹਿਨਦੀਆਂ ਹਨ
ਡਰਾਈਵ ਅੱਖਰ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਕਿਹੜੀ ਪਰਤ ਟੁੱਟੀ, ਅਤੇ ਗਲਤੀ ਦਾ ਪਾਠ ਆਮ ਤੌਰ ’ਤੇ ਤਿੰਨਾਂ ’ਤੇ ਲਾਗੂ ਹੋਣ ਲਾਇਕ ਆਮ ਹੁੰਦਾ ਹੈ। ਉਨ੍ਹਾਂ ਨੂੰ ਦੋ ਤੇਜ਼ ਸਵਾਲਾਂ ਨਾਲ ਵੱਖ ਕਰੋ: ਕੀ ਸਰਵਰ ਆਪਣੇ IP ਪਤੇ ’ਤੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਕੀ ਪੋਰਟ 445 ਕਨੈਕਸ਼ਨ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ?
ਇਹ ਜਵਾਬ ਅੰਦਾਜ਼ੇ ਦੀ ਥਾਂ ਫੈਸਲੇ ਦੀ ਸਾਰਣੀ ਬਣਾਉਂਦੇ ਹਨ। ਜੇ IP ਚੱਲਦਾ ਹੈ ਅਤੇ ਨਾਮ ਨਹੀਂ, ਤਾਂ ਇਹ ਨਾਮ ਹੱਲ ਵੱਲ ਇਸ਼ਾਰਾ ਹੈ। ਜੇ ਦੋਵੇਂ ਚੱਲਦੇ ਹਨ ਅਤੇ ਲੌਗਇਨ ਅਸਵੀਕਾਰ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇਹ ਦਸਤਖ਼ਤ ਵੱਲ ਇਸ਼ਾਰਾ ਹੈ। ਜੇ ਦੋਵੇਂ ਚੱਲਦੇ ਹਨ ਅਤੇ ਟਨਲ ਰੁਕਾਵਟ ਤੋਂ ਬਾਅਦ ਫਾਈਲ ਪੜ੍ਹਨਾ ਅਟਕ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਪੁਰਾਣੇ ਸੈਸ਼ਨ ਵੱਲ ਇਸ਼ਾਰਾ ਹੈ।
| Symptom | Layer to inspect |
|---|---|
| IP works, hostname times out | DNS or subnet overlap |
| TCP 445 opens, logon refused | SMB signing policy |
| Hangs after reconnect | Session state and timers |
ਉਨ੍ਹਾਂ ਨੂੰ ਉਸੇ ਕ੍ਰਮ ਵਿੱਚ ਨਿਬੇੜੋ, ਕਿਉਂਕਿ ਗਲਤ ਹੋਸਟ ’ਤੇ ਹੱਲ ਹੋਣ ਵਾਲਾ ਨਾਮ ਹਰ ਅਗਲੇ ਟੈਸਟ ਨੂੰ ਅਰਥਹੀਣ ਕਰ ਦਿੰਦਾ ਹੈ।
ਸਾਂਝੇਦਾਰੀ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਨਾਮ ਹੱਲ ਕਰੋ
ਜੇ ਸਰਵਰ ਆਪਣੇ ਪਤੇ ’ਤੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਅਤੇ ਸਾਂਝੇਦਾਰੀ ਦਾ ਨਾਮ ਟਾਈਮ ਆਊਟ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਟਨਲ ਆਪਣਾ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਗਲਤ ਥਾਂ ਵੇਖ ਰਿਹਾ ਹੈ। ਦੂਰੋਂ ਪਹੁੰਚ ਵਿੱਚ ਇਸਦਾ ਵੱਡਾ ਹਿੱਸਾ ਦੋ ਕਾਰਨ ਸਮਝਾਉਂਦੇ ਹਨ।
ਪਹਿਲਾ ਪਤਿਆਂ ਦਾ ਓਵਰਲੈਪ ਹੈ। ਜਦੋਂ ਦਫ਼ਤਰ 192.168.70.0/24 ਵਰਤਦਾ ਹੈ ਅਤੇ ਘਰ ਦਾ ਰਾਊਟਰ ਉਹੀ ਰੇਂਜ ਵੰਡਦਾ ਹੈ, ਤਾਂ 192.168.70.20 ’ਤੇ ਹੱਲ ਹੋਣ ਵਾਲਾ ਹੋਸਟ ਨਾਮ ਟਨਲ ਪਿੱਛੇ ਦੇ ਸਰਵਰ ਦੀ ਥਾਂ ਸਥਾਨਕ ਡਿਵਾਈਸ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰ ਸਕਦਾ ਹੈ। Windows ਫਿਰ ਬੇਨਤੀ ਸਥਾਨਕ ਤੌਰ ’ਤੇ ਭੇਜ ਸਕਦਾ ਹੈ, ਰੂਟ ਅਸਵੀਕਾਰ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ ਅਜਿਹੇ ਪ੍ਰਿੰਟਰ ’ਤੇ ਹੱਲ ਕਰ ਸਕਦਾ ਹੈ ਜਿਸ ਕੋਲ ਸੰਜੋਗ ਨਾਲ ਉਹ ਪਤਾ ਹੋਵੇ। ਮੁਰੰਮਤ ਇੱਕ ਪਾਸਾ ਦੁਬਾਰਾ ਨੰਬਰ ਦੇਣਾ ਹੈ, ਨਾ ਕਿ ਇੱਕ ਹੋਰ ਰੂਟ ਜੋੜਨਾ।
ਦੂਜਾ DNS ਦਾਇਰਾ ਹੈ। ਅੰਦਰੂਨੀ DNS ਸਰਵਰ ਤੋਂ ਬਿਨਾਂ, ਜਾਂ ਟਨਲ ਰਾਹੀਂ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਸਰਵਰ ਵਾਲਾ VPN ਅਡੈਪਟਰ ਛੋਟੇ ਨਾਮਾਂ ਨੂੰ ਜਨਤਕ ਰਿਜ਼ੌਲਵਰ ਵੱਲ ਜਾਣ ਦਿੰਦਾ ਹੈ। ਅਡੈਪਟਰ ਦੀਆਂ DNS ਐਂਟਰੀਆਂ ਪੜ੍ਹੋ ਅਤੇ ਸਾਂਝੇਦਾਰੀ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਅੰਦਰੂਨੀ ਨਾਮ ਸਿੱਧਾ ਪੁੱਛੋ:
> ipconfig /all | findstr /i "DNS Servers"
> nslookup files.corp.internal
Server: 10.90.0.2
Address: 10.90.0.2
Name: files.corp.internal
Address: 10.90.0.15ਜੇ ਉਹ ਪੁੱਛਗਿੱਛ ਉਮੀਦਵਾਰ ਪਤਾ ਵਾਪਸ ਕਰਦੀ ਹੈ, ਤਾਂ ਨਾਮ ਹੱਲ ਤੈਅ ਹੈ ਅਤੇ ਸਮੱਸਿਆ ਸਟੈਕ ਵਿੱਚ ਉੱਪਰ ਹੈ।
ਦੋਵੇਂ ਸਿਰਿਆਂ ’ਤੇ ਦਸਤਖ਼ਤ ਦੀ ਲੋੜ ਪੜ੍ਹੋ
ਪਹੁੰਚਯੋਗ ਸਰਵਰ ਜੋ ਹਰ ਲੌਗਇਨ ਅਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਨੈੱਟਵਰਕ ਖਰਾਬੀ ਨਹੀਂ ਬਲਕਿ ਨੀਤੀ ਬੇਮੇਲ ਦਾ ਸੰਕੇਤ ਹੈ। Windows ਕਲਾਇੰਟ ’ਤੇ SMB ਦਸਤਖ਼ਤ ਲਾਜ਼ਮੀ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਦਸਤਖ਼ਤ ਨਾ ਕਰਨ ਵਾਲਾ ਸਰਵਰ ਜਾਂ NAS ਸੈਸ਼ਨ ਪੂਰਾ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਟਨਲ ਕਿੰਨਾ ਵੀ ਸਿਹਤਮੰਦ ਹੋਵੇ।
ਤੁਸੀਂ ਨੀਤੀ ਸੰਪਾਦਕ ਵਿੱਚ ਭਾਲੇ ਬਿਨਾਂ ਕਲਾਇੰਟ ਸੈਟਿੰਗ ਪੜ੍ਹ ਸਕਦੇ ਹੋ:
> Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
RequireSecuritySignature
-------------------------
True
> Get-SmbConnectionਸਰਵਰ ਪਾਸੇ ਦਾ ਸੰਬੰਧਿਤ ਮੁੱਲ ਸਰਵਰ ਦੀ SMB ਕਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਹੈ, ਅਤੇ ਦੋਵਾਂ ਦਾ ਮੇਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਰਿਪੋਰਟ ਕੀਤੇ ਕੇਸ ਵਿੱਚ ਕਲਾਇੰਟ ’ਤੇ ਲੋੜ ਸਥਾਨਕ ਨੀਤੀ ਨਾਲ ਸਮਰੱਥ ਸੀ ਜਦੋਂ ਕਿ ਸਰਵਰ ਬਿਲਕੁਲ ਦਸਤਖ਼ਤ ਨਹੀਂ ਕਰ ਰਿਹਾ ਸੀ; ਇਸਨੂੰ ਅਸਮਰੱਥ ਕਰਕੇ gpupdate /force ਚਲਾਉਣ ਨਾਲ ਸਾਂਝੇਦਾਰੀ ਤੁਰੰਤ ਬਹਾਲ ਹੋ ਗਈ। ਇਹ ਕਾਰਨ ਦੀ ਪੁਸ਼ਟੀ ਲਈ ਨਿਦਾਨਕ ਕਦਮ ਹੈ, ਪੱਕਾ ਹੱਲ ਨਹੀਂ।
ਜਿੱਥੇ ਸਰਵਰ ਸਮਰਥਨ ਕਰਦਾ ਹੈ ਉੱਥੇ ਦੋਵੇਂ ਸਿਰਿਆਂ ’ਤੇ ਦਸਤਖ਼ਤ ਚਾਲੂ ਕਰਨ ਨੂੰ ਤਰਜੀਹ ਦਿਓ। ਸਾਂਝੇਦਾਰੀ ਚੱਲਣ ਲਈ ਸੁਰੱਖਿਆ ਸੈਟਿੰਗ ਬਦਲਣੀ ਇਸਦੇ ਪਿਛਲੇ ਮੁੱਲ ਅਤੇ ਕਾਰਨ ਸਮੇਤ ਦਰਜ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਤਾਂ ਜੋ ਅਗਲੇ ਆਡਿਟ ਵਿੱਚ ਕਿਸੇ ਨੂੰ ਇਹ ਦੁਬਾਰਾ ਲੱਭਣੀ ਨਾ ਪਵੇ।
ਟਾਈਮਰ ਟਿਊਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪੁਰਾਣਾ ਸੈਸ਼ਨ ਸਾਫ਼ ਕਰੋ
ਜੋ ਸਾਂਝੇਦਾਰੀ ਸਿਰਫ਼ VPN ਡਿੱਗਣ ਅਤੇ ਦੁਬਾਰਾ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਅਟਕਦੀ ਹੈ, ਉਹ ਆਮ ਤੌਰ ’ਤੇ ਅਜਿਹਾ ਸੈਸ਼ਨ ਫੜੀ ਰੱਖਦੀ ਹੈ ਜੋ ਸਰਵਰ ਪਹਿਲਾਂ ਹੀ ਸੁੱਟ ਚੁੱਕਾ ਹੈ। ਸਰਵਰ ਅਕਿਰਿਆਸ਼ੀਲ SMB ਸੈਸ਼ਨਾਂ ਨੂੰ LanmanServer\Parameters ਅਧੀਨ Autodisconnect ਟਾਈਮਰ ’ਤੇ ਬੰਦ ਕਰਦਾ ਹੈ, ਜੋ ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ 15 ਮਿੰਟ ਹੈ, ਜਦੋਂ ਕਿ ਕਲਾਇੰਟ ਦਾ ਆਪਣਾ SessTimeout LanmanWorkstation\Parameters ਅਧੀਨ ਹੈ। ਇਨ੍ਹਾਂ ਮੁੱਲਾਂ ਤੋਂ ਲੰਮਾ ਵਿਘਨ ਹਰ ਸਿਰੇ ਨੂੰ ਸੈਸ਼ਨ ਬਾਰੇ ਵੱਖਰੀ ਧਾਰਨਾ ਛੱਡ ਦਿੰਦਾ ਹੈ।
ਨਤੀਜੇ ਦਾ ਕੋਈ ਅਰਥ ਹੋਵੇ ਇਸ ਲਈ ਇਸਨੂੰ ਨਿਸ਼ਚਿਤ ਕ੍ਰਮ ਵਿੱਚ ਦੁਹਰਾਓ: ਟਨਲ ਜੋੜੋ, ਸਾਂਝੇਦਾਰੀ ਖੋਲ੍ਹੋ, ਟਨਲ ਦੋ ਮਿੰਟ ਲਈ ਕੱਟੋ, ਬਹਾਲ ਕਰੋ, ਫਿਰ ਫਾਈਲ ਪੜ੍ਹਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ। ਜੇ ਮਾਊਂਟ ਆਪਣੇ ਆਪ ਠੀਕ ਹੋ ਜਾਵੇ ਤਾਂ ਟਾਈਮਰ ਛੱਡ ਦਿਓ। ਜੇ ਦੁਬਾਰਾ ਮਾਊਂਟ ਕਰਨ ਤੱਕ ਅਟਕਦੀ ਰਹੇ, ਤਾਂ ਟਨਲ ਖੜ੍ਹਨ ਤੋਂ ਬਾਅਦ ਸਾਂਝੇਦਾਰੀ ਦੁਬਾਰਾ ਜੋੜੋ, ਇਸਦੇ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਮਾਊਂਟ ਕਰਨ ਦੀ ਥਾਂ, ਅਤੇ ਵੇਖੋ ਕਿ ਮਾਊਂਟ ਸਹਾਇਕ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।
ਟਾਈਮ ਆਊਟ ਵਧਾਉਣਾ ਅਸਥਿਰ ਲਿੰਕ ਲਈ ਵਾਜਬ ਆਖਰੀ ਕਦਮ ਹੈ, ਪਰ ਇਹ ਲੱਛਣ ਦਾ ਇਲਾਜ ਕਰਦਾ ਹੈ। ਸਰਵਰ ਵੱਲੋਂ ਭੁੱਲੇ ਸੈਸ਼ਨ ਦੀ ਵੱਧ ਦੇਰ ਉਡੀਕ ਕਰਨ ਵਾਲਾ ਕਲਾਇੰਟ ਫਿਰ ਵੀ ਉਡੀਕ ਕਰਦਾ ਹੈ।
ਮਾਊਂਟ ਰਾਹੀਂ ਇੱਕ ਫਾਈਲ ਪੜ੍ਹ ਕੇ ਅਤੇ ਫਿਰ ਇੱਕ ਵਾਰ ਹੋਰ ਟਨਲ ਕੱਟ ਕੇ ਬਹਾਲ ਕਰਕੇ ਸਮਾਪਤ ਕਰੋ। ਉਹ ਸਵੀਕ੍ਰਿਤੀ ਟੈਸਟ ਤਿੰਨੇ ਪਰਤਾਂ ਇੱਕੋ ਵੇਲੇ ਢਕਦਾ ਹੈ, ਅਤੇ ਇਹ ਇੱਕੋ-ਇੱਕ ਟੈਸਟ ਹੈ ਜੋ ਵਰਤੋਂਕਾਰ ਦੇ ਅਸਲ ਕੰਮ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ।