UID ਨਿਯਮ ਨਾਲ ਇੱਕ Linux ਖਾਤਾ OpenVPN ਰਾਹੀਂ ਰੂਟ ਕਰੋ

ਖਾਤਾ-ਆਧਾਰਿਤ ਰਾਊਟਿੰਗ ਤਦ ਢੁਕਵੀਂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਇੱਕ Linux ਵਰਤੋਂਕਾਰ ਦੀ ਮਲਕੀਅਤ ਵਾਲਾ ਹਰ IPv4 ਸਾਕਟ ਮੌਜੂਦਾ ਟਨਲ ਰਾਹੀਂ ਬਾਹਰ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇਹ ਤਦ ਢੁਕਵੀਂ ਨਹੀਂ ਹੁੰਦੀ ਜਦੋਂ ਤੁਹਾਨੂੰ ਪ੍ਰੋਗਰਾਮ-ਪੱਧਰੀ ਵੱਖਰਤਾ ਚਾਹੀਦੀ ਹੋਵੇ। ਇਹ UID ਅਨੁਸਾਰ ਚੁਣਦੀ ਹੈ, ਇਸ ਲਈ ਉਸ ਖਾਤੇ ਹੇਠ ਚੱਲਣ ਵਾਲਾ ਹਰ ਕੁਝ ਦਾਇਰੇ ਵਿੱਚ ਆਉਂਦਾ ਹੈ, ਜਿਸ ਬੈਚ ਕੰਮ ਨੂੰ ਤੁਸੀਂ ਭੁੱਲ ਗਏ, ਉਹ ਵੀ। ਇੱਕ ਵੀ ip rule ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਸਵਾਲ ਨਿਪਟਾਓ।

ਹੇਠਾਂ ਦਿੱਤੀ ਉਦਾਹਰਨ UID 1500 ਤੇ ਸਮਰਪਿਤ ਬਰਾਊਜ਼ਰ ਖਾਤਾ, 10.80.0.11 ਸਥਾਨਕ ਪਤਾ ਰੱਖਣ ਵਾਲਾ ਟਨਲ ਯੰਤਰ tun-office, ਅਤੇ ਵਿਚਾਰ ਅਧੀਨ ਮੰਜ਼ਿਲਾਂ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਵਾਲਾ VPN ਮੰਨਦੀ ਹੈ। ਡੈਮਨ ਆਪ ਉਸ UID ਤੋਂ ਬਾਹਰ ਚੱਲਦਾ ਹੈ।

ਤੰਤਰ ਚੁਣਨ ਵਾਲੀਆਂ ਤਿੰਨ ਸ਼ਰਤਾਂ

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

ਬਚਣ ਵਾਲੀ ਗਲਤੀ ਹੈ ਇਹ ਮੰਨਣਾ ਕਿ ਲਾਂਚਰ ਮਾਲਕ ਤੈਅ ਕਰਦਾ ਹੈ। ਕਿਸੇ ਹੋਰ ਵਰਤੋਂਕਾਰ ਦੇ ਸੈਸ਼ਨ ਤੋਂ URL ਲੈਣ ਵਾਲੇ ਬਰਾਊਜ਼ਰ ਨੇ UID 1500 ਹੇਠ ਸਾਕਟ ਨਹੀਂ ਬਣਾਏ, ਅਤੇ ਕੋਈ ਨਿਯਮ ਉਸ ਦੁਆਰਾ ਪੈਦਾ ਕੀਤਾ ਟ੍ਰੈਫਿਕ ਨਹੀਂ ਹਿਲਾਏਗਾ।

ਸਾਰਣੀ, ਨਿਯਮ ਅਤੇ ਰਾਖਾ

ਮੌਜੂਦਾ ਨਿਯਮ ਜਾਂਚ ਕੇ ਅਣਵਰਤੇ ਸਾਰਣੀ ਅਤੇ ਤਰਜੀਹ ਨੰਬਰ ਚੁਣਨ ਤੋਂ ਬਾਅਦ ਬੰਦੋਬਸਤ ਛੋਟੀ ਹੈ: ਟਨਲ ਦਾ ਸਰੋਤ ਪਤਾ ਰੱਖਣ ਵਾਲੀ ਸਮਰਪਿਤ ਸਾਰਣੀ ਵਿੱਚ ਡਿਫਾਲਟ ਰਾਹ, ਖਾਤੇ ਦੀਆਂ ਖੋਜਾਂ ਨੂੰ ਉਸ ਸਾਰਣੀ ਵੱਲ ਭੇਜਣ ਵਾਲਾ ਨਿਯਮ, ਅਤੇ ਫਾਲਬੈਕ ਰੋਕਣ ਵਾਲਾ ਆਖਰੀ ਨਿਯਮ। ਲਿਖਤ ਰੂਪ ਵਿੱਚ ਇਹ ਇਡੈਂਪੋਟੈਂਟ ਰਾਹ ਬਦਲੀ ਹੈ, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820।

