Linux ਉੱਤੇ Transmission: ਪ੍ਰਕਿਰਿਆ ਦੇ ਮਾਲਕ ਅਨੁਸਾਰ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਟ੍ਰੈਫਿਕ ਲਾਗੂ ਕਰੋ
ਪੀਅਰ ਪੋਰਟ ਪੂਰੀ ਕਹਾਣੀ ਨਹੀਂ ਹੈ। ਫਾਇਰਵਾਲ ਨਿਯਮ ਨੂੰ ਕਲਾਇੰਟ ਦੇ ਖਾਤੇ ਤੱਕ ਸੀਮਿਤ ਕਰੋ, ਦੋਵੇਂ ਪਤਾ ਪਰਿਵਾਰ ਢੱਕੋ ਅਤੇ ਟਨਲ ਬੰਦ ਹੋਣ ’ਤੇ ਪਰਖੋ।
Transmission ਦਾ ਆਉਣ ਵਾਲਾ ਪੋਰਟ ਬੰਦ ਕਰਨਾ VPN ਨੀਤੀ ਨਹੀਂ ਹੈ। ਟੋਰੈਂਟ ਕਲਾਇੰਟ ਪੀਅਰਾਂ ਅਤੇ ਟ੍ਰੈਕਰਾਂ ਵੱਲ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਦਾ ਹੈ, ਨਾਵਾਂ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ ਅਤੇ ਦੂਰ ਤੋਂ ਕੰਟਰੋਲ ਲਈ ਸੁਣਨ ਵਾਲਾ ਖੋਲ੍ਹ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਉਸ ਇੰਟਰਫੇਸ ਰਾਹੀਂ ਬਾਹਰ ਜਾ ਸਕਦਾ ਹੈ ਜਿਸਦਾ ਤੁਸੀਂ ਇਰਾਦਾ ਨਹੀਂ ਕੀਤਾ ਸੀ। ਪੰਜਾਂ ਜਾਂਚਾਂ ਕ੍ਰਮ ਨਾਲ ਕਰੋ ਅਤੇ ਸੀਮਾ ਵਜੋਂ ਫਾਇਰਵਾਲ ਨਿਯਮ ਨੂੰ, ਕਲਾਇੰਟ ਦੀਆਂ ਸੈਟਿੰਗਾਂ ਨੂੰ ਨਹੀਂ, ਮੰਨੋ। ਆਖਰੀ ਦੋ ਜਾਂਚਾਂ ਉਹ ਹਨ ਜਿਹਨਾਂ ਨੂੰ ਲੋਕ ਛੱਡ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਟਨਲ ਡਿੱਗਣ ’ਤੇ ਗਾਰੰਟੀ ਟਿਕਦੀ ਹੈ ਜਾਂ ਨਹੀਂ ਇਹ ਉਹੀ ਤੈਅ ਕਰਦੀਆਂ ਹਨ।
ਉਸ ਪ੍ਰਕਿਰਿਆ ਦਾ ਨਾਂ ਲਵੋ ਜੋ ਟ੍ਰਾਂਸਫਰ ਦੀ ਮਾਲਕ ਹੈ
ਡੈਸਕਟਾਪ ਐਪਲੀਕੇਸ਼ਨ ਅਤੇ ਸਿਸਟਮ ਡੈਮਨ ਵੱਖ-ਵੱਖ ਖਾਤਿਆਂ ਹੇਠ ਚੱਲਦੇ ਹਨ, ਅਤੇ ਮਾਲਕ ਅਧਾਰਿਤ ਨਿਯਮ ਪ੍ਰੋਗਰਾਮ ਦੇ ਨਾਂ ਦੀ ਥਾਂ ਖਾਤੇ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ। ਕੋਈ ਵੀ ਨਿਯਮ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਪਤਾ ਕਰੋ ਕਿ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕਿਹੜਾ ਚੱਲ ਰਿਹਾ ਹੈ। ਸਮਰਪਿਤ ਸੇਵਾ ਖਾਤਾ ਨੀਤੀ ਨੂੰ ਸਹੀ ਵਿਸ਼ਾ ਦਿੰਦਾ ਹੈ, ਜਦਕਿ ਡੈਸਕਟਾਪ ਵਰਤੋਂਕਾਰ ਆਪਣੀ ਪਛਾਣ ਬ੍ਰਾਊਜ਼ਰ, ਸੰਪਾਦਕ ਅਤੇ ਸੈਸ਼ਨ ਦੀ ਹਰ ਹੋਰ ਚੀਜ਼ ਨਾਲ ਸਾਂਝੀ ਕਰਦਾ ਹੈ। UID ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਇਹ ਨਾ ਮੰਨੋ ਕਿ ਪੈਕੇਜ ਵਾਲਾ ਖਾਤਾ ਨਾਂ ਹੀ ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਹੈ।
systemctl status transmission-daemon
ps -o user=,pid=,cmd= -C transmission-daemon
ਜੇ ਖਾਤਾ ਅਜੇ ਮੌਜੂਦ ਨਹੀਂ ਤਾਂ ਇਸੇ ਮਕਸਦ ਲਈ ਬਣਾਓ ਅਤੇ ਇਸਨੂੰ ਚਲਾਉਣ ਲਈ ਹੋਰ ਕੁਝ ਨਾ ਦਿਓ। ਖਾਤਾ ਅਤੇ UID ਨਿਯਮ ਦੀ ਟਿੱਪਣੀ ਵਿੱਚ ਲਿਖੋ, ਕਿਉਂਕਿ ਵਿਸ਼ੇ ਤੋਂ ਬਿਨਾਂ ਨਿਯਮ ਉਹ ਨਿਯਮ ਹੈ ਜਿਸਨੂੰ ਕੋਈ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਸੰਪਾਦਿਤ ਨਹੀਂ ਕਰ ਸਕਦਾ।
ਸੁਣਨ ਵਾਲੇ ਖੇਤਰਾਂ ਨੂੰ ਰਸਤੇ ਤੋਂ ਵੱਖ ਕਰੋ
Transmission 4.x ਪੀਅਰ ਸੁਣਨ ਵਾਲੇ ਪਤਿਆਂ ਨੂੰ rpc-bind-address ਤੋਂ ਵੱਖਰਾ ਦਰਜ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਫ਼ਰਕ ਮਹੱਤਵਪੂਰਨ ਹੈ। RPC ਸੈਟਿੰਗ ਸਿਰਫ਼ ਦੂਰ ਤੋਂ ਕੰਟਰੋਲ ਦੇ ਸੁਣਨ ਵਾਲੇ ਨੂੰ ਕੰਟਰੋਲ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਬਦਲਣ ਨਾਲ ਪੀਅਰ ਟ੍ਰੈਫਿਕ ਲਈ ਰਸਤਾ ਨਹੀਂ ਚੁਣਿਆ ਜਾਂਦਾ। ਦੋਵੇਂ ਸੈਟਿੰਗਾਂ ਨੂੰ ਇੱਕ ਮੰਨ ਕੇ ਪੜ੍ਹਨਾ ਇਸ ਗੱਲ ਦਾ ਸਭ ਤੋਂ ਆਮ ਕਾਰਨ ਹੈ ਕਿ ਦੇਖਣ ਵਿੱਚ ਸਾਵਧਾਨ ਕਾਨਫਿਗਰੇਸ਼ਨ ਫਿਰ ਵੀ ਲੀਕ ਹੁੰਦੀ ਹੈ। ਉਹੀ ਦਸਤਾਵੇਜ਼ ਪੀਅਰ ਦੇ ਸੁਣਨ ਵਾਲੇ ਪਤੇ ਦੇ ਅਵੈਧ ਹੋਣ ’ਤੇ ਵਿਕਲਪਿਕ ਰਾਹ ਦੱਸਦਾ ਹੈ, ਭਾਵ ਉਪਲਬਧ ਨਾ ਹੋਣ ਵਾਲਾ ਪਤਾ ਦਰਜ ਵਿਕਲਪਿਕ ਸਥਿਤੀ ਹੈ, ਕੋਈ ਗਾਰੰਟੀਸ਼ੁਦਾ ਇਨਕਾਰ ਨਹੀਂ।
grep -E '"(peer-port|rpc-bind-address|bind-address-ipv4)"' /var/lib/transmission-daemon/.config/transmission-daemon/settings.json
ਕਲਾਇੰਟ ਦੇ ਕੰਟਰੋਲ ਉਹਨਾਂ ਦੇ ਮਕਸਦ ਲਈ ਵਰਤੋ ਅਤੇ ਗਾਰੰਟੀ ਫਾਇਰਵਾਲ ਵਿੱਚ ਰੱਖੋ। ਸੁਣਨ ਵਾਲੀ ਸੈਟਿੰਗ ਅਜੇ ਵੀ ਲਾਹੇਵੰਦ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਕਿ ਟ੍ਰੈਕਰਾਂ ਨਾਲ ਸੰਪਰਕ, ਸਥਾਨਕ ਖੋਜ ਜਾਂ ਪ੍ਰਤਿਨਿਧਿਤ ਖੋਜ ਸਭ ਟਨਲ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦੇ ਹਨ। ਜਦੋਂ ਦੋਵੇਂ ਵਿੱਚ ਮਤਭੇਦ ਹੋਵੇ, ਫਾਇਰਵਾਲ ਫੈਸਲਾ ਕਰਦਾ ਹੈ।
ਮਾਲਕ ਮੇਲ ਸਹੀ ਚੇਨ ਵਿੱਚ ਲਿਖੋ
ਮਾਲਕ ਮੇਲ ਬਾਰੇ Netfilter ਦੀ ਪੁਸਤਿਕਾ ਦੱਸਦੀ ਹੈ ਕਿ ਸਥਾਨਕ ਤੌਰ ’ਤੇ ਬਣੇ ਪੈਕਟ ਸਾਕਟ ਫਾਈਲ ਦੇ ਮਾਲਕ ਵਰਤੋਂਕਾਰ ਜਾਂ ਗਰੁੱਪ ਨੂੰ ਕਿਵੇਂ ਆਰੋਪਿਤ ਹੁੰਦੇ ਹਨ। ਇਹ ਆਰੋਪਣ ਅੱਗੇ ਭੇਜੇ ਟ੍ਰੈਫਿਕ ਤੱਕ ਨਹੀਂ ਫੈਲਦਾ, ਅਤੇ ਵਾਧੂ ਗਰੁੱਪਾਂ ਦੇ ਮੇਲ ਲਈ ਸਪਸ਼ਟ ਵਿਕਲਪ ਚਾਹੀਦਾ ਹੈ। ਜਿਸ ਐਕਸਟੈਂਸ਼ਨ ਦੀ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ ਉਸਦੀ ਪੁਸਤਿਕਾ ਪੜ੍ਹੋ, ਨਾ ਕਿ ਪਹਿਲਾ ਮਿਲਿਆ ਉਦਾਹਰਨ।
iptables -A OUTPUT -m owner --uid-owner transmission -o tun0 -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner transmission -j REJECT
ip6tables -A OUTPUT -m owner --uid-owner transmission -o tun0 -j ACCEPT
ip6tables -A OUTPUT -m owner --uid-owner transmission -j REJECT
ਕ੍ਰਮ ਮੇਲ ਜਿੰਨਾ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਚੇਨ ਵਿੱਚ ਉੱਪਰ ਦੀ ਵਿਆਪਕ ਮਨਜ਼ੂਰੀ ਹੇਠਾਂ ਦੇ ਸਟੀਕ ਇਨਕਾਰ ਨੂੰ ਨਿਕਾਰਾ ਕਰ ਦਿੰਦੀ ਹੈ, ਇਸ ਲਈ ਨਿਯਮ ਜੋੜ ਕੇ ਆਸ ਕਰਨ ਦੀ ਥਾਂ ਪੂਰੀ ਚੇਨ ਦੀ ਸਮੀਖਿਆ ਕਰੋ। ਜੇ ਹੋਸਟ IPv6 ਚਲਾਉਂਦਾ ਹੈ ਤਾਂ ਦੋਵੇਂ ਪਤਾ ਪਰਿਵਾਰ ਸ਼ਾਮਲ ਕਰੋ, ਕਿਉਂਕਿ ਸਿਰਫ਼ v4 ਨੀਤੀ ਇੱਕ ਅਜਿਹਾ ਰਸਤਾ ਖੁੱਲ੍ਹਾ ਛੱਡ ਦਿੰਦੀ ਹੈ ਜਿਸ ’ਤੇ ਕੋਈ ਨਜ਼ਰ ਨਹੀਂ ਰੱਖਦਾ। ਨਿਯਮ ਕਲਾਇੰਟ ਅਤੇ ਟਨਲ ਦੇ ਮੁੜ ਚਾਲੂ ਹੋਣ ਦੌਰਾਨ ਵੀ ਸਥਾਪਿਤ ਰੱਖੋ।
ਤੈਅ ਕਰੋ ਕਿ tun0 ਗਾਇਬ ਹੋਣ ’ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ
ਫੇਲ੍ਹ ਨੀਤੀ ਇਸ ਅਭਿਆਸ ਦਾ ਮੁੱਖ ਹਿੱਸਾ ਹੈ। ਜੇ ਟਨਲ ਗਾਇਬ ਹੋ ਜਾਵੇ ਅਤੇ ਉਹੀ ਹੁੱਕ ਨਿਯਮ ਹਟਾ ਦੇਵੇ, ਕਲਾਇੰਟ ਭੌਤਿਕ ਇੰਟਰਫੇਸ ਵਰਤਣ ਲਈ ਆਜ਼ਾਦ ਹੈ ਜਦ ਤੱਕ ਕੋਈ ਹੋਰ ਚੀਜ਼ ਉਸਨੂੰ ਰੋਕਦੀ ਨਹੀਂ। ਸੁਰੱਖਿਅਤ ਡਿਜ਼ਾਈਨ ਨਿਯਮ ਰੱਖਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇਨਕਾਰ ਕਰਨ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਸੀਮਾ ਨੂੰ ਟਨਲ ਦੀ ਸਿਹਤ ਤੋਂ ਆਜ਼ਾਦ ਬਣਾਉਂਦਾ ਹੈ। ਨਿਯਮ ਵੀ ਮਿਟਾਉਣ ਵਾਲਾ ਹੁੱਕ ਫੇਲ੍ਹ ਨੀਤੀ ਦਾ ਬਿਲਕੁਲ ਉਲਟ ਹੈ।
ip link show tun0
iptables -S OUTPUT
ਇਸਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ ਪਰਖੋ: ਟਨਲ ਰੋਕੋ, ਅਜਿਹਾ ਟ੍ਰਾਂਸਫਰ ਸ਼ੁਰੂ ਕਰੋ ਜਿਸਨੂੰ ਛੱਡਣਾ ਸੁਰੱਖਿਅਤ ਹੈ ਅਤੇ ਦੇਖੋ ਕਿ ਕੁਝ ਬਾਹਰ ਜਾਂਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਫਿਰ ਟਨਲ ਵਾਪਸ ਲਿਆਓ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਮਨਸ਼ਾ ਵਾਲਾ ਰਸਤਾ ਦੁਬਾਰਾ ਕੰਮ ਕਰਦਾ ਹੈ।
ਉਹ ਰਸਤੇ ਢੱਕੋ ਜਿਹਨਾਂ ਨੂੰ ਨਿਯਮ ਨਹੀਂ ਦੇਖ ਸਕਦਾ
ਨਾਵਾਂ ਦਾ ਹੱਲ ਵੱਖਰੀ ਰਿਜ਼ੌਲਵਰ ਪ੍ਰਕਿਰਿਆ ਕਰ ਸਕਦੀ ਹੈ, ਅਤੇ ਨਾਮ ਥਾਂ ਜਾਂ ਸਮਰਪਿਤ ਗੇਟਵੇ ਇੱਕ ਹੋਰ ਸੀਮਾ ਦੇ ਸਕਦੇ ਹਨ ਜੇ ਉਹਨਾਂ ਦੇ ਸਾਂਝੇ ਤੇ ਬੂਟਸਟ੍ਰੈਪ ਰਸਤੇ ਇਸ ਲਈ ਬਣੇ ਹੋਣ। ਤੈਅ ਕਰੋ ਕਿ DNS ਕਿਹੜੇ ਹਿੱਸੇ ਦੀ ਮਾਲਕੀ ਹੈ ਅਤੇ ਕੀ ਉਹ ਉਹੀ ਨਿਰਗਮ ਨਿਯਮ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ। ਫਿਰ RPC ਦੇਖੋ: ਜੇ rpc-whitelist ਵਰਤੋਂ ਵਿੱਚ ਹੈ ਤਾਂ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਪ੍ਰਬੰਧਨ ਨੈੱਟਵਰਕ ਸਮਝੌਤੇ ਦਾ ਹਿੱਸਾ ਹੈ, ਅਤੇ ਵਿਆਪਕ RFC1918 ਰੇਂਜ ਨਹੀਂ।
ss -tunp | grep -i transmission
ਇੰਟਰਫੇਸ ਕਾਊਂਟਰ ਨਿਰੀਖਣ ਦਾ ਸਮਰਥਨ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰ ਸਕਦੇ ਕਿ ਕਿਸ ਪ੍ਰਕਿਰਿਆ ਨੇ ਬਾਈਟ ਬਣਾਏ। ਅਜਿਹਾ ਟ੍ਰਾਂਸਫਰ ਕਰੋ ਜਿਸਨੂੰ ਛੱਡਣ ਦੀ ਆਗਿਆ ਹੈ: ਪਹਿਲਾਂ ਕੰਮ ਕਰਨ ਵਾਲੇ ਰਸਤੇ ’ਤੇ, ਫਿਰ ਸ਼ੁਰੂਆਤ ’ਤੇ ਟਨਲ ਤੋਂ ਬਿਨਾਂ, ਫਿਰ ਰੁਕਾਵਟ, ਮੁੜ ਜੁੜਨ ਅਤੇ ਨਵੇਂ ਬਣੇ ਇੰਟਰਫੇਸ ਰਾਹੀਂ। ਨਵੀਂ ਕੋਸ਼ਿਸ਼ ਅਤੇ ਪਹਿਲਾਂ ਹੀ ਖੁੱਲ੍ਹਾ ਕਨੈਕਸ਼ਨ ਦੋਵੇਂ ਪਰਖੋ, ਕਿਉਂਕਿ ਨਿਯਮ ਪੁਰਾਣੇ ਸਾਕਟ ’ਤੇ ਲਾਗੂ ਨਾ ਹੋਇਆ ਹੋ ਸਕਦਾ ਹੈ। ਤਾਰੀਖ, ਖਾਤਾ ਅਤੇ ਨਤੀਜਾ ਪਰਖ ਨਾਲ ਦਰਜ ਕਰੋ।
ਪੂਰੀ ਚੇਨ ਸਾਫ਼ ਕਰਨ ਵਾਲਾ ਉਦਾਹਰਨ ਚਿਪਕਾਉਣਾ ਇੱਕ ਮੋਰੀ ਦੀ ਥਾਂ ਕਈ ਮੋਰੀਆਂ ਦੇ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਨਿਯਮ ਮਿਟਾਉਣ ਦੀ ਥਾਂ ਜੋੜੋ। ਜਦੋਂ ਪੰਜੇ ਜਾਂਚਾਂ ਪਾਸ ਹੋ ਜਾਣ, ਗਾਰੰਟੀ ਸਪਸ਼ਟ ਹੈ: ਕਲਾਇੰਟ ਦਾ ਟ੍ਰੈਫਿਕ ਟਨਲ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦਾ ਹੈ ਜਾਂ ਬਿਲਕੁਲ ਨਹੀਂ ਜਾਂਦਾ, ਅਤੇ ਜੋ ਨਿਯਮ ਇਸਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ ਉਹ ਟਨਲ ਦੀ ਆਪਣੀ ਫੇਲ੍ਹ ਨੂੰ ਵੀ ਝੱਲ ਲੈਂਦਾ ਹੈ।