NAT ਰਾਹੀਂ L2TP/IPsec: ਅਸਲ ਵਿੱਚ ਕੀ ਟੁੱਟਦਾ ਹੈ ਅਤੇ ਕਿਉਂ

NAT L2TP/IPsec ਤੋੜਦਾ ਹੈ ਇਹ ਦਾਅਵਾ ਅੱਧਾ ਸੱਚ ਹੈ ਅਤੇ ਇਸ ਲਈ ਬੇਕਾਰ ਹੈ। ਪਤੇ ਦਾ ਅਨੁਵਾਦ ਆਮ ਗੱਲ ਹੈ, NAT ਟਰੈਵਰਸਲ ਠੀਕ ਇਸੇ ਤੋਂ ਬਚਣ ਲਈ ਹੈ, ਅਤੇ ਹਰ ਰੋਜ਼ ਲੱਖਾਂ ਕਲਾਇੰਟ ਰਾਊਟਰ ਪਿੱਛੋਂ ਜੁੜਦੇ ਹਨ। ਜੋ ਟੁੱਟਦਾ ਹੈ ਉਹ ਇੱਕ ਖ਼ਾਸ ਅਦਲਾ-ਬਦਲੀ ਦਾ ਇੱਕ ਖ਼ਾਸ ਪੜਾਅ ਹੈ: IKE ਨੂੰ ਕਦੇ ਜਵਾਬ ਨਹੀਂ ਮਿਲਦਾ, ਸਿਰਫ਼ ਇੱਕ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਵਾਲੀ ਨੀਤੀ ਐਨਕੈਪਸੁਲੇਟਿਡ ਟਨਲ ਨੂੰ ਸੁੱਟ ਦਿੰਦੀ ਹੈ, ਜਾਂ ਟਨਲ ਵਿਹਲਾ ਹੋਣ ਵੇਲੇ ਮੈਪਿੰਗ ਖ਼ਤਮ ਹੋ ਜਾਂਦੀ ਹੈ। ਇੱਕ ਵਾਰ ਜਾਣ ਜਾਣੋ ਕਿ ਤੁਸੀਂ ਕਿਹੜੇ ਪੜਾਅ ਉੱਤੇ ਹੋ, ਹੱਲ ਆਮ ਤੌਰ ਉੱਤੇ ਇੱਕ ਨਿਯਮ ਜਾਂ keepalive ਹੁੰਦਾ ਹੈ, ਨਵਾਂ VPN ਡਿਜ਼ਾਈਨ ਨਹੀਂ।

ਮਿੱਥ ਹੀ ਗ਼ਲਤ ਸਵਾਲ ਹੈ

ਲਾਭਦਾਇਕ ਸਵਾਲ ਇਹ ਨਹੀਂ ਕਿ “ਕੀ NAT ਇਸ ਨੂੰ ਤੋੜਦਾ ਹੈ”, ਸਗੋਂ ਇਹ ਹੈ ਕਿ “ਅਦਲਾ-ਬਦਲੀ ਦਾ ਕਿਹੜਾ ਹਿੱਸਾ ਅਨੁਵਾਦ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਅਨੁਵਾਦ ਕਰਨ ਵਾਲਾ ਯੰਤਰ ਇਸ ਨਾਲ ਕੀ ਕਰਦਾ ਹੈ”। L2TP/IPsec ਪਰਤਾਂ ਵਾਲਾ ਪ੍ਰੋਟੋਕੋਲ ਹੈ: IKE ਗੱਲਬਾਤ ਕਰਦਾ ਹੈ, ESP ਸੁਰੱਖਿਆ ਦਿੰਦਾ ਹੈ, ਅਤੇ L2TP ਉਸ ਸੁਰੱਖਿਆ ਅੰਦਰ PPP ਢੋਂਦਾ ਹੈ। ਪਤੇ ਦਾ ਅਨੁਵਾਦ ਹਰ ਪਰਤ ਨਾਲ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਤੀਕਿਰਿਆ ਕਰਦਾ ਹੈ, ਅਤੇ ਗਲਤੀ ਸੰਵਾਦ ਦੀ ਥਾਂ ਗੱਲਬਾਤ ਦਾ ਪੜਾਅ ਦੇਖੋ ਤਾਂ ਫੇਲ ਦੇ ਸੰਕੇਤ ਵੱਖਰੇ ਪਛਾਣੇ ਜਾ ਸਕਦੇ ਹਨ।

