ਸਿਰਫ਼ VPN ਵਾਲਾ iptables ਹੋਸਟ: tun ਡਿਵਾਈਸ ਦਾ ਨਾਂ ਦਿਓ, tun+ ਨਹੀਂ

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

ਕਦਮ 1: ਹੁਣ ਜੋ ਨਿਯਮ ਹਨ ਉਹ ਲਿਖ ਲਓ

ਡਿਫ਼ਾਲਟ ਨੀਤੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਮੌਜੂਦਾ ਹਾਲਤ ਸੰਭਾਲੋ, ਤਾਂ ਜੋ ਰੋਲਬੈਕ ਯਾਦ ਨਹੀਂ ਸਗੋਂ ਹੁਕਮ ਬਣੇ। iptables-save > /root/iptables.pre ਹਰ ਟੇਬਲ ਨੂੰ ਅਜਿਹੀ ਫਾਈਲ ਵਿੱਚ ਲਿਖਦਾ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਮੁੜ-ਸਥਾਪਿਤ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ ਜੋ ਨੀਤੀ ਸੈੱਟ ਕਰਨ ਵਾਲੇ ਹੋ ਉਹ ਉਸ ਨੂੰ ਢੋਣ ਵਾਲਾ ਕਨੈਕਸ਼ਨ ਡੇਗ ਦੇਵੇ, ਤਦ ਖੁੱਲ੍ਹੀ root ਸੈਸ਼ਨ ਵਾਲਾ ਦੂਜਾ ਟਰਮੀਨਲ ਸ਼ੱਕ ਨਹੀਂ ਹੈ। ਜੇ ਤੁਸੀਂ ਦੂਰੋਂ ਕੰਮ ਕਰਦੇ ਹੋ, ਤਾਂ flush ਵੀ ਐਮਰਜੈਂਸੀ ਸਵਿੱਚ ਵਜੋਂ ਤਹਿ ਕਰੋ।

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

ਕਦਮ 2: ਟਨਲ ਨੂੰ ਆਪਣਾ ਨਾਂ ਦਿਓ

OpenVPN ਕਲਾਇੰਟ ਕਨਫ਼ਿਗਰੇਸ਼ਨ ਵਿੱਚ dev tun_work ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ Linux tun0 ਅਲਾਟ ਕਰਨ ਦੀ ਥਾਂ ਠੀਕ ਉਸੇ ਨਾਂ ਵਾਲਾ ਇੰਟਰਫੇਸ ਬਣਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਤੱਕ ਹੋਰ ਕੋਈ ਇਸ 'ਤੇ ਦਾਅਵਾ ਨਹੀਂ ਕਰਦਾ, ਨਾਂ ਮੁੜ-ਕਨੈਕਟ ਦੌਰਾਨ ਸਥਿਰ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਡਿਵਾਈਸ ਦਾ ਨਾਂ ਲੈਣ ਵਾਲੇ ਨਿਯਮ ਨੂੰ ਅਰਥਪੂਰਨ ਬਣਾਉਂਦਾ ਇਹੀ ਹੈ।

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

ਕਦਮ 3: endpoint ਅਪਵਾਦ ਪਹਿਲਾਂ ਰੱਖ ਕੇ ਨੀਤੀ ਲਿਖੋ

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

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

endpoint ਦਾ ਸ਼ਬਦੀ ਪਤਾ ਅਤੇ ਪੋਰਟ ਤੁਹਾਡੇ ਪ੍ਰਦਾਤਾ ਦੇ ਹਨ, ਇਸ ਪੰਨੇ ਦੇ ਨਹੀਂ। ਜੇ endpoint ਹੋਸਟਨਾਂ ਹੈ, ਤਾਂ ਇੱਕ ਵਾਰ ਹੱਲ ਕਰੋ ਅਤੇ ਨਤੀਜਾ ਤੈਅ ਕਰੋ, ਕਿਉਂਕਿ ਨਿਯਮ ਨਾਂ ਨਹੀਂ ਲੱਭ ਸਕਦਾ ਅਤੇ ਘੁੰਮਦਾ ਜਵਾਬ ਅਗਲੀ DNS ਤਬਦੀਲੀ ਤੋਂ ਬਾਅਦ ਨੀਤੀ ਚੁੱਪਚਾਪ ਤੋੜ ਦੇਵੇਗਾ। ਪੋਰਟ ਵੀ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਤੁਹਾਨੂੰ TCP 443 'ਤੇ ਭੇਜਣ ਵਾਲੇ ਪ੍ਰਦਾਤਾਵਾਂ ਨੂੰ ਵਰਨਾ ਅਜਿਹਾ ਨਿਯਮ ਚਾਹੀਦਾ ਹੈ ਜੋ ਕਿਸੇ ਨੇ ਨਹੀਂ ਲਿਖਿਆ। ਸਿਰਫ਼ ਇੱਕ ਪ੍ਰੋਟੋਕਾਲ 'ਤੇ ਚੱਲਣ ਵਾਲੀ ਟਨਲ ਆਮ ਤੌਰ 'ਤੇ ਇਹੀ ਖੁੰਝ ਹੁੰਦੀ ਹੈ, ਫਾਇਰਵਾਲ ਦੀ ਖਰਾਬੀ ਨਹੀਂ।

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

