nginx ਟੁੱਟਣ ਤੋਂ ਪਹਿਲਾਂ OpenVPN SNAT ਨਿਯਮ ਦਾ ਦਾਇਰਾ ਤੈਅ ਕਰੋ

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

ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਕੰਟੇਨਰ tun ਡਿਵਾਈਸ ਬਣਾ ਸਕਦਾ ਹੈ

ਜੇ ਟਨਲ ਇੰਟਰਫੇਸ ਬਣ ਹੀ ਨਹੀਂ ਸਕਦਾ ਤਾਂ ਹੋਰ ਕੁਝ ਮਾਅਨੇ ਨਹੀਂ ਰੱਖਦਾ। ਜਾਂਚੋ ਕਿ /dev/net/tun ਮੌਜੂਦ ਹੈ ਅਤੇ ਟੈਸਟ ਡਿਵਾਈਸ ਬਣਾਉਣਾ ਸਫਲ ਹੁੰਦਾ ਹੈ, ਕਿਉਂਕਿ ਕਈ ਪ੍ਰਦਾਤਾ ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ ਕੰਟੇਨਰਾਂ ਅੰਦਰ tun ਬੰਦ ਰੱਖਦੇ ਹਨ। ਕਦੇ ਨਾ ਬਣੇ ਡਿਵਾਈਸ ਦੀ ਭਰਪਾਈ ਕੋਈ firewall ਕੰਮ ਨਹੀਂ ਕਰਦਾ।

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

ਤੈਅ ਕਰੋ ਕਿ ਇਸ ਇੰਟਰਫੇਸ ਉੱਤੇ MASQUERADE ਕੀ ਕਰਦਾ ਹੈ

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

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

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

ਨਿਯਮ ਨੂੰ ਇੱਕ pool ਅਤੇ ਇੱਕ ਇੰਟਰਫੇਸ ਤੱਕ ਸੀਮਤ ਕਰੋ

ਦੂਜੇ ਲੱਛਣ ਦਾ ਕਾਰਨ ਵੱਖਰਾ ਹੈ: ਸਰੋਤ ਜਾਂ ਆਉਟਪੁੱਟ ਪਾਬੰਦੀ ਤੋਂ ਬਿਨਾਂ POSTROUTING ਨਿਯਮ। ਅਜਿਹਾ ਨਿਯਮ ਹੋਸਟ ਛੱਡਣ ਵਾਲੇ ਹਰ ਪੈਕੇਟ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਦਾ ਹੈ।

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

ਹੱਲ ਇਹ ਹੈ ਕਿ ਮੇਲ ਨੂੰ ਟਨਲ pool ਅਤੇ ਈਗ੍ਰੈਸ ਇੰਟਰਫੇਸ ਤੱਕ ਸੰਕੁਚਿਤ ਕਰੋ, ਫਿਰ ਕਈਆਂ ਨੂੰ ਢੱਕਣ ਲਈ ਇੱਕ ਨਿਯਮ ਚੌੜਾ ਕਰਨ ਦੀ ਥਾਂ ਹਰ pool ਲਈ ਇੱਕ ਨਿਯਮ ਜੋੜੋ।

ਨਿਯਮਾਂ ਨੂੰ ਸਥਾਈ ਬਣਾਓ ਅਤੇ ਜਾਣੋ ਕਿ ਇਹਨਾਂ ਦਾ ਹੋਰ ਕੌਣ ਮਾਲਕ ਹੈ

ਹੱਥ ਨਾਲ ਜੋੜੇ ਨਿਯਮ ਰੀਬੂਟ ਉੱਤੇ ਗਾਇਬ ਹੋ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਇਹਨਾਂ ਨੂੰ iptables-save ਨਾਲ ਸੰਭਾਲੋ ਜਾਂ ਜਿੱਥੇ ਇਹ ਸਥਾਪਿਤ ਹੈ ਉੱਥੇ netfilter-persistent ਰਾਹੀਂ ਪ੍ਰਬੰਧਿਤ ਕਰੋ। ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਬਹਾਲੀ OpenVPN ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਚੱਲਦੀ ਹੈ। ਫਿਰ ਘਟਨਾ ਦੇ ਦੌਰਾਨ ਖਾਲੀ ਥਾਂ ਲੱਭਣ ਦੀ ਥਾਂ ਜਾਣ-ਬੁੱਝ ਕੇ ਇੱਕ ਵਾਰ ਰੀਬੂਟ ਕਰੋ।

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

ਕਾਊਂਟਰਾਂ ਅਤੇ ਇੱਕ ਕੈਪਚਰ ਕੀਤੇ ਫਲੋ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ

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

ਸਰਵਰ ਉੱਤੇ iptables -t nat -L -v -n ਨਾਲ NAT ਅਤੇ FORWARD ਨਿਯਮਾਂ ਦੇ ਪੈਕੇਟ ਕਾਊਂਟਰ ਪੜ੍ਹੋ ਅਤੇ ਕੈਪਚਰ ਵਿੱਚ ਇੱਕ ਫਲੋ ਵੇਖੋ। ਜੇ ਕੈਪਚਰ ਵਿੱਚ ਕਲਾਇੰਟ ਦਾ ਪਤਾ ਦਿਖਦਾ ਹੈ ਅਤੇ ਕੋਈ ਜਵਾਬ ਨਹੀਂ ਆਉਂਦਾ, ਤਾਂ ਖਾਲੀ ਥਾਂ ਵਾਪਸੀ ਰਾਹ ਉੱਤੇ ਜਾਂ ਪ੍ਰਦਾਤਾ ਦੀ ਫਿਲਟਰਿੰਗ ਵਿੱਚ ਹੈ, ਕਲਾਇੰਟ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਨਹੀਂ। ਕੈਪਚਰ ਕੀਤੇ ਸਰੋਤ ਦੀ ਤੁਲਨਾ ਉਸ ਪਤੇ ਨਾਲ ਕਰੋ ਜਿਸ ਉੱਤੇ ਨਿਯਮ ਅਨੁਵਾਦ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ ਬੇਮੇਲ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕੋਈ ਹੋਰ ਨਿਯਮ ਪਹਿਲਾਂ ਮੇਲ ਖਾਧਾ। ਇੱਕ ਦੇਖਿਆ ਗਿਆ ਫਲੋ ਕੌਂਫਿਗਰੇਸ਼ਨ ਪੜ੍ਹਨ ਦੇ ਇੱਕ ਪੰਨੇ ਤੋਂ ਵੱਧ ਤੈਅ ਕਰਦਾ ਹੈ।

pool, ਅਨੁਵਾਦਿਤ ਪਤਾ ਅਤੇ ਇੰਟਰਫੇਸ ਦਾ ਨਾਮ ਬਦਲਾਅ ਰਿਕਾਰਡ ਵਿੱਚ ਇਕੱਠੇ ਰੱਖੋ। ਇੱਕ pool ਲਈ ਸਹੀ ਨਿਯਮ ਅਗਲੇ ਦਾ ਗਲਤ ਅਨੁਵਾਦ ਕਰਦਾ ਹੈ।