Linux VPN ਉੱਤੇ ਪਤਾ, ਰੂਟ, DNS ਅਤੇ ਫਾਇਰਵਾਲ ਦਾ ਮਾਲਕ ਕੌਣ ਹੈ?

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

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

ਡਿਵਾਈਸ ਅਤੇ ਉਸਦੇ ਪਤੇ

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

ਸੈਸ਼ਨ ਖਤਮ ਹੋਣ 'ਤੇ ਡਿਵਾਈਸ ਕੌਣ ਹਟਾਉਂਦਾ ਹੈ, ਇਹ ਦਰਜ ਕਰੋ। ਜੋ ਡਿਵਾਈਸ ਆਪਣੇ ਸੈਸ਼ਨ ਤੋਂ ਵੱਧ ਜੀਵਦਾ ਹੈ, ਉਹੀ ਪੁਰਾਣੇ ਪਤਿਆਂ ਅਤੇ ਉਹਨਾਂ ਤੋਂ ਬਾਅਦ ਦੀ ਉਲਝਣ ਦਾ ਸਭ ਤੋਂ ਆਮ ਸਰੋਤ ਹੈ।

ਰੂਟ ਅਤੇ ਨੀਤੀ ਨਿਯਮ

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

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

DNS ਹਮੇਸ਼ਾ ਵੱਖਰਾ ਮਾਲਕ ਹੈ

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

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

ਫਾਇਰਵਾਲ ਸਥਿਤੀ, ਅਤੇ ਇਸਨੂੰ ਕੌਣ ਬਹਾਲ ਕਰਦਾ ਹੈ

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

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

ਜੀਵਨ-ਚੱਕਰ: ਬੂਟ, ਮੁੜ-ਕਨੈਕਸ਼ਨ, ਟਿਅਰਡਾਊਨ

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

ਨਿਰੀਖਣ ਲਈ ip monitor link address route ਕਰਨਲ ਬਦਲਾਅ ਹੁੰਦਿਆਂ ਹੀ ਦਿਖਾਉਂਦਾ ਹੈ, ਪਰ ਇਹ ਮੰਸ਼ਾ ਨਹੀਂ, ਘਟਨਾਵਾਂ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ: ਹਟਾਇਆ ਰੂਟ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਕਿਹੜੀ ਪ੍ਰਕਿਰਿਆ ਨੇ ਇਸਨੂੰ ਹਟਾਇਆ। ਇਸਨੂੰ ਮਾਲਕੀ ਨਕਸ਼ੇ ਨਾਲ ਜੋੜੋ, ਅਤੇ ਉਲਝਾਉਣ ਵਾਲਾ ਸ਼ਟਡਾਊਨ ਉਮੀਦਵਾਰਾਂ ਦੀ ਛੋਟੀ ਸੂਚੀ ਬਣ ਜਾਂਦਾ ਹੈ।

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