ਕਦਮ 4: ਸਿਰਫ਼ ਮੌਜੂਦਗੀ ਨਹੀਂ, ਕ੍ਰਮ ਵੀ ਜਾਂਚੋ

ਨਿਯਮ ਕ੍ਰਮ ਵਿੱਚ ਮੁਲਾਂਕਣ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਪਹਿਲਾਂ ਆਉਣ ਵਾਲਾ ACCEPT ਬਾਅਦ ਵਿੱਚ ਜੋੜੇ REJECT ਨੂੰ ਬੱਸ ਲੁਕਾ ਦਿੰਦਾ ਹੈ। established ਅਤੇ related ਮੇਲ ਹੀ ਆਮ ਆਉਣ ਵਾਲਾ ਰਾਹ ਖੋਲ੍ਹੇ ਬਿਨਾਂ ਤੁਹਾਡੇ ਆਪਣੇ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਬੇਨਤੀਆਂ ਦੇ ਜਵਾਬ ਵਾਪਸ ਆਉਣ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇਸ ਨੂੰ ਟਨਲ ਸਵੀਕ੍ਰਿਤੀ ਤੋਂ ਬਾਅਦ ਰੱਖਣ ਦਾ ਅਰਥ ਹੈ ਕਿ ਡਿੱਗੀ ਟਨਲ ਵੀ ਆਪਣੇ ਇੰਟਰਫੇਸ 'ਤੇ ਵਾਪਸੀ ਟ੍ਰੈਫਿਕ ਲੰਘਾਉਂਦੀ ਹੈ।

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

ਕਦਮ 5: ਇਸ ਨੂੰ ਬੂਟ ਅਤੇ ਪਤਾ ਪਰਿਵਾਰ ਦੋਵੇਂ ਝੱਲਣ ਯੋਗ ਬਣਾਓ

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

ਫਿਰ IPv6 ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਜਾਂਚੋ, ਕਿਉਂਕਿ IPv4 ਲਈ ਚੰਗੀ ਡਿਫ਼ਾਲਟ-ਇਨਕਾਰ ਨੀਤੀ ਦੂਜੇ ਪਰਿਵਾਰ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ। ip -6 route ਤੁਹਾਨੂੰ ਦੱਸੇਗਾ ਕਿ ਹੋਸਟ ਕੋਲ ਅਜਿਹਾ ਰਾਹ ਹੈ ਜੋ ਸਿਰਫ਼ IPv4 ਸੰਭਾਲਣ ਵਾਲੀ ਟਨਲ ਦੁਆਲੇ ਟ੍ਰੈਫਿਕ ਲੈ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ip6tables ਜਾਂ nftables ਨੂੰ ਆਪਣੇ ਬਰਾਬਰ ਨਿਯਮ ਚਾਹੀਦੇ ਹਨ। ਨਿਯਮ-ਸਮੂਹ ਦੀ ਸਮਰੂਪਤਾ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਥਾਂ IPv6-only ਮੰਜ਼ਿਲ ਨਾਲ ਪਰਖੋ।

ਕਦਮ 6: ਪਰਖੋ ਅਤੇ ਮੁੜ-ਸਥਾਪਿਤ ਕਰਨ ਲਈ ਤਿਆਰ ਰਹੋ

ਟਨਲ ਉੱਪਰ ਲਿਆਓ, ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤੁਹਾਡੀ ਲੋੜੀਂਦੀ ਸੇਵਾ ਕੰਮ ਕਰਦੀ ਹੈ, ਫਿਰ ਕੁਝ ਅਜਿਹਾ ਅਜ਼ਮਾਓ ਜਿਸ ਨੂੰ ਨੀਤੀ ਨੇ ਇਨਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਜਵਾਬ ਤੁਹਾਨੂੰ ਹੈਰਾਨ ਕਰੇ ਤਾਂ iptables-restore < /root/iptables.pre ਨਾਲ ਮੁੜ-ਸਥਾਪਿਤ ਕਰੋ, ਅਤੇ ਫਿਰ ਹੀ ਨਿਯਮ ਸੰਪਾਦਿਤ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰੋ। ਟਿਕਾਊਪਣ ਅਤੇ ਪਰਖਿਆ ਮੁੜ-ਸਥਾਪਨਾ ਰਾਹ ਹੀ ਇਸ ਨੂੰ ਦੋ ਵਾਰ ਕਰਨ ਯੋਗ ਬਦਲਾਅ ਬਣਾਉਂਦੇ ਹਨ।