ਇੱਕ ਟੀਮ ਵਿੱਚ ਤਿੰਨ ਲੈਪਟਾਪ, ਤਿੰਨ ਵੱਖਰੇ VPN ਮੀਨੂ, ਅਤੇ ਇੱਕ ਟਿਕਟ ਜੋ ਕਹਿੰਦੀ ਹੈ ਕਿ ਕਨੈਕਸ਼ਨ ਹਰ ਥਾਂ ਚੱਲਦਾ ਹੈ ਸਿਵਾਏ Mac ਦੇ। ਉਹਨਾਂ ਕਲਾਇੰਟਾਂ ਪਿੱਛੇ ਦੀ ਯੋਜਨਾ ਇੱਕੋ ਹੋ ਸਕਦੀ ਹੈ ਭਾਵੇਂ ਮੀਨੂ ਵੱਖਰੇ ਹੋਣ। ਜੋ ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ ਉਹ ਬਹੁਤੇ ਰੋਲਆਊਟਾਂ ਦੇ ਅਨੁਮਾਨ ਨਾਲੋਂ ਤੰਗ ਹੈ: ਇੱਕ ਗੇਟਵੇ ਪਛਾਣ, ਇੱਕ ਪ੍ਰਮਾਣ ਕਿਸਮ, ਇੱਕ ਰਸਤਾ ਸੈੱਟ ਅਤੇ ਇੱਕ ਰੈਜ਼ੋਲਵਰ ਨੀਤੀ। ਕੋਈ ਪ੍ਰੋਫਾਈਲ ਐਕਸਪੋਰਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਚਾਰ ਲਿਖ ਲਵੋ, ਫਿਰ ਪਲੇਟਫਾਰਮ ਦਾ ਕੰਮ ਜਾਂਚ ਦੀ ਥਾਂ ਚੈੱਕਲਿਸਟ ਬਣ ਜਾਂਦਾ ਹੈ।

ਕਲਾਇੰਟ ਫਾਈਲ ਨਾਲ ਨਹੀਂ, ਪਹੁੰਚ ਸਮਝੌਤੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ

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

ਦਫ਼ਤਰ ਦੀ ਇੱਕ ਮਿਸਾਲ ਆਕਾਰ ਸਪਸ਼ਟ ਕਰਦੀ ਹੈ: 10.60.0.0/16 ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ, corp.example ਹੇਠ ਨਿੱਜੀ ਨਾਮ, 10.61.0.53 ਉੱਤੇ ਅੰਦਰੂਨੀ ਰੈਜ਼ੋਲਵਰ, ਅਤੇ ਆਮ ਬ੍ਰਾਊਜ਼ਿੰਗ ਡਿਵਾਈਸ ਦੇ ਪਹਿਲਾਂ ਵਾਲੇ ਰਸਤੇ ਉੱਤੇ ਹੀ ਰਹਿੰਦੀ ਹੈ। ਆਖਰੀ ਗੱਲ ਕਲਾਇੰਟ ਡਿਫਾਲਟ ਨਹੀਂ, ਨੀਤੀ ਦਾ ਫ਼ੈਸਲਾ ਹੈ; ਜੇ ਕੋਈ ਹੋਰ ਨਾ ਕਹੇ ਤਾਂ ਕਈ ਕਲਾਇੰਟ ਸਭ ਕੁਝ ਸੁਰੰਗ ਰਾਹੀਂ ਭੇਜਦੇ ਹਨ। ਸਮਝੌਤਾ ਤਾਰੀਖ਼ ਅਤੇ ਮਾਲਕ ਸਮੇਤ ਦਰਜ ਕਰੋ, ਕਿਉਂਕਿ ਸੁਰੰਗ ਬਦਲੀ ਜਾਂ ਨੀਤੀ ਬਦਲੀ ਇਹ ਬਾਅਦ ਵਿੱਚ ਉਹੀ ਰਿਕਾਰਡ ਦੱਸਦਾ ਹੈ।

