ਦੋ VPN, ਇੱਕ ਰਿਜ਼ਾਲਵਰ: ਜੋ ਅੰਤ ਵਿੱਚ ਲਿਖਦਾ ਹੈ, ਉਹੀ ਜਿੱਤਦਾ ਹੈ

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

ਭਰਮ: ਸਭ ਤੋਂ ਨਵਾਂ VPN ਹੀ DNS ਦਾ ਮਾਲਕ ਹੈ

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

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

ਨਾਮ ਥਾਵਾਂ ਨੂੰ ਰਿਜ਼ਾਲਵਰਾਂ ਨਾਲ ਮੈਪ ਕਰੋ

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

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

Windows ਵਿੱਚ, ਨਾਮ ਹੱਲ ਨੀਤੀ ਸਾਰਣੀ ਸਫਿਕਸਾਂ ਨੂੰ ਖ਼ਾਸ ਸਰਵਰਾਂ ਵੱਲ ਭੇਜ ਸਕਦੀ ਹੈ, ਅਤੇ VPN ਕਲਾਇੰਟ ਉੱਥੇ ਨਿਯਮ ਸਥਾਪਤ ਕਰ ਸਕਦਾ ਹੈ। ਐਡਾਪਟਰ ਸੂਚੀ ਦੀ ਥਾਂ ਨੀਤੀ ਦੀ ਜਾਂਚ ਕਰੋ, ਕਿਉਂਕਿ ਨਾਮ ਐਡਾਪਟਰ ਸੂਚੀ ਹੱਲ ਨਹੀਂ ਕਰਦੀ।

ਬੂਟਸਟ੍ਰੈਪ ਮਾਰਗ ਰੱਖੋ

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

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

ਓਵਰਲੈਪਿੰਗ ਪਤੇ DNS ਦੀ ਸਮੱਸਿਆ ਨਹੀਂ ਹਨ

ਇੱਕੋ ਪਤਾ ਰੇਂਜ ਵਰਤਣ ਵਾਲੇ ਦੋ ਨਿੱਜੀ ਨੈੱਟਵਰਕ DNS ਕ੍ਰਮ ਨਾਲ ਠੀਕ ਨਹੀਂ ਹੋ ਸਕਦੇ। ਜੇ ਦੋਵੇਂ ਟਨਲ 10.0.0.0/8 ਦਾ ਦਾਅਵਾ ਕਰਦੀਆਂ ਹਨ, ਤਾਂ ਸਹੀ ਢੰਗ ਨਾਲ ਹੱਲ ਹੋਇਆ ਨਾਮ ਵੀ ਉਸ ਪਤੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ ਜਿੱਥੇ ਹੋਸਟ ਸਹੀ ਟਨਲ ਤੱਕ ਰੂਟ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਇਸ ਲਈ ਪਤੇ ਦੇ ਪੱਧਰ 'ਤੇ ਹੱਲ ਚਾਹੀਦਾ ਹੈ, ਜਿਵੇਂ ਵੱਖਰੀਆਂ ਰੇਂਜਾਂ, ਨਾਮ ਥਾਂ ਜਾਂ ਅਨੁਵਾਦ, ਨਾ ਕਿ ਇੱਕ ਹੋਰ ਰਿਜ਼ਾਲਵਰ ਸੈਟਿੰਗ। ਇਹ ਜਲਦੀ ਤੈਅ ਕਰਨਾ ਉਸ ਲੰਮੇ ਚੱਕਰ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ ਜੋ ਕਦੇ ਕੰਮ ਨਾ ਕਰਨ ਵਾਲੀ DNS ਕਨਫਿਗਰੇਸ਼ਨ ਰਾਹੀਂ ਹੁੰਦਾ।

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

ਅਸਲੀ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨਾਲ ਇਹ ਸਾਬਤ ਕਰੋ

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

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