OpenVPN ਵੱਲੋਂ ਧੱਕੇ ਗਏ ਰੂਟ ਸਥਾਪਤ ਨਹੀਂ ਹੁੰਦੇ: ਸਮਾਂ, ਅਧਿਕਾਰ ਜਾਂ ਨੀਤੀ

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

ਬਾਹਰੋਂ ਇਹ ਇੱਕੋ ਜਿਹੇ ਦਿਖਦੇ ਹਨ ਅਤੇ ਵੱਖਰੇ ਸੁਧਾਰ ਮੰਗਦੇ ਹਨ। ਕਲਾਇੰਟ ਲੌਗ ਉਸ ਬਿੰਦੂ ’ਤੇ ਪੜ੍ਹੋ ਜਿੱਥੇ ਰੂਟ ਦਾ ਫੈਸਲਾ ਲਿਆ ਜਾਂਦਾ ਹੈ।

ਸਿੱਧ ਕਰੋ ਕਿ ਰੂਟ ਗੈਰਹਾਜ਼ਰ ਹੈ, ਸਿਰਫ਼ ਟੁੱਟਾ ਨਹੀਂ

ਸ਼ੁਰੂਆਤ ਇਹ ਸਿੱਧ ਕਰਨ ਨਾਲ ਕਰੋ ਕਿ ਰੂਟ ਟੁੱਟਾ ਨਹੀਂ ਸਗੋਂ ਗੈਰਹਾਜ਼ਰ ਹੈ। Linux ਉੱਤੇ, ip route show dev tun0 ਦੱਸਦਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਨੇ ਟਨਲ ਡਿਵਾਈਸ ਉੱਤੇ ਕੀ ਸਥਾਪਤ ਕੀਤਾ। Windows ਉੱਤੇ, route print ਜਾਂ Get-NetRoute ਉਹੀ ਗੱਲ ਟੇਬਲ ਰੂਪ ਵਿੱਚ ਦਿਖਾਉਂਦਾ ਹੈ।

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

ਸਮਾਂ: ਡਿਵਾਈਸ ਦੇ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਜੋੜਨ ਦੀ ਕਾਰਵਾਈ ਚੱਲੀ

ਕੰਟਰੋਲ ਚੈਨਲ ਉੱਪਰ ਆਉਣ ਤੋਂ ਬਾਅਦ ਅਤੇ ਇੰਟਰਫ਼ੇਸ ਸੰਰਚਿਤ ਕਰਨ ਤੋਂ ਬਾਅਦ ਕਲਾਇੰਟ ਸਰਵਰ ਦੇ PUSH_REPLY ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦਾ ਹੈ। ਤਦ ਹੀ ਉਹ ਪਲੇਟਫ਼ਾਰਮ ਵੱਲੋਂ ਦਿੱਤੀ ਕਿਸੇ ਵੀ ਵਿਧੀ ਨਾਲ ਰਾਊਟਿੰਗ ਟੇਬਲ ਨੂੰ ਛੂਹਦਾ ਹੈ। Linux netlink ਰਾਹੀਂ ਜਾਂਦਾ ਹੈ; Windows ਉੱਨਤ ਟੋਕਨ ਲੋੜੀਂਦਾ API ਵਰਤਦਾ ਹੈ। ਸੰਰਚਨਾ ਪੜ੍ਹਦਿਆਂ ਹੀ ਰੂਟ ਜੋੜਨ ਵਾਲੀ ਸਕ੍ਰਿਪਟ ਜਾਂ ਕਲਾਇੰਟ TUN/TAP ਡਿਵਾਈਸ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਚੱਲ ਸਕਦਾ ਹੈ, ਅਤੇ ਕਰਨਲ ਜੋੜਨ ਤੋਂ ਇਨਕਾਰ ਕਰ ਦਿੰਦਾ ਹੈ।