ਇੱਕ ਪ੍ਰੋਟੋਕੋਲ ਅਤੇ ਇੱਕ ਪ੍ਰਮਾਣਿਕਤਾ ਜੋੜੀ ਚੁਣੋ ਜਿਸਦਾ ਤੁਸੀਂ ਬਚਾਅ ਕਰ ਸਕੋ

ਬਿਨਾਂ ਵਾਧੂ ਸੌਫ਼ਟਵੇਅਰ ਤਿੰਨੇ ਪਲੇਟਫਾਰਮ ਚੱਲਣੇ ਚਾਹੀਦੇ ਹਨ ਤਾਂ ਸਰਟੀਫਿਕੇਟ-ਆਧਾਰਿਤ ਗੇਟਵੇ ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਵਰਤੋਂਕਾਰ ਲਈ EAP ਵਾਲਾ IKEv2 ਆਮ ਚੋਣ ਹੈ, ਕਿਉਂਕਿ Windows, macOS ਅਤੇ NetworkManager ਹਰ ਇੱਕ IKEv2 ਕਲਾਇੰਟ ਦਿੰਦਾ ਹੈ। ਮੁਸੀਬਤ ਇਹ ਹੈ ਕਿ IKEv2 ਦਾ ਸਮਰਥਨ ਇੱਕ ਲੇਬਲ ਹੈ, ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਦਾ ਸੈੱਟ ਨਹੀਂ। EAP ਢੰਗ, ਹਾਰਡਵੇਅਰ-ਆਧਾਰਿਤ ਕੁੰਜੀਆਂ, ਸਰਟੀਫਿਕੇਟ-ਖਾਤਾ ਨਕਸ਼ਾ ਅਤੇ ਆਪਣੇ-ਆਪ ਮੁੜ ਕਨੈਕਟ ਹਰ ਪਲੇਟਫਾਰਮ ਉੱਤੇ ਵੱਖਰੇ ਲਾਗੂ ਹੁੰਦੇ ਹਨ। ਤਿੰਨ ਵਿੱਚੋਂ ਦੋ ਉੱਤੇ ਚੱਲਣ ਵਾਲਾ ਮੇਲ ਇੰਨਾ ਆਮ ਹੈ ਕਿ ਜਾਂਚ ਹੋਣ ਤੱਕ ਇਹੀ ਮੰਨੋ।

ਡਿਪਲੌਇਮੈਂਟ ਗਾਈਡ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਟਾਰਗਿਟ ਪਲੇਟਫਾਰਮ ਉੱਤੇ ਜੋੜੀ ਦੀ ਜਾਂਚ ਕਰੋ, ਬਾਅਦ ਵਿੱਚ ਨਹੀਂ। EAP-MSCHAPv2 ਅਤੇ EAP-TLS ਦੋਵੇਂ ਦੇਣ ਵਾਲਾ ਗੇਟਵੇ ਪਿੱਛੇ ਹਟਣ ਦੀ ਥਾਂ ਦਿੰਦਾ ਹੈ, ਬਸ਼ਰਤੇ ਉਹ ਪਿੱਛੇ ਹਟਣਾ ਘਟਨਾ ਦੇ ਸਮੇਂ ਲੱਭਣ ਦੀ ਥਾਂ ਸਮਰਥਿਤ ਵਜੋਂ ਦਰਜ ਹੋਵੇ। ਦੋ ਸਮਰਥਿਤ ਰਸਤੇ ਸਸਤਾ ਬੀਮਾ ਹਨ; ਬਿਨਾਂ ਦਰਜ ਤੀਜਾ ਰਸਤਾ ਭਵਿੱਖ ਦੀ ਟਿਕਟ ਹੈ।

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

ਸਮਝੌਤੇ ਤੋਂ ਹਰ ਪਲੇਟਫਾਰਮ ਲਈ ਇੱਕ ਕਲਾਕ੍ਰਿਤੀ ਬਣਾਓ

