VPS ਫਾਇਰਵਾਲ: ਸਿਰਫ਼ VPN ਪੋਰਟ ਖੋਲ੍ਹੋ, ਫਿਰ ਇਸ ਨੂੰ ਸਾਬਤ ਕਰੋ

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

ਇੱਕੋ ਪੋਰਟ ਜੋ ਬੰਦ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ

VPN ਸਰੋਤਾ ਨੂੰ ਅਜਿਹੇ ਪਤਿਆਂ ਤੋਂ ਕਨੈਕਸ਼ਨ ਸਵੀਕਾਰ ਕਰਨੇ ਪੈਂਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ ਤੁਸੀਂ ਪਹਿਲਾਂ ਅੰਦਾਜ਼ਾ ਨਹੀਂ ਲਾ ਸਕਦੇ, ਇਸ ਲਈ ਇਹ ਪਰਿਭਾਸ਼ਾ ਅਨੁਸਾਰ ਜਨਤਕ ਸੇਵਾ ਹੈ। ਡਿਜ਼ਾਈਨ ਇਸੇ ਇੱਕ ਅਪਵਾਦ 'ਤੇ ਟਿਕਿਆ ਹੈ: OpenVPN ਲਈ ਇੱਕ UDP ਪੋਰਟ, WireGuard ਲਈ ਇੱਕ UDP ਪੋਰਟ, SSL VPN ਲਈ ਇੱਕ TCP ਪੋਰਟ। ਬਾਕੀ ਸਭ ਟਨਲ ਦੇ ਪਿੱਛੇ ਹੈ, ਭਾਵ ਐਪਲੀਕੇਸ਼ਨ ਸੇਵਾਵਾਂ ਨੂੰ ਹਰ ਇੰਟਰਫੇਸ ਦੀ ਥਾਂ ਟਨਲ ਪਤੇ ਜਾਂ loopback ਨਾਲ ਬੱਝਣਾ ਚਾਹੀਦਾ ਹੈ।

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

ਇਨਪੁਟ, ਫਾਰਵਰਡ ਅਤੇ NAT ਵੱਖਰੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੇ ਹਨ

ਇਨਪੁਟ ਟ੍ਰੈਫ਼ਿਕ ਹੋਸਟ ਲਈ ਹੀ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ VPN ਸਰੋਤਾ ਅਤੇ ਪ੍ਰਸ਼ਾਸਕੀ ਰਾਹ ਉੱਥੇ ਹੀ ਰਹਿੰਦੇ ਹਨ। ਫਾਰਵਰਡ ਟ੍ਰੈਫ਼ਿਕ ਹੋਸਟ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ, ਅਤੇ ਟਨਲ ਕਲਾਇੰਟਾਂ ਨੂੰ ਇਹ net.ipv4.ip_forward=1 ਦੇ ਨਾਲ ਚਾਹੀਦਾ ਹੈ। ਰਵਾਇਤੀ ਅੱਧ-ਟੁੱਟੀ ਸੰਰਚਨਾ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਵਹਾਅ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ ਅਤੇ ਵਾਪਸੀ ਦੀ ਦਿਸ਼ਾ ਭੁੱਲ ਜਾਂਦੀ ਹੈ, ਇਸ ਲਈ ਕਲਾਇੰਟ ਹੈਂਡਸ਼ੇਕ ਪੂਰਾ ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਕੁਝ ਲੋਡ ਨਹੀਂ ਹੁੰਦਾ; ਸਥਾਪਿਤ ਅਤੇ ਸੰਬੰਧਿਤ ਟ੍ਰੈਫ਼ਿਕ ਲਈ conntrack ਨਿਯਮ ਉਸ ਦਿਸ਼ਾ ਨੂੰ ਢਕਦਾ ਹੈ।

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