ਸਫਲਤਾਪੂਰਵਕ ਵੈੱਬ ਬ੍ਰਾਊਜ਼ ਕਰਨ ਵਾਲਾ ਰਾਊਟਰ ਸਿਰਫ਼ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਸਰੋਤ ਪੋਰਟ ਅਨੁਵਾਦ ਨਾਲ TCP ਕੰਮ ਕਰਦਾ ਹੈ। ਇਹ UDP 500, UDP 4500 ਜਾਂ ਪ੍ਰੋਟੋਕੋਲ 50 ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ, ਅਤੇ ਇਹ ਤੈਨਾਤੀ ਇਨ੍ਹਾਂ ਤਿੰਨਾਂ ਉੱਤੇ ਨਿਰਭਰ ਹੈ।

ਪੜਾਅ 1: IKE ਨੂੰ ਜਵਾਬ ਤਾਂ ਮਿਲਣਾ ਹੀ ਚਾਹੀਦਾ ਹੈ

ਪਹਿਲੀ ਅਦਲਾ-ਬਦਲੀ UDP 500 ਉੱਤੇ ਜਵਾਬ ਦੇਣ ਵਾਲੇ ਕੋਲ ਜਾਂਦੀ ਹੈ। ਜੇ ਕੋਈ ਜਵਾਬ ਵਾਪਸ ਨਾ ਆਵੇ ਤਾਂ ਬਾਕੀ ਕੁਝ ਵੀ ਮਾਅਨੇ ਨਹੀਂ ਰੱਖਦਾ: ਪਹਿਲਾਂ ਤੋਂ ਸਾਂਝੀ ਕੁੰਜੀ, ਪ੍ਰਸਤਾਵ ਅਤੇ ਪ੍ਰਮਾਣ ਪੜ੍ਹੇ ਬਿਨਾਂ ਹੀ ਰਹਿ ਜਾਂਦੇ ਹਨ। ਕਲਾਇੰਟ ਦੇ ਟਾਈਮਆਊਟ ਤੋਂ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਬੇਨਤੀ ਅਤੇ ਜਵਾਬ ਉੱਤੇ ਨਜ਼ਰ ਰੱਖੋ:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

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

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

ਪੜਾਅ 2: ਐਨਕੈਪਸੁਲੇਸ਼ਨ ਫਾਇਰਵਾਲ ਦੀ ਦਿੱਖ ਬਦਲ ਦਿੰਦਾ ਹੈ

ESP ਇੱਕ IP ਪ੍ਰੋਟੋਕੋਲ ਹੈ, TCP ਜਾਂ UDP ਪੋਰਟ ਨਹੀਂ, ਅਤੇ ਆਮ ਪੋਰਟ ਪਤਾ ਅਨੁਵਾਦ ਵਿੱਚ ਦੁਬਾਰਾ ਲਿਖਣ ਲਈ ਪੋਰਟ ਫੀਲਡ ਨਹੀਂ ਹੁੰਦੀ। ਇਸੇ ਲਈ NAT ਟਰੈਵਰਸਲ ਸੁਰੱਖਿਅਤ ਪੇਲੋਡ ਨੂੰ UDP 4500 ਵਿੱਚ ਲੈ ਜਾਂਦਾ ਹੈ: ਐਨਕੈਪਸੁਲੇਸ਼ਨ ਅਨੁਵਾਦ ਕਰਨ ਵਾਲੇ ਯੰਤਰ ਨੂੰ ਉਹ ਦਿੰਦਾ ਹੈ ਜਿਸ ਦਾ ਅਨੁਵਾਦ ਉਹ ਜਾਣਦਾ ਹੈ। ਅਜਿਹਾ ਹੋਣ ਉੱਤੇ, ਸਿਰਫ਼ UDP 500 ਲਈ ਲਿਖਿਆ ਫਾਇਰਵਾਲ ਨਿਯਮ ਗੱਲਬਾਤ ਦੀ ਇਜਾਜ਼ਤ ਦੇ ਕੇ ਟਨਲ ਸੁੱਟ ਦੇਵੇਗਾ, ਜਿਸ ਨਾਲ ਉਹ ਉਲਝਾਉਣ ਵਾਲਾ ਨਤੀਜਾ ਆਉਂਦਾ ਹੈ ਜਿੱਥੇ ਲੌਗ ਸਫਲ ਪੜਾਅ 1 ਅਤੇ ਕੋਈ ਟ੍ਰੈਫਿਕ ਨਹੀਂ ਦਿਖਾਉਂਦਾ।

