ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ VPN ਉੱਤੇ ਸਟੈਟਿਕ ਰੂਟ ਜਾਂ ਰਾਊਟਿੰਗ ਪ੍ਰੋਟੋਕੋਲ?
ਪ੍ਰੀਫ਼ਿਕਸ ਦਾ ਬਦਲਾਅ, ਫੇਲਓਵਰ ਵਿਵਹਾਰ ਅਤੇ ਸੰਚਾਲਨ ਸਮਰੱਥਾ ਇਹ ਤੈਅ ਕਰਦੇ ਹਨ। ਹਰ ਵਿਕਲਪ ਨੂੰ ਸਹੀ ਰੱਖਣ ਦਾ ਖ਼ਰਚਾ ਤੋਲੋ, ਫਿਰ ਨਾਕਾਮੀ ਦਾ ਰਾਹ ਜਾਂਚੋ।
ਦੋਵੇਂ ਵਿਕਲਪ ਸਾਈਟਾਂ ਵਿਚਕਾਰ ਪੈਕਟ ਲੈ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਫ਼ੈਸਲਾ ਇਸ ਗੱਲ ਦਾ ਨਹੀਂ ਕਿ ਕਿਹੜਾ ਪ੍ਰੋਟੋਕੋਲ ਨਵਾਂ ਹੈ, ਅਤੇ ਟਨਲ ਦਾ ਆਕਾਰ ਵੀ ਇਹ ਤੈਅ ਨਹੀਂ ਕਰਦਾ। ਤਿੰਨ ਸ਼ਰਤਾਂ ਇਹ ਤੈਅ ਕਰਦੀਆਂ ਹਨ: ਕਿੰਨੇ ਪ੍ਰੀਫ਼ਿਕਸ ਬਦਲਦੇ ਹਨ ਅਤੇ ਕਿੰਨੀ ਵਾਰ, ਕੀ ਡਿਜ਼ਾਈਨ ਨੂੰ ਰਾਹਾਂ ਵਿਚਕਾਰ ਆਪਣੇ-ਆਪ ਫੇਲਓਵਰ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਟੀਮ ਰਾਤ ਤਿੰਨ ਵਜੇ ਕਿੰਨੀ ਕੰਟਰੋਲ-ਪਰਤ ਮਸ਼ੀਨਰੀ ਚਲਾ ਸਕਦੀ ਹੈ। ਇਹਨਾਂ ਦਾ ਇਮਾਨਦਾਰ ਜਵਾਬ ਦਿਓ ਅਤੇ ਚੋਣ ਆਮ ਤੌਰ ਤੇ ਆਪਣੇ ਆਪ ਹੋ ਜਾਂਦੀ ਹੈ। ਇਸ ਲੇਖ ਦਾ ਬਾਕੀ ਹਿੱਸਾ ਹਰ ਜਵਾਬ ਦੀ ਕੀਮਤ ਹੈ।
ਤਿੰਨ ਸ਼ਰਤਾਂ ਇਹ ਤੈਅ ਕਰਦੀਆਂ ਹਨ
ਪਹਿਲੀ ਸ਼ਰਤ ਬਦਲਾਅ ਹੈ। ਸਪਸ਼ਟ ਮਾਲਕੀ ਵਾਲੇ ਕੁਝ ਸਥਿਰ ਸਬਨੈੱਟ ਸਾਲਾਂ ਤੱਕ ਹੱਥ ਨਾਲ ਸੰਭਾਲੇ ਜਾ ਸਕਦੇ ਹਨ, ਅਤੇ ਹਰ ਰੂਟ ਉਹ ਲਾਈਨ ਰਹਿੰਦਾ ਹੈ ਜਿਸ ਨੂੰ ਕੋਈ ਪੜ੍ਹ ਕੇ ਜਾਂਚ ਸਕਦਾ ਹੈ। ਪ੍ਰੋਜੈਕਟਾਂ ਦੇ ਆਉਣ-ਜਾਣ ਨਾਲ ਹਿੱਲਣ ਵਾਲੇ ਦਰਜਨਾਂ ਪ੍ਰੀਫ਼ਿਕਸ ਵੱਖਰੀ ਸਮੱਸਿਆ ਹਨ, ਕਿਉਂਕਿ ਹਰ ਹਿੱਲਣ ਨੂੰ ਉਸ ਹਰ ਡਿਵਾਈਸ ਤੱਕ ਪਹੁੰਚਣਾ ਹੈ ਜੋ ਅਜੇ ਵੀ ਪੁਰਾਣਾ ਰਾਹ ਯਾਦ ਰੱਖਦੀ ਹੈ।
ਦੂਜੀ ਸ਼ਰਤ ਨਾਕਾਮੀ ਦਾ ਵਿਵਹਾਰ ਹੈ। ਜਦੋਂ ਬੈਕਅਪ ਰਾਹ ਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਇਨਸਾਨ ਦੇ ਧਿਆਨ ਦੇ ਸਰਗਰਮ ਹੋਣਾ ਹੋਵੇ, ਤਾਂ ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਨਾਕਾਮੀ ਪਛਾਣ ਕੇ ਰੂਟ ਵਾਪਸ ਖਿੱਚਣਾ ਪਵੇਗਾ। ਸਟੈਟਿਕ ਰਾਊਟਿੰਗ ਇਹ ਸਿਰਫ਼ ਟ੍ਰੈਕਿੰਗ ਜਾਂ ਸ਼ਰਤੀ ਇੰਸਟਾਲੇਸ਼ਨ ਰਾਹੀਂ ਕਰ ਸਕਦੀ ਹੈ, ਅਤੇ ਸਿਰਫ਼ ਉਹਨਾਂ ਨਾਕਾਮੀਆਂ ਲਈ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਸੋਚੀਆਂ ਹਨ।
ਤੀਸਰੀ ਸ਼ਰਤ ਦੂਜੀ ਕੰਟਰੋਲ ਪਰਤ ਦੀ ਭੁੱਖ ਹੈ। ਰਾਊਟਿੰਗ ਪ੍ਰੋਟੋਕੋਲ ਸੈਸ਼ਨ, ਪ੍ਰਮਾਣੀਕਰਨ, ਫਿਲਟਰ ਅਤੇ ਚੋਣ ਨੀਤੀ ਜੋੜਦਾ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਨੂੰ ਨਿਗਰਾਨੀ ਅਤੇ ਬਦਲਾਅ ਪ੍ਰਕਿਰਿਆ ਚਾਹੀਦੀ ਹੈ। ਇਹ ਸਥਾਈ ਸੰਚਾਲਨ ਖ਼ਰਚਾ ਹੈ, ਇੱਕ ਵਾਰ ਦਾ ਕੌਨਫਿਗਰੇਸ਼ਨ ਕੰਮ ਨਹੀਂ।
| Condition | Points to static | Points to dynamic |
|---|---|---|
| Prefix churn | Rare, few, stable | Frequent, many, moving |
| Failover | Manual or tracked | Automatic withdrawal |
| Operations | No routing staff | Protocol monitoring exists |
ਤੀਸਰੇ ਪੈਰੇ ਹੇਠਾਂ ਦਿੱਤੀ ਸਾਰਣੀ ਛੋਟਾ ਸੰਸਕਰਣ ਹੈ, ਅਤੇ ਇਸ ਤੋਂ ਬਾਅਦ ਦੇ ਤਿੰਨ ਹਿੱਸੇ ਦੱਸਦੇ ਹਨ ਕਿ ਹਰ ਕਤਾਰ ਆਪਣੀ ਥਾਂ ਤੇ ਕਿਉਂ ਹੈ। ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ ਕਤਾਰਾਂ ਨੂੰ ਆਪਣੀ ਸਾਈਟ ਗਿਣਤੀ ਨਾਲ ਮਿਲਾ ਕੇ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਸੰਚਾਲਨ ਖ਼ਰਚੇ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨ ਵਾਲਾ ਫ਼ੈਸਲਾ ਅੱਧਾ ਫ਼ੈਸਲਾ ਹੈ।
ਸਟੈਟਿਕ ਰਾਊਟਿੰਗ ਅਸਲ ਵਿੱਚ ਕੀ ਖ਼ਰਚ ਕਰਦੀ ਹੈ
ਸਟੈਟਿਕ ਰੂਟ ਟਨਲ ਦੇ ਦੋਵੇਂ ਪਾਸੇ ਸਹੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਬਨੈੱਟ ਜੋੜਨ ਦਾ ਮਤਲਬ ਦੂਰ ਦਾ ਗੇਟਵੇ, ਸਥਾਨਕ ਗੇਟਵੇ ਅਤੇ ਆਮ ਤੌਰ ਤੇ ਵਾਪਸੀ ਰਾਹ ਸੋਧਣਾ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਭੁੱਲਣ ਨਾਲ ਇੱਕਤਰਫ਼ਾ ਨਾਕਾਮੀ ਹੁੰਦੀ ਹੈ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਬੱਗ ਵਰਗੀ ਲੱਗਦੀ ਹੈ। ਐਪਲੀਕੇਸ਼ਨ ਟੀਮ ਨੂੰ ਸਮਾਂ ਸਮਾਪਤੀ ਦਿਖਦੀ ਹੈ, ਜਦੋਂ ਕਿ ਨੈੱਟਵਰਕ ਟੀਮ ਨੂੰ ਮੌਜੂਦ ਅਤੇ ਦਿੱਖ ਵਿੱਚ ਤੰਦਰੁਸਤ ਰੂਟ ਦਿਖਦਾ ਹੈ। ਕੋਈ ਟੀਮ ਗ਼ਲਤ ਨਹੀਂ, ਅਤੇ ਇਸੇ ਲਈ ਇਸ ਨਾਕਾਮੀ ਦੀ ਥਾਂ ਲੱਭਣ ਵਿੱਚ ਇੰਨਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ।
ਸਟੈਟਿਕ ਐਂਟਰੀ ਹੇਠਾਂ ਦਾ ਰਾਹ ਗ਼ਾਇਬ ਹੋਣ ਤੋਂ ਬਾਅਦ ਵੀ ਸਥਾਪਿਤ ਰਹਿੰਦੀ ਹੈ। ਜੇ ਪਲੇਟਫਾਰਮ ਟ੍ਰੈਕਿੰਗ ਨਹੀਂ ਦਿੰਦਾ, ਤਾਂ ਰੂਟ ਉਸ ਅਗਲੇ ਹੌਪ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ ਜੋ ਹੁਣ ਅੱਗੇ ਨਹੀਂ ਭੇਜਦਾ, ਅਤੇ ਟ੍ਰੈਫ਼ਿਕ ਫੇਲਓਵਰ ਹੋਣ ਦੀ ਬਜਾਏ ਗ਼ਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ। ਉਹ ਚੁੱਪ ਹੀ ਉਹ ਖ਼ਰਚਾ ਹੈ ਜੋ ਤੁਸੀਂ ਸਧਾਰਨ ਵਿਕਲਪ ਚੁਣਦੇ ਸਮੇਂ ਸਵੀਕਾਰ ਕਰਦੇ ਹੋ।
ਹਰ ਰੂਟ ਦੇ ਕੋਲ ਟ੍ਰੈਕਿੰਗ ਢੰਗ ਲਿਖੋ, ਇਹ ਕਿਹੜੀਆਂ ਨਾਕਾਮੀਆਂ ਢਕਦਾ ਹੈ ਨੋਟ ਕਰੋ, ਅਤੇ ਸੂਚੀ ਟਨਲ ਕੌਨਫਿਗਰੇਸ਼ਨ ਨਾਲ ਰੱਖੋ। ਨਹੀਂ ਤਾਂ ਅਗਲੀ ਰੁਕਾਵਟ ਨੈੱਟਵਰਕ ਨਹੀਂ ਬਲਕਿ ਵਰਤੋਂਕਾਰ ਲੱਭੇਗਾ, ਅਤੇ ਉਹ ਹਮੇਸ਼ਾ ਵੱਧ ਮਹਿੰਗੀ ਖੋਜ ਹੁੰਦੀ ਹੈ।
ਡਾਇਨਾਮਿਕ ਰਾਊਟਿੰਗ ਅਸਲ ਵਿੱਚ ਕੀ ਖ਼ਰਚ ਕਰਦੀ ਹੈ
ਪ੍ਰੋਟੋਕੋਲ ਨਵੇਂ ਪ੍ਰੀਫ਼ਿਕਸ ਦਾ ਐਲਾਨ ਕਰਦਾ ਹੈ, ਨਾ-ਪਹੁੰਚ ਵਾਲੇ ਵਾਪਸ ਲੈਂਦਾ ਹੈ ਅਤੇ ਰਾਹਾਂ ਵਿਚਕਾਰ ਤਰਜੀਹ ਜ਼ਾਹਰ ਕਰਦਾ ਹੈ। ਕਈ ਸਾਈਟਾਂ ਜਾਂ ਵਾਧੂ ਟਨਲਾਂ ਨੂੰ ਹਰ ਬਦਲਾਅ ਤੇ ਤਾਲਮੇਲ ਵਾਲੀ ਸੋਧ ਚਾਹੀਦੀ ਹੋਵੇ ਤਾਂ ਇਹ ਸੱਚਮੁੱਚ ਲਾਹੇਵੰਦ ਹੈ। ਇਹ ਵੀ ਉਹੀ ਕਾਰਨ ਹੈ ਕਿ ਪ੍ਰੋਟੋਕੋਲ ਤੁਹਾਨੂੰ ਸਭ ਤੋਂ ਮਾੜੇ ਪਲ ਹੈਰਾਨ ਕਰ ਸਕਦਾ ਹੈ। ਉਹਨਾਂ ਕੰਮਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਅਜਿਹਾ ਹਾਲਤ ਬਦਲਾਅ ਹੈ ਜੋ ਤੁਸੀਂ ਆਪ ਨਹੀਂ ਕੀਤਾ।
ਇਹ ਦੋ ਹਾਲਤਾਂ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਅਸਹਿਮਤ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਟਨਲ ਉੱਪਰ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਰਾਊਟਿੰਗ ਸੈਸ਼ਨ ਹੇਠਾਂ ਹੋਵੇ, ਅਤੇ ਸੈਸ਼ਨ ਉੱਪਰ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਇਸ ਦੇ ਐਲਾਨ ਉਹ ਸਬਨੈੱਟ ਛੱਡ ਦੇਣ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਚਾਹੀਦਾ ਹੈ। ਦੋਵੇਂ ਅੱਧਾ ਕੰਮ ਕਰਦੇ ਨੈੱਟਵਰਕ ਵਰਗੇ ਲੱਗਦੇ ਹਨ, ਅਤੇ ਕੋਈ ਵੀ ਟਨਲ ਸਥਿਤੀ ਸਫ਼ੇ ਤੋਂ ਦਿਖਦਾ ਨਹੀਂ।
ਇਸ ਲਈ ਫਿਲਟਰ ਅਤੇ ਨੀਤੀ ਬਾਅਦ ਦੀ ਸੋਚ ਨਹੀਂ ਬਲਕਿ ਡਿਜ਼ਾਈਨ ਦਾ ਹਿੱਸਾ ਬਣਦੇ ਹਨ। ਜੋ ਪ੍ਰੋਟੋਕੋਲ ਸਭ ਕੁਝ ਐਲਾਨਦਾ ਹੈ ਉਹ ਅੰਤ ਵਿੱਚ ਕੁਝ ਗ਼ਲਤ ਐਲਾਨੇਗਾ, ਅਤੇ ਗ਼ਲਤ ਪ੍ਰੀਫ਼ਿਕਸ ਉਸ ਵਿਅਕਤੀ ਨਾਲੋਂ ਤੇਜ਼ ਚੱਲਦਾ ਹੈ ਜੋ ਇਸਨੂੰ ਸੁਧਾਰ ਸਕਦਾ ਹੈ। ਪਹਿਲਾ ਸੈਸ਼ਨ ਸਮਰੱਥ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਫਿਲਟਰ ਲਿਖੋ, ਤਾਂ ਜੋ ਪਹਿਲਾ ਐਲਾਨ ਪਹਿਲਾਂ ਹੀ ਜਾਣ-ਬੁੱਝ ਕੇ ਹੋਵੇ।
ਰਾਊਟਿੰਗ ਸੈਸ਼ਨ ਕੀ ਕਹਿ ਸਕਦਾ ਹੈ ਇਸਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰੋ
ਹਰ ਪੀਅਰ ਲਈ ਮਨਜ਼ੂਰ ਪ੍ਰੀਫ਼ਿਕਸ ਸੂਚੀ ਤੈਅ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਆਮਦ ਤੇ ਲਾਗੂ ਕਰੋ, ਕਿਉਂਕਿ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਫਿਲਟਰ ਪੀਅਰ ਨੂੰ ਤੁਹਾਨੂੰ ਡਿਫ਼ਾਲਟ ਰੂਟ ਭੇਜਣ ਤੋਂ ਨਹੀਂ ਰੋਕ ਸਕਦਾ। ਡਿਫ਼ਾਲਟ ਰੂਟ ਅਤੇ ਸਮੂਹ ਇੱਥੇ ਮਹਿੰਗੀਆਂ ਗ਼ਲਤੀਆਂ ਹਨ: ਉਹ ਕਾਨੂੰਨੀ ਦਿਖਣ ਵਾਲੀ ਇੱਕ ਸਿੱਖੀ ਐਂਟਰੀ ਨਾਲ ਅਸੰਬੰਧਿਤ ਰਾਹ ਚੁੱਪਚਾਪ ਬਦਲ ਸਕਦੇ ਹਨ। ਜੇ ਡਿਜ਼ਾਈਨ ਸੱਚਮੁੱਚ ਨਹੀਂ ਚਾਹੁੰਦਾ ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਸਪਸ਼ਟ ਤੌਰ ਤੇ ਰੱਦ ਕਰੋ।
ਪਹਿਲਾ ਸੈਸ਼ਨ ਉੱਠਣ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਨੈੱਟਵਰਕ ਦੇ ਕੋਲ ਮਾਲਕ ਸਾਈਟ ਲਿਖੋ, ਕਿਉਂਕਿ ਉਹ ਮੈਪਿੰਗ ਫਿਲਟਰ ਸੂਚੀ ਦਾ ਸਰੋਤ ਹੈ, ਦਸਤਾਵੇਜ਼ ਦੀ ਸਜਾਵਟ ਨਹੀਂ। ਇਸ ਤੋਂ ਬਿਨਾਂ ਫਿਲਟਰ ਸੋਧਣ ਵਾਲੇ ਨੂੰ ਅੰਦਾਜ਼ਾ ਲਾਉਣਾ ਪੈਂਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਸਾਈਟ ਪ੍ਰੀਫ਼ਿਕਸ ਦਾ ਐਲਾਨ ਕਰੇ।
ਦੋ ਪ੍ਰੋਟੋਕੋਲਾਂ ਵਿਚਕਾਰ ਮੁੜ-ਵੰਡ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਲੂਪ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਜਿੱਥੇ ਉਹੀ ਪ੍ਰੀਫ਼ਿਕਸ ਦੋ ਵਾਰ ਉਹਨਾਂ ਗੁਣਾਂ ਨਾਲ ਆਉਂਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਤੁਲਨਾ ਸਾਫ਼ ਨਹੀਂ ਹੁੰਦੀ। ਜਦੋਂ ਤੱਕ ਕੋਈ ਖ਼ਾਸ ਲੋੜ ਮਜਬੂਰ ਨਾ ਕਰੇ, ਮੁੜ-ਵੰਡ ਨੂੰ ਡਿਜ਼ਾਈਨ ਤੋਂ ਬਾਹਰ ਰੱਖੋ, ਅਤੇ ਜੇ ਹੋਣਾ ਹੀ ਹੈ ਤਾਂ ਸੀਮਾ ਤੇ ਰੂਟ ਨਿਸ਼ਾਨਬੱਧ ਕਰਕੇ ਫਿਲਟਰ ਕਰੋ।
ਰੂਟ-ਆਧਾਰਿਤ ਟਨਲ ਇੰਟਰਫ਼ੇਸ ਡਾਇਨਾਮਿਕ ਰਾਊਟਿੰਗ ਨੂੰ ਦਰਸਾਉਣਾ ਸੌਖਾ ਬਣਾਉਂਦੇ ਹਨ, ਕਿਉਂਕਿ ਟਨਲ ਚੋਣਕਾਰਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਨੀਤੀ ਦੀ ਬਜਾਏ ਰੂਟਾਂ ਵਾਲਾ ਇੰਟਰਫ਼ੇਸ ਬਣ ਜਾਂਦਾ ਹੈ। ਇਹ ਪੀਅਰ ਘੇਰੇ ਦਾ ਸਵਾਲ ਨਹੀਂ ਹਟਾਉਂਦਾ: IPsec ਚੋਣਕਾਰਾਂ ਨੂੰ ਅਜੇ ਵੀ ਉਹ ਟ੍ਰੈਫ਼ਿਕ ਮਨਜ਼ੂਰ ਕਰਨਾ ਪਵੇਗਾ ਜੋ ਤੁਸੀਂ ਰਾਊਟ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ।
ਨਾਕਾਮੀ ਦਾ ਰਾਹ ਜਾਂਚੋ, ਖ਼ੁਸ਼ੀ ਦਾ ਰਾਹ ਨਹੀਂ
ਤੁਸੀਂ ਜੋ ਵੀ ਚੁਣੋ, ਇੱਕ ਅਪਲਿੰਕ ਹੇਠਾਂ ਲਾਹੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਟ੍ਰੈਫ਼ਿਕ ਹਿੱਲਦਾ ਹੈ, ਜਾਂ ਜਿਵੇਂ ਤੁਸੀਂ ਦਸਤਾਵੇਜ਼ ਕੀਤਾ ਉਸ ਤਰ੍ਹਾਂ ਨਾਕਾਮ ਹੁੰਦਾ ਹੈ। ਜੋ ਡਿਜ਼ਾਈਨ ਸਿਰਫ਼ ਦੋਵੇਂ ਰਾਹ ਤੰਦਰੁਸਤ ਹੋਣ ਤੇ ਜਾਂਚਿਆ ਗਿਆ ਹੈ ਉਹ ਬਿਲਕੁਲ ਨਾ ਜਾਂਚਿਆ ਡਿਜ਼ਾਈਨ ਹੈ। ਉੱਥੇ ਹੁੰਦਿਆਂ ਪਛਾਣ ਸਮਾਂ ਮਾਪੋ, ਕਿਉਂਕਿ ਤੁਸੀਂ ਜੋ ਸੰਖਿਆ ਮਾਪੀ ਉਹੀ ਸੰਖਿਆ ਵਰਤੋਂਕਾਰ ਭੋਗਣਗੇ।
ਫਿਰ ਵਾਪਸੀ ਰਾਹ ਦੀ ਸੁਤੰਤਰ ਪੁਸ਼ਟੀ ਕਰੋ, ਕਿਉਂਕਿ VPN ਉੱਤੇ ਅਸਮਮਿਤ ਰਾਊਟਿੰਗ ਆਮ ਹੈ ਅਤੇ ਅਦਿੱਖ ਰਹਿੰਦੀ ਹੈ ਜਦੋਂ ਤੱਕ ਕੋਈ ਹਾਲਤ-ਸੰਗ੍ਰਾਹਕ ਡਿਵਾਈਸ ਜਵਾਬ ਨਾ ਟਿਕਾ ਦੇਵੇ। ਇੱਕ ਦਿਸ਼ਾ ਵਿੱਚ ਚੱਲਣ ਵਾਲਾ ਪ੍ਰਵਾਹ ਰਾਹ ਦਾ ਸਿਰਫ਼ ਅੱਧਾ ਹਿੱਸਾ ਸਾਬਤ ਕਰਦਾ ਹੈ।
ਕੰਮ ਦਾ ਕ੍ਰਮ: ਪ੍ਰੀਫ਼ਿਕਸ ਗਿਣੋ, ਨਾਕਾਮੀਆਂ ਕਿਵੇਂ ਪਛਾਣੀਆਂ ਜਾਣ ਇਹ ਤੈਅ ਕਰੋ, ਕੌਣ ਪ੍ਰੋਟੋਕੋਲ ਚਲਾ ਸਕਦਾ ਹੈ ਜਾਂਚੋ, ਕੀ ਐਲਾਨ ਹੁੰਦਾ ਹੈ ਨਿਯੰਤਰਿਤ ਕਰੋ, ਅਤੇ ਫਿਰ ਇੱਕ ਰੁਕਾਵਟ ਸ਼ੁਰੂ ਤੋਂ ਅੰਤ ਤੱਕ ਜਾਂਚੋ। ਹਰ ਕਦਮ ਅਗਲੇ ਕਦਮ ਨੂੰ ਲੋੜੀਂਦਾ ਤੱਥ ਦਿੰਦਾ ਹੈ।