Windows VPNv2 ਪ੍ਰੋਫਾਈਲ ਲੈਂਦਾ ਹੈ, ਜੋ MDM ਦਿੰਦਾ ਹੈ ਜਾਂ Add-VpnConnection ਅਤੇ ਇਸਦੇ XML ਪੇਲੋਡ ਨਾਲ ਸਥਾਨਕ ਤੌਰ ਉੱਤੇ ਬਣਦਾ ਹੈ। ਡੰਗਣ ਵਾਲੇ ਹਿੱਸੇ ਦਾਇਰਾ ਅਤੇ ਭਰੋਸਾ ਹਨ। ਡਿਵਾਈਸ-ਦਾਇਰੇ ਦਾ ਪ੍ਰੋਫਾਈਲ ਅਤੇ ਵਰਤੋਂਕਾਰ-ਦਾਇਰੇ ਦਾ ਪ੍ਰੋਫਾਈਲ ਵੱਖਰੇ ਸਟੋਰਾਂ ਵਿੱਚ ਬੈਠਦੇ ਹਨ, ਇਸ ਲਈ ਕਲਾਇੰਟ ਨੂੰ ਲੋੜੀਂਦਾ ਸਰਟੀਫਿਕੇਟ ਤੁਹਾਡੇ ਚੁਣੇ ਦਾਇਰੇ ਨਾਲ ਮਿਲਦੇ ਸਟੋਰ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਜੋੜੀ ਗਲਤ ਹੋਈ ਤਾਂ ਪ੍ਰੋਫਾਈਲ ਸਾਫ਼ ਇੰਪੋਰਟ ਹੋ ਕੇ ਪਹਿਲੇ ਕਨੈਕਟ ਉੱਤੇ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦਾ ਹੈ।

macOS ਪ੍ਰਬੰਧਿਤ VPN ਪੇਲੋਡ ਵਾਲਾ ਕੌਨਫਿਗਰੇਸ਼ਨ ਪ੍ਰੋਫਾਈਲ ਲੈਂਦਾ ਹੈ, ਜੋ ਦਸਤਖ਼ਤ ਕਰਕੇ MDM ਰਾਹੀਂ ਭੇਜਿਆ ਜਾਂ ਪਾਇਲਟ ਲਈ ਹੱਥੋਂ ਲਗਾਇਆ ਜਾਂਦਾ ਹੈ। ਪਛਾਣ ਅਤੇ CA ਚੇਨ ਵੱਖਰੇ ਪੇਲੋਡਾਂ ਵਜੋਂ ਸਫ਼ਰ ਕਰਦੇ ਹਨ, ਇਸੇ ਲਈ ਪ੍ਰੋਫਾਈਲ ਬਿਨਾਂ ਸ਼ਿਕਾਇਤ ਲੱਗ ਕੇ ਕਨੈਕਟ ਵੇਲੇ ਫੇਲ੍ਹ ਹੋ ਸਕਦਾ ਹੈ। ਸਿਰਫ਼ ਇੰਸਟਾਲ ਨਤੀਜਾ ਨਹੀਂ, ਪੇਲੋਡ ਸੂਚੀ ਜਾਂਚੋ।

Linux NetworkManager ਪਿੱਛੇ ਦੇ ਬੈਕਐਂਡ ਉੱਤੇ ਨਿਰਭਰ ਹੈ, ਅਤੇ strongSwan ਤੇ NetworkManager ਪਲੱਗਇਨ ਵੱਖਰੇ ਪੈਕੇਜ ਹਨ। ਕਨੈਕਸ਼ਨ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਆਮ VPN ਕੁੰਜੀਆਂ ਨਹੀਂ, ਪਲੱਗਇਨ-ਖ਼ਾਸ ਹਨ, ਇਸ ਲਈ ਦੂਜੇ ਪਲੱਗਇਨ ਤੋਂ ਕਾਪੀ ਕੀਤੀ ਕੁੰਜੀ ਅਕਸਰ ਬਿਨਾਂ ਗਲਤੀ ਸੰਭਾਲੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਸਰਗਰਮੀ ਵੇਲੇ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ। ਪਲੱਗਇਨ ਅਸਲ ਵਿੱਚ ਜਿੱਥੇ ਚੱਲੇਗਾ ਉੱਥੇ ਮੌਜੂਦ ਹੈ ਜਾਂ ਨਹੀਂ ਇਹ ਪੱਕਾ ਕਰਨ ਲਈ ਸਾਫ਼ ਇਮੇਜ ਉੱਤੇ ਕਨੈਕਸ਼ਨ ਬਣਾਓ।

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

