OpenVPN ਜਾਂ IKEv2: ਪ੍ਰੋਟੋਕੋਲ ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ ਚਾਰ ਜਾਂਚਾਂ

OpenVPN ਅਤੇ IKEv2 ਵਿਚਕਾਰ ਚੋਣ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰੋਟੋਕੋਲ ਦੇ ਸਵਾਲ ਵਜੋਂ ਬਹਿਸੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਇਹ ਢਾਂਚਾ ਫੈਸਲੇ ਨੂੰ ਵਿਅਰਥ ਕਰਦਾ ਹੈ। ਤੁਹਾਡਾ ਸਰਵਰ ਅਤੇ ਤੁਹਾਡੇ ਯੰਤਰ ਇੱਕੋ ਪੂਰੀ ਪ੍ਰੋਫਾਈਲ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਉਹ ਪ੍ਰੋਫਾਈਲ ਨੈੱਟਵਰਕਾਂ ਵਿਚਕਾਰ ਤੁਹਾਡੀ ਆਵਾਜਾਈ ਨੂੰ ਝੱਲਦੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਹ ਫੈਸਲਾ ਕਰਦਾ ਹੈ। ਦੋਵੇਂ ਸਟੈਕ ਇੱਕ-ਦੂਜੇ ਵਿੱਚ ਤਬਦੀਲ ਨਹੀਂ ਹੁੰਦੇ: OVPN ਫਾਈਲ ਵੱਖਰੀ ਸਿੰਟੈਕਸ ਵਾਲੀ IKEv2 ਪ੍ਰੋਫਾਈਲ ਨਹੀਂ ਹੈ। ਕ੍ਰਮ ਵਿੱਚ ਕੀਤੀਆਂ ਚਾਰ ਜਾਂਚਾਂ ਕਿਸੇ ਵੀ ਫੀਚਰ ਸਾਰਣੀ ਨਾਲੋਂ ਤੇਜ਼ੀ ਨਾਲ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀਆਂ ਹਨ।

ਕਲਾਇੰਟ ਨਾ ਹੋਵੇ ਤਾਂ ਬਹਿਸ ਖ਼ਤਮ

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

Windows 'ਤੇ ਇੱਕ ਕਮਾਂਡ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਪ੍ਰੋਫਾਈਲਾਂ ਦੀ ਸੂਚੀ ਦਿੰਦੀ ਹੈ ਅਤੇ ਦੱਸਦੀ ਹੈ ਕਿ ਹਰ ਇੱਕ ਕਿਸ ਕਿਸਮ ਦੀ ਹੈ। ਇਹ ਜੋ ਨਾਮ ਛਾਪਦੀ ਹੈ ਉਹੀ ਨਾਮ ਅੱਗੇ ਦੀਆਂ ਜਾਂਚਾਂ ਵਰਤਦੀਆਂ ਹਨ।

Get-VpnConnection -AllUserConnection
Get-VpnConnection -Name <profile-name> | Select-Object Name, ServerAddress, TunnelType

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

ਗਤੀਸ਼ੀਲਤਾ ਸਾਂਝੀ ਸੈਟਿੰਗ ਹੈ, ਪ੍ਰੋਟੋਕੋਲ ਦਾ ਵਾਅਦਾ ਨਹੀਂ

IKEv2 MOBIKE ਦੀ ਵਰਤੋਂ ਤਦ ਕਰ ਸਕਦਾ ਹੈ ਜਦੋਂ ਦੋਵੇਂ ਸਿਰੇ ਇਸ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਅਤੇ ਇਸ ਨੂੰ ਸਮਰੱਥ ਕਰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਕਲਾਇੰਟ ਪਤਾ ਬਦਲਣ ਸਮੇਂ ਵੀ ਆਪਣੀ ਸੁਰੰਗ ਬਣਾਈ ਰੱਖ ਸਕਦਾ ਹੈ। RFC 4555 ਇਸ ਵਿਸਤਾਰ ਦੀ ਪਰਿਭਾਸ਼ਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਸ਼ਰਤੀ ਸ਼ਬਦਾਵਲੀ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਇਸ ਸਮਰੱਥਾ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨ ਵਾਲਾ ਸਰਵਰ ਇਸ ਦੀ ਬਜਾਏ ਦੁਬਾਰਾ ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ। ਨਤੀਜਾ ਫਾਈਲ ਟ੍ਰਾਂਸਫਰ ਲਈ ਇੱਕੋ ਜਿਹਾ ਅਤੇ ਲਾਈਵ ਕਾਲ ਲਈ ਬਹੁਤ ਵੱਖਰਾ ਦਿਸ ਸਕਦਾ ਹੈ।

