ਜਦੋਂ openfortivpn ਜੁੜਦਾ ਹੈ ਤਾਂ ਰੂਟ ਅਤੇ DNS ਦਾ ਮਾਲਕ ਕੌਣ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ?

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

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

ਇੱਕੋ ਕਨੈਕਸ਼ਨ ਵਰਗੇ ਦਿਖਣ ਵਾਲੇ ਚਾਰ ਪੜਾਅ

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

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

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

ਰਾਊਟਿੰਗ ਟੇਬਲ ਕੌਣ ਸੋਧਦਾ ਹੈ

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

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

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

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

DNS ਅਤੇ ਰਿਜ਼ੋਲਵਰ ਫਾਈਲ ਦਾ ਮਾਲਕ ਕੌਣ ਹੈ

DNS ਉਹੀ ਫੈਸਲਾ ਹੈ, ਹੋਰ ਤਿੱਖੇ ਕਿਨਾਰਿਆਂ ਨਾਲ। ਕਲਾਇੰਟ ਗੇਟਵੇ ਜਾਂ PPP ਸਾਥੀ ਵੱਲੋਂ ਦੱਸੇ DNS ਸਰਵਰ ਸਵੀਕਾਰ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਹੋਸਟ ਰਿਜ਼ੋਲਵਰ ਕਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਲਿਖ ਸਕਦਾ ਹੈ। ਸਧਾਰਨ ਮਸ਼ੀਨ 'ਤੇ ਇਹੀ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ, ਕਿਉਂਕਿ ਅੰਦਰੂਨੀ ਨਾਮ ਤਦ ਹੀ ਹੱਲ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਟਨਲ ਚਾਲੂ ਹੋਵੇ।

ਆਧੁਨਿਕ Linux ਹੋਸਟ 'ਤੇ ਰਿਜ਼ੋਲਵਰ ਸਥਾਨਕ ਸਟਬ ਦੁਆਰਾ ਸੰਭਾਲਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਉਸ ਸਟਬ ਦੀ ਪਿੱਠ ਪਿੱਛੇ ਰਿਜ਼ੋਲਵਰ ਫਾਈਲ ਦੁਬਾਰਾ ਲਿਖਣ ਨਾਲ ਅਜਿਹਾ ਕਨਫਿਗਰੇਸ਼ਨ ਬਣਦਾ ਹੈ ਜੋ ਸਹੀ ਦਿਖਦਾ ਹੈ ਅਤੇ ਅਸੰਗਤ ਵਿਵਹਾਰ ਕਰਦਾ ਹੈ। ਜੇ ਹੋਸਟ ਪਹਿਲਾਂ ਹੀ ਰਿਜ਼ੋਲਵਰ ਮੈਨੇਜਰ ਚਲਾ ਰਿਹਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ DNS ਦਾ ਮਾਲਕ ਬਣਨ ਦਿਓ ਅਤੇ ਇਸਦੇ ਸਮਰਥਿਤ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਟਨਲ ਦੇ ਸਰਵਰ ਦਿਓ। ਕਲਾਇੰਟ ਦਾ no-dns ਵਿਕਲਪ ਉੱਥੇ ਸਹੀ ਚੋਣ ਹੈ, ਕੋਈ ਬਚਾਅ ਉਪਾਅ ਨਹੀਂ।

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

ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ, ਤਿਆਰੀ ਅਤੇ ਹੈਂਡਓਵਰ

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

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

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