NAT ਦਾ ਪਤਾ ਲੱਗਣ ਤੋਂ ਬਾਅਦ IKE ਅਦਲਾ-ਬਦਲੀ ਵੀ UDP 4500 ਉੱਤੇ ਜਾ ਸਕਦੀ ਹੈ, ਜੋ ਸਿਰਫ਼ 500 ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਵਾਲਿਆਂ ਨੂੰ ਹੈਰਾਨ ਕਰਦਾ ਹੈ। ਰਾਹ ਉੱਤੇ ਦੋਵੇਂ ਪੋਰਟਾਂ ਨੂੰ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਇਜਾਜ਼ਤ ਦਿਓ, ਅਤੇ ਯਾਦ ਰੱਖੋ ਕਿ ਸਟੇਟਫੁਲ ਫਾਇਰਵਾਲ ਪ੍ਰਵਾਹ ਨੂੰ ਸਿਰਫ਼ ਉਦੋਂ ਤੱਕ ਰੱਖਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਉਹ ਟ੍ਰੈਫਿਕ ਦੇਖਦਾ ਹੈ।

ਪ੍ਰੋਟੋਕੋਲ 50 ਅਨੁਵਾਦ ਰਹਿਤ ਰਾਹਾਂ ਉੱਤੇ ਅਤੇ ਉਹਨਾਂ ਰਾਹਾਂ ਉੱਤੇ ਜਿੱਥੇ ਵਿਚਕਾਰਲਾ ਬਕਸਾ ਇਸ ਦੀ ਇਜਾਜ਼ਤ ਲਈ ਸੰਰਚਿਤ ਹੈ, ਅਜੇ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਜੇ ਤੁਸੀਂ ਹਟਾ ਕੇ ਨਿਦਾਨ ਕਰਦੇ ਹੋ, ਤਾਂ ਨਿਯਮ ਢੇਰ ਵਿੱਚ ਜੋੜਨ ਦੀ ਥਾਂ ਧਾਰਨਾ ਬੰਦ ਕਰੋ: 500, 4500 ਅਤੇ ESP ਦੀ ਇਜਾਜ਼ਤ ਦਿਓ, ਟਨਲ ਉੱਠਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਫਿਰ ਜੋ ਬੇਲੋੜਾ ਨਿਕਲੇ ਉਹ ਹਟਾਓ। ਜਿਸ ਨਿਯਮ ਨੂੰ ਕੋਈ ਸਮਝਾ ਨਾ ਸਕੇ, ਉਹ ਅਜਿਹਾ ਨਿਯਮ ਹੈ ਜਿਸ ਨੂੰ ਅਗਲੀ ਰੁਕਾਵਟ ਦਾ ਕਾਰਨ ਬਣਨ ਉੱਤੇ ਕੋਈ ਨਹੀਂ ਹਟਾਏਗਾ। ਸੰਕੋਚ ਬਦਲਾਅ-ਰਿਕਾਰਡ ਵਿੱਚ ਉਸ ਪੜਾਅ ਨਾਲ ਲਿਖੋ ਜਿਸ ਨੂੰ ਇਸ ਨੇ ਠੀਕ ਕੀਤਾ, ਤਾਂ ਜੋ ਅਗਲਾ ਇੰਜੀਨੀਅਰ ਉਸੇ ਅੰਗੂਠਾ-ਨਿਯਮ ਤੋਂ ਨਹੀਂ, ਤੁਹਾਡੇ ਸਬੂਤਾਂ ਤੋਂ ਸ਼ੁਰੂ ਕਰੇ।

ਪੜਾਅ 3: ਮੈਪਿੰਗ ਖ਼ਤਮ ਹੁੰਦੀ ਹੈ ਅਤੇ ਟਨਲ ਮਰ ਜਾਂਦੀ ਹੈ

