Android IKEv2: ਵਰਤੋਂਕਾਰ ਸਰਟੀਫਿਕੇਟ ਅਤੇ CA ਵੱਖਰੇ ਕੰਮ ਕਰਦੇ ਹਨ
ਇੱਕ ਖੇਤਰ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਫੋਨ ਕੌਣ ਹੈ, ਦੂਜਾ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕਿਸ ਗੇਟਵੇ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਹੈ। Android ਦਾ IKEv2 ਪ੍ਰੋਫਾਈਲ ਦੋਵਾਂ ਨੂੰ ਵੱਖ ਰੱਖਦਾ ਹੈ।
Android ਵਿੱਚ IKEv2 ਸਕ੍ਰੀਨ ਜਦੋਂ ਇੱਕੋ ਸਮੇਂ ਵਰਤੋਂਕਾਰ ਸਰਟੀਫਿਕੇਟ ਅਤੇ CA ਸਰਟੀਫਿਕੇਟ ਮੰਗਦੀ ਹੈ ਤਾਂ ਲੱਗਦਾ ਹੈ ਕਿ ਉਹੀ ਚੀਜ਼ ਦੋ ਵਾਰ ਮੰਗੀ ਜਾ ਰਹੀ ਹੈ। ਪਰ ਐਸਾ ਨਹੀਂ ਹੈ। IKEv2 ਇੱਕ ਹੀ ਅਦਲਾ-ਬਦਲੀ ਵਿੱਚ ਦੋਵਾਂ ਧਿਰਾਂ ਨੂੰ ਦੋਵਾਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਫੋਨ ਦੀ ਹਰ ਦਿਸ਼ਾ ਵਿੱਚ ਵੱਖਰੀ ਭੂਮਿਕਾ ਹੁੰਦੀ ਹੈ: ਆਪਣੇ ਆਪ ਨੂੰ ਕੌਣ ਹੈ ਇਹ ਸਾਬਤ ਕਰਨਾ ਅਤੇ ਕਿਸ ਗੇਟਵੇ 'ਤੇ ਯਕੀਨ ਕਰਨਾ ਹੈ ਇਹ ਤੈਅ ਕਰਨਾ। ਵਰਤੋਂਕਾਰ ਸਰਟੀਫਿਕੇਟ ਪਹਿਲੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਭਰੋਸੇਯੋਗ CA ਦੂਜੇ ਦਾ, ਅਤੇ ਕੋਈ ਵੀ ਦੂਜੇ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈ ਸਕਦਾ।
ਇੱਕ ਅਦਲਾ-ਬਦਲੀ ਵਿੱਚ ਪ੍ਰਮਾਣਿਕਤਾ ਦੀਆਂ ਦੋ ਦਿਸ਼ਾਵਾਂ
IKEv2 ਦੋ ਪੜਾਵਾਂ ਵਿੱਚ ਕੰਟਰੋਲ ਚੈਨਲ ਬਣਾਉਂਦਾ ਹੈ। ਪਹਿਲਾ ਪੜਾਅ ਐਲਗੋਰਿਦਮ ਅਤੇ ਕੁੰਜੀਆਂ ਬਾਰੇ ਗੱਲ ਕਰਦਾ ਹੈ; ਦੂਜਾ, IKE_AUTH, ਹਰ ਧਿਰ ਤੋਂ ਇੱਕ AUTH ਪੇਲੋਡ ਉਸ ਦੀ ਪਛਾਣ ਨਾਲ ਲਿਆਉਂਦਾ ਹੈ। ਪੇਲੋਡ ਅਦਲਾ-ਬਦਲੀ ਉੱਤੇ ਕੀਤਾ ਦਸਤਖਤ ਜਾਂ MAC ਹੈ, ਅਤੇ ਇਸ ਨੂੰ ਉਸ ਚੀਜ਼ ਨਾਲ ਜਾਂਚਿਆ ਜਾਂਦਾ ਹੈ ਜਿਸ 'ਤੇ ਪ੍ਰਾਪਤਕਰਤਾ ਪਹਿਲਾਂ ਹੀ ਭਰੋਸਾ ਕਰਦਾ ਹੈ।
ਗੇਟਵੇ ਆਪਣੇ ਸਰਟੀਫਿਕੇਟ ਨਾਲ ਆਪਣੇ ਆਪ ਨੂੰ ਸਾਬਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਫੋਨ ਲੜੀ ਨੂੰ ਆਪਣੇ ਸਵੀਕਾਰ ਕੀਤੇ ਮੂਲ ਤੱਕ ਜਾਂਚਦਾ ਹੈ ਤੇ ਵੇਖਦਾ ਹੈ ਕਿ ਸਰਟੀਫਿਕੇਟ ਦੀ ਪਛਾਣ ਉਸ ਗੇਟਵੇ ਨਾਲ ਮਿਲਦੀ ਹੈ ਜਿਸ ਤੱਕ ਪਹੁੰਚਣਾ ਸੀ; ਫੋਨ ਆਪਣੇ ਪ੍ਰਮਾਣ-ਪੱਤਰਾਂ ਨਾਲ ਆਪਣੇ ਆਪ ਨੂੰ ਸਾਬਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਗੇਟਵੇ ਉਹਨਾਂ ਨੂੰ ਉਸ CA ਨਾਲ ਜਾਂਚਦਾ ਹੈ ਜਿਸ ਨੇ ਕਲਾਇੰਟ ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਕੀਤਾ।
ਦੋਵਾਂ ਖੇਤਰਾਂ ਪਿੱਛੇ ਇਹੀ ਪੂਰਾ ਕਾਰਜ-ਢਾਂਚਾ ਹੈ। ਵਰਤੋਂਕਾਰ ਸਰਟੀਫਿਕੇਟ ਫੋਨ ਦਾ ਆਪਣੇ ਬਾਰੇ ਬਿਆਨ ਹੈ; CA ਖੇਤਰ ਇਸ ਬਾਰੇ ਬਿਆਨ ਹੈ ਕਿ ਉਹ ਕਿਸ 'ਤੇ ਵਿਸ਼ਵਾਸ ਕਰੇਗਾ। ਇੱਕ ਹੋਵੇ ਤੇ ਦੂਜਾ ਨਾ ਹੋਵੇ ਤਾਂ ਪ੍ਰੋਫਾਈਲ ਆਪਸੀ ਪ੍ਰਮਾਣਿਕਤਾ ਪੂਰੀ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਅਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਨਾਲ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ। ਅਸਫਲਤਾਵਾਂ ਵੀ ਵੱਖਰੀਆਂ ਦਿਸਦੀਆਂ ਹਨ: ਵਰਤੋਂਕਾਰ ਕੁੰਜੀ ਤੋਂ ਬਿਨਾਂ ਫੋਨ ਦਸਤਖਤ ਹੀ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਅਤੇ ਭਰੋਸੇ ਦੇ ਆਧਾਰ ਤੋਂ ਬਿਨਾਂ ਗੇਟਵੇ ਦਾ ਸਰਟੀਫਿਕੇਟ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰ ਸਕਦਾ।
| Material | Role | What it cannot do |
|---|---|---|
| User certificate plus its private key | Proves possession of the enrolled client identity | Establish that the gateway is the right one |
| Trusted CA certificate | Validates the gateway chain under the intended identity checks | Prove the client's identity to the gateway |
| Expected gateway identity | Pins which server the phone accepts | Grant that user access to every private resource |
Android ਪ੍ਰੋਫਾਈਲ ਬਿਲਡਰ ਕੀ ਮੰਗਦਾ ਹੈ
Android ਦਾ IKEv2 ਪ੍ਰੋਫਾਈਲ ਬਿਲਡਰ ਹਰ ਪ੍ਰਮਾਣਿਕਤਾ ਢੰਗ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਦਿੰਦਾ ਹੈ, ਇੱਕੋ ਸਰਟੀਫਿਕੇਟ ਮੋਡ ਵਜੋਂ ਨਹੀਂ। ਡਿਜੀਟਲ ਦਸਤਖਤ ਢੰਗ ਵਰਤੋਂਕਾਰ ਸਰਟੀਫਿਕੇਟ, ਨਿੱਜੀ ਕੁੰਜੀ ਅਤੇ ਸਰਵਰ ਦਾ ਮੂਲ CA ਲੈਂਦਾ ਹੈ; ਬਾਕੀ ਢੰਗ ਵਰਤੋਂਕਾਰ ਨਾਂ ਅਤੇ ਪਾਸਵਰਡ, ਜਾਂ ਪਹਿਲਾਂ ਸਾਂਝੀ ਕੀਤੀ ਕੁੰਜੀ ਲੈਂਦੇ ਹਨ।
ਉਹ ਦਸਤਖਤ ਧਿਆਨ ਨਾਲ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਉਹ ਉੱਪਰਲਾ ਢਾਂਚਾ ਬਿਆਨ ਕਰਦਾ ਹੈ। ਵਰਤੋਂਕਾਰ ਨਾਂ ਅਤੇ ਪਾਸਵਰਡ ਢੰਗ ਵਿੱਚ ਨਿੱਜੀ ਕੁੰਜੀ ਲਈ ਕੋਈ ਖੇਤਰ ਨਹੀਂ, ਅਤੇ PSK ਢੰਗ ਵਿੱਚ ਗੇਟਵੇ ਦੇ ਭਰੋਸੇ ਆਧਾਰ ਲਈ ਕੋਈ ਖੇਤਰ ਨਹੀਂ, ਕਿਉਂਕਿ ਉਹ ਢੰਗ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਸਾਬਤ ਕਰਦੇ ਹਨ। ਸਰਟੀਫਿਕੇਟ ਖੇਤਰ ਵਿੱਚ ਪਾਸਵਰਡ ਲਾਉਣ ਨਾਲ IKE_AUTH 'ਤੇ ਅਸਫਲ ਹੋਣ ਵਾਲਾ ਪ੍ਰੋਫਾਈਲ ਬਣਦਾ ਹੈ, ਅਤੇ ਸੁਨੇਹਾ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਦਾ ਨਾਂ ਨਹੀਂ ਲੈਂਦਾ।
ਡਿਜੀਟਲ ਦਸਤਖਤ ਢੰਗ ਲਈ ਦਰਜ ਨਿੱਜੀ ਕੁੰਜੀ ਦੀ ਕਿਸਮ RSA ਹੈ। IPsec ਜਾਂ ਸਰਟੀਫਿਕੇਟ ਲਿਖਿਆ ਮੀਨੂ ECDSA ਸਮਰਥਨ ਦਾ ਮਤਲਬ ਨਹੀਂ, ਅਤੇ ਉਸ ਧਾਰਨਾ 'ਤੇ ਬਣਿਆ ਪ੍ਰੋਫਾਈਲ ਨੈੱਟਵਰਕ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਪਲੇਟਫਾਰਮ API 'ਤੇ ਅਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ।
ਸਿਰਫ਼ ਜਨਤਕ ਸਰਟੀਫਿਕੇਟ ਕਿਉਂ ਕਾਫ਼ੀ ਨਹੀਂ
AUTH ਪੇਲੋਡ ਕਲਾਇੰਟ ਦੀ ਨਿੱਜੀ ਕੁੰਜੀ ਨਾਲ ਅਦਲਾ-ਬਦਲੀ 'ਤੇ ਕੀਤਾ ਦਸਤਖਤ ਹੈ। ਜਨਤਕ ਸਰਟੀਫਿਕੇਟ ਗੇਟਵੇ ਨੂੰ ਦਸਤਖਤ ਜਾਂਚਣ ਦਿੰਦਾ ਹੈ, ਪਰ ਫੋਨ ਲਈ ਕੁਝ ਨਹੀਂ ਕਰਦਾ, ਕਿਉਂਕਿ ਦਸਤਖਤ ਬਣਾਉਣ ਲਈ ਉਸ ਨੂੰ ਕੁੰਜੀ ਚਾਹੀਦੀ ਹੈ। ਸਿਰਫ਼ .crt ਆਯਾਤ ਕਰਕੇ ਕੁੰਜੀ ਪਿੱਛੇ ਛੱਡਣਾ ਇਸ ਅਸਫਲਤਾ ਦਾ ਸਭ ਤੋਂ ਆਮ ਰੂਪ ਹੈ।
Android ਦਾ ਕੁੰਜੀ ਢਾਂਚਾ ਇਹੀ ਦਿਖਾਉਂਦਾ ਹੈ: ਕਲਾਇੰਟ ਪਛਾਣ ਚੁਣਨਾ KeyChain ਰਾਹੀਂ ਜਾਂਦਾ ਹੈ, ਜਿਸ ਨੂੰ ਸੰਬੰਧਿਤ ਨਿੱਜੀ ਕੁੰਜੀ ਤੱਕ ਪਹੁੰਚ ਚਾਹੀਦੀ ਹੈ, ਸਿਰਫ਼ ਸਰਟੀਫਿਕੇਟ ਐਂਟਰੀ ਨਹੀਂ। ਜੋੜੀ ਨੂੰ ਇਕੱਠਿਆਂ ਸਥਾਪਤ ਕਰਨ ਵਾਲਾ ਰਜਿਸਟਰੇਸ਼ਨ ਪੈਕੇਜ ਜਾਂ ਡਿਵਾਈਸ ਪ੍ਰਬੰਧਨ ਪ੍ਰਵਾਹ ਲਾਭਦਾਇਕ ਪਛਾਣ ਲੈਣ ਦਾ ਆਮ ਰਾਹ ਹੈ; ਹੱਥ ਨਾਲ ਫਾਈਲ ਕਾਪੀ ਕਰਨਾ ਆਮ ਤੌਰ 'ਤੇ ਨਹੀਂ।
ਇਸ ਲਈ ਪ੍ਰੋਫਾਈਲ ਦੀਆਂ ਦੋ ਚੀਜ਼ਾਂ ਸਰਟੀਫਿਕੇਟਾਂ ਦਾ ਬੰਡਲ ਅਤੇ ਉਸ ਦੀ ਨਕਲ ਨਹੀਂ ਹਨ। ਇੱਕ ਕੁੰਜੀ ਜੋੜੀ ਹੈ ਜਿਸ ਨਾਲ ਪਲੇਟਫਾਰਮ ਦਸਤਖਤ ਕਰ ਸਕਣਾ ਚਾਹੀਦਾ ਹੈ, ਦੂਜੀ ਉਹ ਭਰੋਸਾ ਆਧਾਰ ਹੈ ਜਿਸ ਨਾਲ ਉਹ ਤੁਲਨਾ ਕਰਦਾ ਹੈ। ਇਹਨਾਂ ਨੂੰ ਦੋ ਵੱਖਰੇ ਤੱਥਾਂ ਵਜੋਂ ਜਾਂਚੋ: ਕੀ ਇਹ ਪ੍ਰੋਫਾਈਲ ਦਸਤਖਤ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੀ ਇਹ ਜਾਣਦਾ ਹੈ ਕਿਸ 'ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਹੈ?
ਭਰੋਸਾ ਆਧਾਰ ਐਪ ਦੇ ਹਨ, ਫੋਨ ਦੇ ਨਹੀਂ
ਵਰਤੋਂਕਾਰ ਭੰਡਾਰ ਵਿੱਚ ਮੂਲ ਸਥਾਪਤ ਕਰਨ ਨਾਲ ਹਰ Android ਐਪ ਉਸ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਦੀ: Android 7 ਤੋਂ ਐਪ ਨੂੰ ਆਪਣੀ ਨੈੱਟਵਰਕ ਸੁਰੱਖਿਆ ਸੰਰਚਨਾ ਰਾਹੀਂ ਇਹ ਚੁਣਨਾ ਪੈਂਦਾ ਹੈ, ਅਤੇ ਉਸ ਸੰਸਕਰਣ ਤੋਂ ਪਹਿਲਾਂ ਵਰਤੋਂਕਾਰ ਵੱਲੋਂ ਸਥਾਪਤ CA ਬਹੁਤ ਵੱਧ ਵਿਆਪਕ ਰੂਪ ਵਿੱਚ ਸਵੀਕਾਰ ਕੀਤੇ ਜਾਂਦੇ ਸਨ। ਭਰੋਸਾ ਸੰਰਚਨਾ ਵੱਖਰੀ ਹੋ ਸਕਦੀ ਹੈ, ਅਤੇ ਆਪਣੀ ਭਰੋਸਾ ਸਮੱਗਰੀ ਆਪ ਪ੍ਰਬੰਧ ਕਰਨ ਵਾਲਾ VPN ਕਲਾਇੰਟ ਸ਼ਾਇਦ ਭੰਡਾਰ ਵੱਲ ਕਦੇ ਨਾ ਵੇਖੇ। ਇਸ ਲਈ ਉਹੀ CA ਫਾਈਲ ਇੱਕ ਕਲਾਇੰਟ ਵਿੱਚ ਕੰਮ ਕਰਦੀ ਹੈ ਅਤੇ ਦੂਜੇ ਵਿੱਚ ਅਣਡਿੱਠੀ ਲੱਗਦੀ ਹੈ।
ਇਸ ਤੋਂ ਦੋ ਮਾਲਕੀ ਮਾਡਲ ਆਉਂਦੇ ਹਨ। ਸਿਸਟਮ ਵੱਲੋਂ ਪ੍ਰਬੰਧਿਤ ਪ੍ਰੋਫਾਈਲ ਡਿਵਾਈਸ ਦੀ ਸਰਟੀਫਿਕੇਟ ਸਥਾਪਨਾ ਜਾਂ ਪ੍ਰਸ਼ਾਸਕ ਰਜਿਸਟਰੇਸ਼ਨ ਵਰਤਦਾ ਹੈ ਅਤੇ ਫਿਰ ਲੋੜੀਂਦੇ CA ਦਾ ਹਵਾਲਾ ਦਿੰਦਾ ਹੈ। ਐਪ ਵੱਲੋਂ ਪ੍ਰਬੰਧਿਤ VPN ਆਪਣੀ ਭਰੋਸਾ ਸਮੱਗਰੀ ਅਤੇ ਆਪਣੀ ਦਰਜ ਆਯਾਤ ਰੱਖਦਾ ਹੈ, ਜੋ Android ਸੈਟਿੰਗ ਸਕ੍ਰੀਨ ਤੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰੀ ਹੋ ਸਕਦੀ ਹੈ। ਟੁੱਟੀ ਲੜੀ ਦੀ ਮੁਰੰਮਤ ਵੀ ਉੱਥੇ ਹੀ ਹੁੰਦੀ ਹੈ।
ਕੁਝ ਵੀ ਆਯਾਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਤੁਸੀਂ ਕਿਸ ਮਾਡਲ ਵਿੱਚ ਹੋ, ਫਿਰ ਸਰਗਰਮ ਪ੍ਰੋਫਾਈਲ ਦੀ ਭਰੋਸਾ ਚੋਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਜੇ ਆਪਰੇਟਰ ਦੀਆਂ ਹਦਾਇਤਾਂ ਅਤੇ ਕਲਾਇੰਟ ਦਾ ਮੀਨੂ ਨਾ ਮਿਲਣ, ਤਾਂ ਉਸ ਸਥਾਪਨਾ ਲਈ ਕਲਾਇੰਟ ਦਾ ਦਰਜ ਵਿਵਹਾਰ ਜਿੱਤਦਾ ਹੈ, ਪਰ CA ਫਿਰ ਵੀ ਆਪਰੇਟਰ ਕੋਲੋਂ ਉਸ ਰਾਹੇ ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਜਾਂਚ ਸਕਦੇ ਹੋ। ਫਾਈਲ ਦਾ ਨਾਂ ਇਸ ਦਾ ਸਬੂਤ ਨਹੀਂ ਕਿ ਇਹ ਕਿਸ ਨੇ ਜਾਰੀ ਕੀਤੀ।
ਪਹਿਲਾਂ ਮੋਡ, ਫਿਰ ਫਾਈਲਾਂ
ਸਰਟੀਫਿਕੇਟ ਮੋਡ ਲਈ ਕਲਾਇੰਟ ਦੀ ਕੁੰਜੀ ਜੋੜੀ, ਗੇਟਵੇ ਵਾਲੇ ਪਾਸੇ ਜਾਰੀ ਕਰਨ ਵਾਲਾ CA, ਗੇਟਵੇ ਸਰਟੀਫਿਕੇਟ ਲਈ ਭਰੋਸਾ ਆਧਾਰ ਅਤੇ ਇਸ ਦੀ ਉਮੀਦ ਕਿ ਉਸ ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਕਿਹੜੀ ਪਛਾਣ ਚਾਹੀਦੀ ਹੈ। ਵਰਤੋਂਕਾਰ ਨਾਂ ਅਤੇ ਪਾਸਵਰਡ ਕੁੰਜੀ ਜੋੜੀ ਦੀ ਥਾਂ ਪ੍ਰਮਾਣ-ਪੱਤਰ ਦਿੰਦੇ ਹਨ ਪਰ ਗੇਟਵੇ 'ਤੇ ਭਰੋਸੇ ਦੀ ਸ਼ਰਤ ਬਣਾਈ ਰੱਖਦੇ ਹਨ। PSK ਦੋਵਾਂ ਦੀ ਥਾਂ ਸਾਂਝਾ ਭੇਤ ਦਿੰਦਾ ਹੈ ਅਤੇ ਭਰੋਸਾ ਮਾਡਲ ਨੂੰ ਸਰਲ ਕਰਨ ਦੀ ਥਾਂ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਤੁਸੀਂ ਜੋ ਵੀ ਚੁਣੋ, ਆਮ ਜਾਂਚ ਚਾਲੂ ਰੱਖੋ। ਬਿਨਾਂ ਜਾਂਚ ਵਾਲਾ ਬਦਲ ਉਸ ਜਾਂਚ ਨੂੰ ਹਟਾ ਦਿੰਦਾ ਹੈ ਜਿਸ ਲਈ CA ਖੇਤਰ ਹੈ; ਗੁੰਮ ਭਰੋਸਾ ਆਧਾਰ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰਦਾ। ਇਹੀ ਗੱਲ ਕਿਸੇ ਵੀ ਸਰਵਰ ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਇਸ ਲਈ ਸਵੀਕਾਰ ਕਰਨ 'ਤੇ ਲਾਗੂ ਹੁੰਦੀ ਹੈ ਕਿ ਕਨੈਕਸ਼ਨ ਉਸ ਤੋਂ ਬਿਨਾਂ ਵੀ ਚੱਲਦਾ ਹੈ।
ਫਿਰ ਸਹੀ ਥਾਂ 'ਤੇ ਜਾਂਚੋ: ਸਮੱਗਰੀ ਆਯਾਤ ਕਰੋ, ਇੱਕ ਵਾਰ ਜੁੜੋ, ਅਤੇ ਕਨੈਕਸ਼ਨ ਵੇਰਵਿਆਂ ਵਿੱਚ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਗੇਟਵੇ ਦੀ ਪਛਾਣ ਉਹੀ ਹੈ ਜਿਸ ਦੀ ਤੁਸੀਂ ਉਮੀਦ ਕੀਤੀ ਸੀ ਅਤੇ ਪ੍ਰੋਫਾਈਲ ਉਹੀ ਢੰਗ ਦੱਸਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਸੀ। ਗਲਤ ਢੰਗ ਨਾਲ ਸਫਲ ਕਨੈਕਸ਼ਨ ਉਹ ਸੰਰਚਨਾ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਅਜੇ ਨਹੀਂ ਸਮਝਦੇ, ਅਤੇ ਆਪਰੇਟਰ ਵੱਲੋਂ ਨੀਤੀ ਸਖ਼ਤ ਕਰਨ 'ਤੇ ਇਹ ਅਸਫਲ ਹੋਵੇਗਾ।