IPv6 ਦੂਜੀ ਨੀਤੀ ਹੈ, ਬਾਅਦ ਦਾ ਵਿਚਾਰ ਨਹੀਂ। ਸਖ਼ਤ IPv4 ਚੇਨ ਅਤੇ ip6tables 'ਤੇ ਖੁੱਲ੍ਹੀ ਨੀਤੀ ਵਾਲੇ ਹੋਸਟ ਨੇ ਕੁਝ ਵੀ ਬੰਦ ਨਹੀਂ ਕੀਤਾ; ਸੇਵਾਵਾਂ ਦੂਜੇ ਪਰਿਵਾਰ ਰਾਹੀਂ ਅਜੇ ਵੀ ਪਹੁੰਚਯੋਗ ਹਨ। ਇੱਕ ਜਾਂ ਤਾਂ ip6tables ਨਾਲ ਨਿਯਮ-ਸਮੂਹ ਦਾ ਪ੍ਰਤੀਬਿੰਬ ਬਣਾਓ, ਜਾਂ ਜਨਤਕ ਇੰਟਰਫੇਸ 'ਤੇ IPv6 ਜਾਣ-ਬੁੱਝ ਕੇ ਬੰਦ ਕਰੋ, ਅਤੇ ਲਿਖੋ ਕਿ ਤੁਸੀਂ ਕਿਹੜਾ ਚੁਣਿਆ।

ਇੱਕ ਵਾਰ ਪੜ੍ਹਨ ਵਿੱਚ ਆਉਣ ਵਾਲਾ ਆਧਾਰ

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

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -p udp --dport 1194 -m conntrack --ctstate NEW -j ACCEPT
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o eth0 -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

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

ਹੋਸਟ ਗੁਆਏ ਬਿਨਾਂ ਆਖਰੀ ਪੋਰਟ ਬੰਦ ਕਰਨਾ

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

ਬਦਲਾਅ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਸਥਾਪਿਤ ਸੈਸ਼ਨ ਤੋਂ ਲਾਗੂ ਕਰੋ, ਤੁਸੀਂ ਜਿਸ ਕਨੈਕਸ਼ਨ ਨੂੰ ਫਿਲਟਰ ਕਰਨ ਲੱਗੇ ਹੋ ਉਸ ਰਾਹੀਂ ਨਹੀਂ। ਰੋਲਬੈਕ ਦਾ ਸਮਾਂ ਤੈਅ ਕਰੋ ਤਾਂ ਜੋ ਗਲਤੀ ਪੱਕੀ ਹੋਣ ਦੀ ਥਾਂ ਖ਼ਤਮ ਹੋ ਜਾਵੇ, ਉਦਾਹਰਣ ਲਈ ਪਿਛਲੇ ਨਿਯਮ-ਸਮੂਹ ਨੂੰ ਬਹਾਲ ਕਰਨ ਵਾਲਾ systemd-run --on-active=10min ਕੰਮ, ਅਤੇ ਪਹਿਲੇ ਦੀ ਪਰਖ ਕਰਦੇ ਸਮੇਂ ਦੂਜਾ SSH ਸੈਸ਼ਨ ਖੁੱਲ੍ਹਾ ਰੱਖੋ। ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਰੋਲਬੈਕ ਕੰਮ ਸੱਚਮੁੱਚ ਚੱਲਦਾ ਹੈ, ਕਿਉਂਕਿ ਨਾ-ਪਰਖੀ ਰਿਕਵਰੀ ਰਿਕਵਰੀ ਨਾ ਹੋਣ ਦੇ ਬਰਾਬਰ ਹੈ।

ਸਕ੍ਰਿਪਟ ਨਹੀਂ, ਰਾਹ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

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

iptables -S
iptables -t nat -S
ss -lntup
ip -4 addr show

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

ਇੱਕ ਆਦਤ ਨਿਯਮ-ਸਮੂਹ ਨਾਲੋਂ ਵੱਧ ਕੀਮਤੀ ਹੈ: ਹਰ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਕਲਾਇੰਟ ਬੇਨਤੀ ਨਾਲ ਫਾਰਵਰਡ ਰਾਹ ਅਤੇ ਦੂਜੇ ਸੈਸ਼ਨ ਨਾਲ ਰਿਕਵਰੀ ਰਾਹ ਸਾਬਤ ਕਰੋ। ਜੋ ਲਾਕਡਾਊਨ ਤੁਸੀਂ ਵਰਤਿਆ ਨਹੀਂ, ਉਹ ਸਿਰਫ਼ ਇੱਕ ਅਨੁਮਾਨ ਹੈ।