ਅਨੁਵਾਦ ਕਰਨ ਵਾਲਾ ਯੰਤਰ ਅੱਗੇ ਭੇਜੇ ਪ੍ਰਵਾਹਾਂ ਲਈ ਸਥਿਤੀ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਉਸ ਸਥਿਤੀ ਦੀ ਉਮਰ ਹੁੰਦੀ ਹੈ। ਜਦੋਂ ਕੋਈ ਵਰਤਦਾ ਨਹੀਂ ਤਾਂ L2TP/IPsec ਟਨਲ ਘੱਟ ਟ੍ਰੈਫਿਕ ਢੋਂਦੀ ਹੈ, ਇਸ ਲਈ ਵਿਹਲੀ ਟਨਲ ਆਪਣੀ ਮੈਪਿੰਗ ਤੋਂ ਵੱਧ ਜੀਅ ਸਕਦੀ ਹੈ ਅਤੇ ਵਾਪਸੀ ਟ੍ਰੈਫਿਕ ਲੈਣਾ ਬੰਦ ਕਰ ਸਕਦੀ ਹੈ। ਕਲਾਇੰਟ ਨੂੰ ਭਰੋਸਾ ਰਹਿੰਦਾ ਹੈ ਕਿ ਉਹ ਜੁੜਿਆ ਹੈ, ਸਰਵਰ ਨੂੰ ਕੁਝ ਨਹੀਂ ਦਿਸਦਾ, ਅਤੇ ਪਹਿਲਾ ਲੱਛਣ ਆਮ ਤੌਰ ਉੱਤੇ VPN ਗਲਤੀ ਨਹੀਂ ਸਗੋਂ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਟਾਈਮਆਊਟ ਹੁੰਦਾ ਹੈ।

ਡੈੱਡ ਪੀਅਰ ਖੋਜ ਅਤੇ NAT keepalive ਇਸੇ ਲਈ ਹਨ, ਅਤੇ ਦੋਵੇਂ ਸਿਰਿਆਂ ਨੂੰ ਇਹ ਭੇਜਣ ਲਈ ਤਿਆਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਸਰਵਰ ਅਨੁਵਾਦ ਪਿੱਛੇ ਹੈ, ਤਾਂ Windows ਪਾਸੇ ਦੀ ਲੋੜ ਇੱਕ ਦਸਤਾਵੇਜ਼ੀ ਰਜਿਸਟਰੀ ਸੈਟਿੰਗ ਹੈ ਜੋ ਸਰਵਰ ਨੂੰ ਆਪਣੇ ਆਉਟਬਾਊਂਡ ਪੈਕਟਾਂ ਲਈ UDP ਐਨਕੈਪਸੁਲੇਸ਼ਨ ਮੰਨਣ ਲਈ ਮਜਬੂਰ ਕਰਦੀ ਹੈ; ਇਸ ਤੋਂ ਬਿਨਾਂ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ESP ਭੇਜਦਾ ਹੈ ਜਿਸ ਨੂੰ ਅਨੁਵਾਦ ਕਰਨ ਵਾਲਾ ਯੰਤਰ ਵਾਪਸ ਮੈਪ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਇਹ ਸਰਵਰ ਸੰਰਚਨਾ ਦਾ ਮਾਮਲਾ ਹੈ, ਕਲਾਇੰਟ ਦਾ ਨਹੀਂ।

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

ਕੈਰੀਅਰ-ਗ੍ਰੇਡ NAT ਪਿੱਛੇ ਹੋਸਟਿੰਗ ਇੱਕ ਵੱਖਰੀ ਸਮੱਸਿਆ ਹੈ

ਜੇ ਤੁਸੀਂ ਘਰ ਵਿੱਚ L2TP/IPsec ਸਰਵਰ ਹੋਸਟ ਕਰਕੇ ਬਾਹਰੋਂ ਉਸ ਤੱਕ ਪਹੁੰਚਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਲੋੜ ਬਿਨਾਂ ਮੰਗੀ ਆਉਣ ਵਾਲੀ ਪਹੁੰਚ ਹੈ, ਅਤੇ NAT ਟਰੈਵਰਸਲ ਇਹ ਨਹੀਂ ਦਿੰਦਾ। ਤੁਹਾਡੇ ਰਾਊਟਰ ਅੱਗੇ ਕੈਰੀਅਰ-ਗ੍ਰੇਡ NAT ਦਾ ਅਰਥ ਹੈ ਕਿ ਕੋਈ ਅਜਿਹਾ ਪੋਰਟ ਨਹੀਂ ਜਿਸ ਨੂੰ ਫਾਰਵਰਡ ਕਰਕੇ ਤੁਸੀਂ ਪਹੁੰਚਯੋਗ ਬਣ ਸਕੋ, ਕਿਉਂਕਿ ਜਨਤਕ ਪਤਾ ਸਾਂਝਾ ਹੈ ਅਤੇ ਮੈਪਿੰਗ ਸਿਰਫ਼ ਬਾਹਰ ਜਾਣ ਵਾਲੀ ਹੈ।

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

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