ਜਿਸ ਤਬਦੀਲੀ ਦੀ ਤੁਹਾਨੂੰ ਸੱਚਮੁੱਚ ਪਰਵਾਹ ਹੈ, ਉਸ ਨੂੰ ਕਿਸੇ ਚੱਲ ਰਹੀ ਚੀਜ਼ ਨਾਲ ਜਾਂਚੋ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਦੇਖ ਸਕੋ। Windows 'ਤੇ ping -t <internal-host> ਚੱਲਦਾ ਰੱਖੋ, ਜਾਂ ਕਿਤੇ ਹੋਰ ਸਾਧਾਰਨ ping, ਫਿਰ Wi-Fi ਤੋਂ ਸੈਲੂਲਰ 'ਤੇ ਜਾਓ ਅਤੇ ਵਿਰਾਮ ਵੇਖੋ। MOBIKE ਦੀ ਅਸਫਲਤਾ ਕਲਾਇੰਟ ਲੌਗ ਵਿੱਚ ਚੁੱਪਚਾਪ ਪਤਾ ਅੱਪਡੇਟ ਹੋਣ ਦੀ ਬਜਾਏ ਪੂਰੀ ਮੁੜ-ਪ੍ਰਮਾਣਿਕਤਾ ਵਜੋਂ ਦਿਸਦੀ ਹੈ। ਤੁਸੀਂ ਇਹ ਮਾਪ ਰਹੇ ਹੋ ਕਿ ਸੁਰੰਗ ਤਬਦੀਲੀ ਨੂੰ ਝੱਲਦੀ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਹ ਨਹੀਂ ਕਿ ਪ੍ਰੋਟੋਕੋਲ ਸਮਰਥਨ ਦਾ ਇਸ਼ਤਿਹਾਰ ਦਿੰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।

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

ਪ੍ਰਮਾਣ ਸੇਵਾ ਦੇ ਹੁੰਦੇ ਹਨ, ਸਟੈਕ ਦੇ ਨਹੀਂ

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

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

openssl x509 -in client.crt -noout -subject -issuer -dates

ਕੰਪਨੀ ਕਨੈਕਸ਼ਨ ਲਈ ਕੰਪਨੀ ਵੱਲੋਂ ਪ੍ਰਕਾਸ਼ਿਤ ਢੰਗ ਵਰਤੋ ਅਤੇ ਤੁਲਨਾ ਨੂੰ ਪ੍ਰਯੋਗ ਮੰਨਣਾ ਬੰਦ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਆਪ ਦੋਵਾਂ ਦੀ ਤੁਲਨਾ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਪਹਿਲਾਂ ਵੇਖੋ ਕਿ ਦੋਵੇਂ ਵਿਕਲਪ ਇੱਕੋ ਗੇਟਵੇ 'ਤੇ ਖ਼ਤਮ ਹੁੰਦੇ ਹਨ ਜਾਂ ਨਹੀਂ, ਕਿਉਂਕਿ ਇਹੀ ਇੱਕ ਵੇਰਵਾ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਨਤੀਜੇ ਦਾ ਕਿੰਨਾ ਹਿੱਸਾ ਪ੍ਰੋਟੋਕੋਲ ਬਾਰੇ ਹੈ। ਪ੍ਰਮਾਣ ਦਾ ਨਾਮ ਲੈਣ ਵਾਲਾ ਇਨਕਾਰ ਪ੍ਰਮਾਣ ਦੀ ਸਮੱਸਿਆ ਹੈ, ਅਤੇ ਕਿੰਨਾ ਵੀ ਪ੍ਰੋਟੋਕੋਲ ਬਦਲਿਆ ਜਾਵੇ ਉਹ ਠੀਕ ਨਹੀਂ ਹੋਵੇਗਾ।

ਵੇਖੋ ਸੁਰੰਗ ਅਸਲ ਵਿੱਚ ਕੀ ਰੂਟ ਕਰਦੀ ਹੈ

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

Windows 'ਤੇ ਦੋ ਕਮਾਂਡਾਂ ਰਾਹ ਅਤੇ ਨਾਮ ਖੋਜ ਦੋਵੇਂ ਕਵਰ ਕਰਦੀਆਂ ਹਨ। Linux ਵਿੱਚ ਬਰਾਬਰ ਦੇ ip route show default ਅਤੇ resolvectl query <internal-host> ਹਨ।

Get-NetRoute -DestinationPrefix 0.0.0.0/0
Resolve-DnsName <internal-host>

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

ਜਾਂਚਾਂ ਤੋਂ ਬਾਅਦ ਸੰਭਾਲ ਨੂੰ ਤੋਲੋ

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

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