PlatformArtifactCheck before handoff
WindowsVPNv2 profile or Add-VpnConnectionScope matches certificate store
macOSManaged VPN payload plus certificate payloadBoth payloads present in one profile
LinuxNetworkManager connection with strongSwan backendPlugin package installed on the image

ਸਾਫ਼ ਖਾਤੇ ਉੱਤੇ ਰਸਤੇ, ਰੈਜ਼ੋਲਵਰ ਅਤੇ ਮੁੜ ਕਨੈਕਟ ਦੀ ਜਾਂਚ ਕਰੋ

ਕਨੈਕਟ ਹੋ ਗਿਆ ਇਹ ਸਵੀਕ੍ਰਿਤੀ ਜਾਂਚ ਨਹੀਂ ਹੈ। Windows ਉੱਤੇ Get-VpnConnection ਪ੍ਰੋਫਾਈਲ ਦਿਖਾਉਂਦਾ ਹੈ ਅਤੇ route print ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਨਿੱਜੀ ਪ੍ਰੀਫਿਕਸ ਸੁਰੰਗ ਇੰਟਰਫੇਸ ਉੱਤੇ ਪਿਆ ਜਾਂ ਨਹੀਂ। macOS ਉੱਤੇ scutil --nc list ਸਰਗਰਮ ਸੇਵਾ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ ਜਦਕਿ scutil --dns ਉਹ ਰੈਜ਼ੋਲਵਰ ਕ੍ਰਮ ਦਿਖਾਉਂਦਾ ਹੈ ਜੋ ਸਿਸਟਮ ਸੱਚਮੁੱਚ ਵਰਤੇਗਾ।

Linux ਉੱਤੇ nmcli connection show --active ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਕਨੈਕਸ਼ਨ ਚਾਲੂ ਹੈ ਅਤੇ resolvectl status ਹਰ ਲਿੰਕ ਲਈ DNS ਦਿਖਾਉਂਦਾ ਹੈ। ਕਨੈਕਸ਼ਨ ਫਾਈਲ ਵਿੱਚ ਮੌਜੂਦ ਰੈਜ਼ੋਲਵਰ ਜੇ ਪ੍ਰਤੀ-ਲਿੰਕ ਆਉਟਪੁੱਟ ਵਿੱਚ ਨਹੀਂ ਤਾਂ ਵੰਡਿਆ DNS ਲਾਗੂ ਨਹੀਂ ਹੋ ਰਿਹਾ। ਨਾਮ ਹੱਲ ਹੋਣ ਅਤੇ ਸੁਰੰਗ ਰਾਹੀਂ ਨਾਮ ਹੱਲ ਹੋਣ ਵਿੱਚ ਇਹੀ ਫ਼ਰਕ ਹੈ, ਅਤੇ ਇਹ ਬਦਲਦਾ ਹੈ ਕਿ ਅਗਲਾ ਕਦਮ ਕਿਹੜੀ ਸਹਾਇਤਾ ਟੀਮ ਦਾ ਹੈ। ਕਨੈਕਸ਼ਨ ਆਉਣ ਤੋਂ ਬਾਅਦ ਹੀ ਨਹੀਂ, ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਪ੍ਰਤੀ-ਲਿੰਕ ਆਉਟਪੁੱਟ ਦੀ ਤੁਲਨਾ ਕਰੋ।

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

ਪੈਕੇਜ ਨੂੰ ਸੰਸਕਰਣ ਦਿਓ ਅਤੇ ਰੋਲਬੈਕ ਰਸਤਾ ਰੱਖੋ

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

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

ਸੰਬੰਧਿਤ ਲੇਖ