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

ਮਿੱਥ: ਸਪਲਿਟ ਟਨਲਿੰਗ ਇੱਕ ਸਮਝੌਤਾ ਹੈ

ਮਿੱਥ ਟਿਕੀ ਰਹਿੰਦੀ ਹੈ ਕਿਉਂਕਿ ਪੂਰਾ ਟਨਲ ਇੱਕ ਵਾਰ ਸੈੱਟ ਕਰਨਾ ਸੌਖਾ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਡੀਬੱਗ ਕਰਨਾ ਔਖਾ ਹੈ। ਇਹ ਸੌਦਾ ਜਨਤਕ Wi-Fi ’ਤੇ ਲੈਪਟਾਪ ਲਈ ਵਾਜਬ ਅਤੇ ਤਹਿਖਾਨੇ ਦੇ ਰੈਕ ਲਈ ਗਲਤ ਹੈ।

ਇਹ ਦੂਜੀ ਧਾਰਨਾ ਵੀ ਲੁਕਾਉਂਦਾ ਹੈ: ਲੈਬ ਦੀ ਐਡਰੈਸਿੰਗ ਦਾ ਉਸ ਨੈੱਟਵਰਕ ਨਾਲ ਕੋਈ ਸਾਂਝ ਨਹੀਂ ਜਿਸ ਤੋਂ ਤੁਸੀਂ ਜੁੜਦੇ ਹੋ।

ਰੂਟਾਂ ਤੋਂ ਪਹਿਲਾਂ ਸਰੋਤਾਂ ਦੀ ਸੂਚੀ ਬਣਾਓ

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

ਹਰ ਸਰੋਤ ਨੂੰ ਇੱਕ ਰਾਹ ਦਿਓ: ਟਨਲ ਰਾਹੀਂ, ਸਿੱਧਾ ਜਾਂ ਇਨਕਾਰ ਕੀਤਾ। ਰਾਹ ਨਾ ਦਿੱਤਾ ਸਰੋਤ ਹੀ ਬਾਅਦ ਵਿੱਚ ਉਲਝਣ ਭਰੀ ਸਹਾਇਤਾ ਬੇਨਤੀ ਪੈਦਾ ਕਰਦਾ ਹੈ।

ਪੰਜ ਕਤਾਰਾਂ ਅਤੇ ਫੈਸਲਿਆਂ ਦਾ ਇੱਕ ਕਾਲਮ ਉਸ ਰੂਟ ਟੇਬਲ ਤੋਂ ਬਿਹਤਰ ਹੈ ਜਿਸ ਨੂੰ ਕੋਈ ਪੜ੍ਹ ਨਹੀਂ ਸਕਦਾ।

ਗੇਟਵੇ ਨੂੰ ਵਾਪਸੀ ਰਾਹ ਚਾਹੀਦਾ ਹੈ

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

ਲੈਬ ਦੀ ਆਪਣੀ ਐਡਰੈਸਿੰਗ ਨਾਲ ਓਵਰਲੈਪ ਕਰਨ ਵਾਲਾ ਕਲਾਇੰਟ ਪੂਲ ਇਸ ਸਮੱਸਿਆ ਦਾ ਦੂਜਾ ਅੱਧਾ ਹੈ, ਅਤੇ ਇਹ ਬਿਲਕੁਲ ਉਸੇ ਤਰ੍ਹਾਂ ਅਸਫਲ ਹੁੰਦਾ ਹੈ।

ਦੋਵੇਂ ਰੇਂਜ ਟਕਰਾਉਣ ’ਤੇ ਲੱਛਣ ਨਹੀਂ, ਯੋਜਨਾ ਸੁਧਾਰੋ।

ਪ੍ਰਬੰਧਨ ਅਤੇ ਇੰਟਰਨੈੱਟ ਦੀਆਂ ਭੂਮਿਕਾਵਾਂ ਵੱਖਰੀਆਂ ਹਨ

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

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

ਇਨ੍ਹਾਂ ਨੂੰ ਵੱਖਰਾ ਰੱਖਣਾ ਹੀ ਬਾਅਦ ਵਿੱਚ ਅਸਫਲਤਾ ਦੇ ਤਰੀਕਿਆਂ ਨੂੰ ਵੱਖਰਿਆਉਣ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।

LAN ਤੋਂ ਨਹੀਂ, ਬਾਹਰੋਂ ਟੈਸਟ ਕਰੋ

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

ਫਿਰ ਰੂਟ ਅਤੇ DNS ਕਨਫਿਗਰੇਸ਼ਨ ਸੂਚੀ ਦੇ ਕੋਲ ਸੰਭਾਲੋ, ਮਾਲਕ ਦੇ ਨਾਂ ਨਾਲ। ਜਦੋਂ ਲੈਬ ਨੂੰ ਹੋਰ ਸਬਨੈੱਟ ਮਿਲੇ, ਦੋਵੇਂ ਅੱਪਡੇਟ ਕਰੋ ਅਤੇ ਫਿਰ ਟੈਸਟ ਕਰੋ।

ਮੌਜੂਦਾ ਘਰ ਦੇ ਨੈੱਟਵਰਕ ਨਾਲ ਓਵਰਲੈਪ ਕਰਨ ਵਾਲਾ ਅਸਪਸ਼ਟ ਰੂਟ ਉਸ ਕਦਮ ਨੂੰ ਛੱਡਣ ਦਾ ਡਿਫਾਲਟ ਨਤੀਜਾ ਹੈ।

ਤਿਆਰ ਡਿਜ਼ਾਈਨ ਛੋਟਾ, ਦਸਤਾਵੇਜ਼ੀ ਅਤੇ ਉਬਾਊ ਹੈ, ਅਤੇ ਲੈਬ ਆਪਣੇ ਨੈੱਟਵਰਕ ਤੋਂ ਬਿਲਕੁਲ ਇਹੀ ਚਾਹੁੰਦੀ ਹੈ। ਦਿਲਚਸਪ ਸੰਸਕਰਣ ਉਹ ਹੈ ਜੋ ਤੁਸੀਂ ਘਰੋਂ ਦੂਰ ਹੁੰਦੇ ਹੋਏ ਟੁੱਟਦਾ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