ਉਹੀ ਦੌੜ ਦੱਸਦੀ ਹੈ ਕਿ ਹੱਥ ਨਾਲ ਲਿਖਿਆ ਰੂਟ ਕਿਉਂ ਕੰਮ ਕਰਦਾ ਹੈ ਪਰ ਆਪਣੇ-ਆਪ ਵਾਲਾ ਨਹੀਂ: ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਲਿਖਦੇ ਹੋ, ਇੰਟਰਫ਼ੇਸ ਪਹਿਲਾਂ ਹੀ ਉੱਪਰ ਹੁੰਦਾ ਹੈ।

ਇਸ ਸਥਿਤੀ ਲਈ route-delay ਮੌਜੂਦ ਹੈ, ਅਤੇ ਇੰਟਰਫ਼ੇਸ ਤੇ ਰੂਟ ਸੰਰਚਿਤ ਹੋਣ ਤੋਂ ਬਾਅਦ ਚੱਲਣ ਵਾਲੀ ਸਕ੍ਰਿਪਟ ਦਾ ਨਾਮ route-up ਦੱਸਦਾ ਹੈ। ਟਨਲ ਪਤੇ ’ਤੇ ਨਿਰਭਰ ਰੂਟ ਸ਼ੁਰੂਆਤੀ ਪੜਾਅ ਵਿੱਚ ਨਹੀਂ, ਉਸੇ ਹੁੱਕ ਵਿੱਚ ਰੱਖੋ।

ਅਧਿਕਾਰ: ਟੇਬਲ ਕੌਣ ਬਦਲ ਸਕਦਾ ਹੈ

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

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

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

ਨੀਤੀ: ਪੁਸ਼ ਕੀਤੇ ਰੂਟ ਜਾਣ-ਬੁੱਝ ਕੇ ਛੱਡੇ ਜਾ ਸਕਦੇ ਹਨ

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

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

ਟੈਕਸਟ ਐਡੀਟਰ ਵਿੱਚ ਸਾਫ਼ ਦਿਖਣ ਵਾਲੀ ਪਰੋਫ਼ਾਈਲ ਰਨਟਾਈਮ ਵਿੱਚ ਜੋੜਿਆ ਨਿਰਦੇਸ਼ ਲੈ ਕੇ ਹੋ ਸਕਦੀ ਹੈ।

ਪੁਸ਼ ਸੂਚੀ ਦੀ ਟੇਬਲ ਨਾਲ ਤੁਲਨਾ ਕਰੋ

ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਸਰਵਰ ਦੀ ਪੁਸ਼ ਸੂਚੀ ਕਲਾਇੰਟ ਦੀ ਟੇਬਲ ਦੇ ਕੋਲ ਰੱਖੋ। Linux ਉੱਤੇ ਉਹ ip route show dev tun0 ਹੈ; Windows ਉੱਤੇ route print ਜਾਂ Get-NetRoute। ਜੇ ਰੂਟ ਗੈਰਹਾਜ਼ਰ ਹੈ, ਤਾਂ ਪਹਿਲਾਂ ਸਥਾਪਨਾ ਠੀਕ ਕਰੋ। ਜੇ ਉਹ ਮੌਜੂਦ ਹੈ ਪਰ ਟ੍ਰੈਫਿਕ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਫਾਰਵਰਡਿੰਗ ਅਤੇ ਫਾਇਰਵਾਲ ਨੀਤੀ ਵੱਲ ਵਧੋ।

ਕਲਾਇੰਟ ਦਾ ਸੰਸਕਰਣ, ਉਹ ਕਿਹੜੇ ਖਾਤੇ ’ਤੇ ਚੱਲਦਾ ਹੈ ਅਤੇ ਸੇਵਾ-ਆਧਾਰਿਤ ਹੈ ਕਿ ਨਹੀਂ, ਦਰਜ ਕਰੋ। ਇਹ ਤਿੰਨ ਤੱਥ ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ ਦੱਸਦੇ ਹਨ ਕਿ ਕਿਹੜੇ ਕਾਰਨ ਬਾਹਰ ਰੱਖੇ ਗਏ।