ਰਾਖਾ ip -4 rule add priority 12101 uidrange 1500-1500 unreachable ਹੈ, ਅਤੇ ਇਹ ਆਪਣੀ ਲੰਬਾਈ ਦੇ ਸੰਕੇਤ ਤੋਂ ਵੱਧ ਮਾਅਨੇ ਰੱਖਦਾ ਹੈ। ਇਸ ਤੋਂ ਬਿਨਾਂ ਸਾਰਣੀ 51820 ਵਿੱਚ ਗੁੰਮ ਰਾਹ ਆਮ ਅਪਲਿੰਕ ਵਿੱਚ ਡਿੱਗਦਾ ਹੈ ਅਤੇ ਖਾਤਾ ਚੁੱਪਚਾਪ ਉਹ ਟ੍ਰੈਫਿਕ ਲੀਕ ਕਰਦਾ ਹੈ ਜੋ ਨੀਤੀ ਨੇ ਫੜਨਾ ਸੀ। ਇਸ ਨਾਲ ਉਹੀ ਨਾਕਾਮੀ ਟਾਈਮਆਊਟ ਬਣ ਜਾਂਦੀ ਹੈ, ਭਾਵ ਫਾਲਬੈਕ ਨਹੀਂ ਸਗੋਂ ਰੋਕ।

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

UID ਰਾਊਟਿੰਗ ਕੀ ਛੱਡਦੀ ਹੈ: DNS

ਰਿਜ਼ਾਲਵਰ ਡੈਮਨ ਆਪਣੇ ਅੱਪਸਟਰੀਮ ਸਾਕਟ ਆਪਣੇ UID ਹੇਠ ਖੋਲ੍ਹਦਾ ਹੈ, ਇਸ ਲਈ 1500 ਚੁਣਨ ਨਾਲ ਉਹ ਕਵੈਰੀਆਂ ਸਾਰਣੀ 51820 ਵਿੱਚ ਨਹੀਂ ਜਾਂਦੀਆਂ। DNS ਏਕੀਕਰਨ ਵੱਖਰਾ ਫੈਸਲਾ ਹੈ: ਖਾਤੇ ਨੂੰ ਟਨਲ ਰਾਹੀਂ ਪਹੁੰਚ ਵਾਲੇ ਰਿਜ਼ਾਲਵਰ ਵੱਲ ਨਿਸ਼ਾਨਾ ਕਰੋ, ਜਾਂ ਮੰਨ ਲਓ ਕਿ ਨਾਮ-ਹੱਲ ਹੋਸਟ ਦੇ ਰਾਹ ਨਾਲ ਚੱਲਦਾ ਹੈ ਪਰ ਟ੍ਰੈਫਿਕ ਨਹੀਂ।

ਸਥਾਨਕ stub ਨੂੰ loopback ਕਵੈਰੀ ਇਹ ਸਬੂਤ ਨਹੀਂ ਕਿ ਅੱਪਸਟਰੀਮ ਕਵੈਰੀ ਨੇ ਬਰਾਊਜ਼ਰ ਦਾ ਰਾਹ ਵਰਤਿਆ, ਅਤੇ ਨਾ ਹੀ ਕੈਸ਼ ਤੋਂ ਸਫਲ ਪੰਨਾ ਲੋਡ।

IPv6 ਨੂੰ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਆਪਣਾ ਵਾਕ ਚਾਹੀਦਾ ਹੈ

ਉੱਪਰਲੇ ਨਿਯਮ ਸਿਰਫ਼ IPv4 ਢਕਦੇ ਹਨ। ਜੇ ਲੋੜ ਇਸ ਖਾਤੇ ਤੋਂ ਸਿੱਧਾ IPv6 ਤੋਂ ਬਿਨਾਂ IPv4 ਟਨਲ ਹੈ, ਤਾਂ ਸਮੀਖਿਆ ਕੀਤਾ ਆਖਰੀ ਨਿਯਮ ਸ਼ਾਮਲ ਕਰੋ ਜਿਵੇਂ ip -6 rule add priority 12101 uidrange 1500-1500 unreachable, ਫਿਰ ਪਹਿਲਾਂ ਦੇ IPv6 ਨਿਯਮ ਅਤੇ ਤੁਹਾਡੇ ਰੱਖਣ ਵਾਲੇ loopback ਛੋਟਾਂ ਜਾਂਚੋ।

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

ਸੱਚੇ ਖਾਤੇ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ, ਫਿਰ ਜੀਵਨ-ਚੱਕਰ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਲਵੋ

ਖੋਜਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ: ਆਮ UID ਨਾਲ ਉਸੇ ਮੰਜ਼ਿਲ ਲਈ ip -4 route get 198.51.100.25 uid 1500। ਫਿਰ ਸਮਰਪਿਤ ਖਾਤੇ ਹੇਠ ਮਨਜ਼ੂਰ ਬੇਨਤੀ ਕਰੋ ਅਤੇ ਦੂਰਲੇ ਸਿਰੇ ਵੱਲੋਂ ਦਿਸਦਾ ਸਰੋਤ ਪਤਾ ਜਾਂਚੋ। ਤਰਜੀਹੀ ਸਰੋਤ ਪਤਾ source NAT ਨਹੀਂ, ਅਤੇ ਇਹ ਕਿਸੇ ਹੋਰ ਚੀਜ਼ ਨੂੰ ਬਾਈਂਡ ਕਰਨ ਵਾਲੀ ਐਪਲੀਕੇਸ਼ਨ ਤੇ ਭਾਰੀ ਨਹੀਂ ਪਵੇਗਾ। ਜੇ ਦੋਵੇਂ ਖੋਜਾਂ ਇੱਕੋ ਰਾਹ ਦਿੰਦੀਆਂ ਹਨ, ਤਾਂ ਨਿਯਮ ਉਹ ਨਹੀਂ ਕਰ ਰਿਹਾ ਜੋ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ।

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