firewalld ਸੁਣਨ ਵਾਲੇ ਦਾ ਨਿਯਮ ਅਤੇ ਫਾਰਵਰਡਿੰਗ ਨੀਤੀ: ਹਰ ਇੱਕ ਕੀ ਕਰਦਾ ਹੈ

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

ਦੋ ਨੀਤੀਆਂ, ਇੱਕ ਟਨਲ

ਬਾਹਰੀ ਨੀਤੀ ਇੱਕ ਸਧਾਰਨ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ: ਕੀ ਇਸ ਸਰੋਤ ਤੋਂ ਆਉਣ ਵਾਲਾ ਪੈਕਟ ਇਸ ਹੋਸਟ ਤੇ UDP 1194 ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ? ਅੰਦਰੂਨੀ ਨੀਤੀ ਦੂਜੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ: ਕੀ ਉਸ ਟਨਲ ਪਿੱਛੇ ਦਾ ਪ੍ਰਮਾਣਿਤ ਕਲਾਇੰਟ ਇਸ ਮੰਜ਼ਿਲ ਤੱਕ, ਇਸ ਪ੍ਰੋਟੋਕੋਲ ਨਾਲ, ਇਸ ਪੋਰਟ ਤੇ ਪਹੁੰਚ ਸਕਦਾ ਹੈ? ਪਹਿਲੀ ਸਾਕਟ ਬਾਰੇ ਹੈ, ਦੂਜੀ ਮਾਰਗ ਬਾਰੇ, ਅਤੇ firewalld ਉਹਨਾਂ ਨੂੰ ਵੱਖਰੀਆਂ ਵਸਤੂਆਂ ਨਾਲ ਮਾਡਲ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਉਹ ਵੱਖਰੇ ਬਿੰਦੂਆਂ ਤੇ ਤੈਅ ਹੁੰਦੀਆਂ ਹਨ। ਇੱਕ ਇਸ ਹੋਸਟ ਦੇ ਸਾਕਟ ਦਾ ਗੁਣ ਹੈ, ਦੂਜੀ ਇਸ ਵਿੱਚੋਂ ਲੰਘਣ ਵਾਲੇ ਮਾਰਗ ਦਾ।

ਵਿਹਾਰਕ ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ ਕੰਮ ਕਰਦਾ ਟਨਲ ਦੂਜੀ ਨੀਤੀ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ, ਅਤੇ ਸਹੀ ਦੂਜੀ ਨੀਤੀ ਪਹਿਲੀ ਨੂੰ ਬੇਲੋੜਾ ਨਹੀਂ ਬਣਾਉਂਦੀ।

ਅਸਲ ਬਾਹਰੀ ਸੁਣਨ ਵਾਲੇ ਨੂੰ ਇਜਾਜ਼ਤ ਦਿਓ

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

firewall-cmd --get-active-zones
firewall-cmd --zone=public --list-all
firewall-cmd --info-service=openvpn

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

ਡੀਕ੍ਰਿਪਟ ਕੀਤੀ ਮੰਜ਼ਿਲ ਨੂੰ ਵੱਖਰੇ ਤੌਰ ਤੇ ਅਧਿਕਾਰ ਦਿਓ

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

ਮਨਜ਼ੂਰ ਸਰੋਤਾਂ ਨੂੰ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਅਤੇ ਬਾਕੀ ਸਭ ਨੂੰ ਇਨਕਾਰ ਵਿੱਚ ਡਿੱਗਣ ਦਿਓ। ਬਾਹਰੀ ਸੇਵਾ ਲਈ ਇਜਾਜ਼ਤ ਉਹ ਨੀਤੀ ਨਹੀਂ ਹੈ, ਜ਼ੋਨ ਦੀ ਬਣਾਵਟ ਕੈਸੀ ਵੀ ਦਿਸੇ।

ਇੰਟਰਫੇਸ ਤੇ ਭਰੋਸਾ ਕਰਨਾ ਗਲਤ ਛੋਟਾ ਰਾਹ ਕਿਉਂ ਹੈ

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

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

ਤਿੰਨ ਚੀਜ਼ਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਇੱਕ ਇਨਕਾਰ ਵੀ

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

ਸਰਵਰ ਦੇ ਨੋਟਾਂ ਵਿੱਚ ਜ਼ੋਨ, ਪੋਰਟ, ਟ੍ਰਾਂਸਪੋਰਟ ਅਤੇ ਨੀਤੀ ਵਸਤੂ ਦਰਜ ਕਰੋ। ਨਹੀਂ ਤਾਂ ਇਸ ਹੋਸਟ ਤੇ ਅਗਲੀ ਤਬਦੀਲੀ ਉਸੇ ਅਨੁਮਾਨ ਤੋਂ ਸ਼ੁਰੂ ਹੋਵੇਗੀ।