VPN ਗੇਟਵੇ ਨੂੰ Windows XP ਦੇ ਕੋਲ ਰੱਖੋ, ਇਸਦੇ ਅੰਦਰ ਨਹੀਂ

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

VPN ਕਲਾਇੰਟ ਤੋਂ ਨਹੀਂ, ਹੋਸਟ ਅਡੈਪਟਰ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ

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

C:\> route add 10.20.30.0 mask 255.255.255.0 192.168.50.1 -p

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

ਟਨਲ ਨੂੰ ਅਜਿਹੇ ਹਾਰਡਵੇਅਰ ਉੱਤੇ ਰੱਖੋ ਜਿਸਨੂੰ ਤੁਸੀਂ ਅਪਡੇਟ ਕਰ ਸਕਦੇ ਹੋ

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

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

ਨੈੱਟਵਰਕ ਨਹੀਂ, ਸੇਵਾਵਾਂ ਦੀ ਆਗਿਆ ਦਿਓ

ਨੀਤੀ ਨੂੰ ਦੋ ਜੋੜਾਂ ਵਿਚਕਾਰ ਪ੍ਰੋਟੋਕੋਲ, ਪੋਰਟ ਅਤੇ ਦਿਸ਼ਾ ਦੇ ਰੂਪ ਵਿੱਚ ਲਿਖੋ। ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਪਤੇ ਲਈ ਇੱਕ ਮਨਜ਼ੂਰ ਪੋਰਟ ਆਮ ਜਵਾਬ ਹੈ, ਅਤੇ ਜੰਪ ਹੋਸਟ ਰਾਹੀਂ ਪ੍ਰਬੰਧਕੀ ਮਾਰਗ ਬਾਕੀ ਨੂੰ ਢਕਦਾ ਹੈ।

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

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

ਰਿਕਵਰੀ ਨੂੰ ਟਨਲ ਤੋਂ ਬਿਨਾਂ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ

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

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

ਸਰਟੀਫਿਕੇਟ, ਘੜੀਆਂ ਅਤੇ ਦਸਤਖਤ ਚੇਤਾਵਨੀਆਂ

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

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