OpenVPN ਕਲਾਇੰਟ ਬਲਾਕ ਨਿਯਮ FORWARD ਤੱਕ ਕਿਉਂ ਨਹੀਂ ਪਹੁੰਚਦਾ

ਇੱਕੋ OpenVPN ਸਰਵਰ ਦੇ ਦੋ ਕਲਾਇੰਟ ਆਪਣੇ ਪੂਲ ਲਈ DROP ਨਿਯਮ ਜੋੜਨ ਤੋਂ ਬਾਅਦ ਵੀ ਇੱਕ-ਦੂਜੇ ਤੱਕ ਪਹੁੰਚ ਸਕਦੇ ਹਨ। ਨਿਯਮ FORWARD ਚੇਨ ਵਿੱਚ ਬੈਠਾ ਹੈ, ਟ੍ਰੈਫਿਕ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਵਹਿ ਰਿਹਾ ਹੈ, ਅਤੇ ਉਸ ਨਿਯਮ ਦਾ ਕਾਊਂਟਰ ਸਿਫ਼ਰ 'ਤੇ ਹੀ ਰਹਿੰਦਾ ਹੈ। ਸੁਭਾਵਿਕ ਸਿੱਟਾ ਇਹ ਹੈ ਕਿ ਫਾਇਰਵਾਲ ਟੁੱਟੀ ਹੋਈ ਹੈ। ਬਹੁਤੀਆਂ ਵਾਰ ਪੈਕੇਟ ਚੇਨ ਵਿੱਚ ਆਇਆ ਹੀ ਨਹੀਂ।

OpenVPN ਸਰਵਰ ਰਾਹੀਂ ਪੀਅਰ ਪੈਕੇਟ ਦੋ ਰਾਹਾਂ ਲੰਘ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਨੂੰ ਕਾਨਫਿਗਰੇਸ਼ਨ ਤੈਅ ਕਰਦਾ ਹੈ, ਫਾਇਰਵਾਲ ਨਹੀਂ। ਕਿਹੜਾ ਰਾਹ ਵਰਤਿਆ ਜਾ ਰਿਹਾ ਹੈ, ਇਹ ਜਾਣਨਾ ਦੱਸਦਾ ਹੈ ਕਿ ਹੋਸਟ ਨਿਯਮ ਠੀਕ ਥਾਂ 'ਤੇ ਹੈ ਜਾਂ ਨਹੀਂ।

ਪੀਅਰ ਪੈਕੇਟ ਜਾ ਸਕਣ ਵਾਲੇ ਦੋ ਰਾਹ

ਜਦੋਂ ਅੰਦਰੂਨੀ ਫਾਰਵਰਡਿੰਗ ਚੋਣ ਬੰਦ ਹੁੰਦੀ ਹੈ, ਕਲਾਇੰਟ A ਦਾ ਪੈਕੇਟ ਟਨਲ ਇੰਟਰਫ਼ੇਸ 'ਤੇ ਆਉਂਦਾ ਹੈ ਅਤੇ ਇਸਦੀ ਮੰਜ਼ਿਲ ਕਲਾਇੰਟ B ਨੂੰ ਦਿੱਤੇ ਐਡਰੈਸ ਦੇ ਅੰਦਰ ਹੁੰਦੀ ਹੈ। ਸਰਵਰ ਦੀ ਰੂਟਿੰਗ ਟੇਬਲ ਇਸਨੂੰ ਉਸੇ ਟਨਲ ਇੰਟਰਫ਼ੇਸ ਰਾਹੀਂ ਵਾਪਸ ਭੇਜਦੀ ਹੈ, ਕਿਉਂਕਿ B ਦੇ ਐਡਰੈਸ ਤੱਕ ਰੂਟ ਸਰਵਰ ਦਾ ਹੈ। ਇਹ ਹੋਸਟ ਰਾਹੀਂ ਅੰਦਰ-ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਪ੍ਰਵਾਹ ਹੈ, ਅਤੇ IPv4 ਫਾਰਵਰਡਿੰਗ ਰਾਹ ਇਸਦਾ ਮੁਲਾਂਕਣ ਕਰਦਾ ਹੈ।

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

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

ਜਦੋਂ ਕਾਊਂਟਰ ਕਦੇ ਨਹੀਂ ਹਿਲਦਾ

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

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

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

ਫਿਲਟਰ ਕਰ ਸਕਣ ਵਾਲੀ ਸੀਮਾ ਚੁਣਨਾ

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

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

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

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

ਨਿਯਮ 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਬਜਾਏ ਅਲੱਗਾਅ ਜਾਂਚਣਾ

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

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

ਅਲੱਗਾਅ ਉਸ ਸੀਮਾ 'ਤੇ ਦੇਖਿਆ ਨਤੀਜਾ ਹੈ ਜੋ ਅਸਲ ਵਿੱਚ ਪ੍ਰਵਾਹ ਢੋਂਦੀ ਹੈ। ਹੋਸਟ ਵਿੱਚ ਕਿਤੇ DROP ਨਿਯਮ ਸਬੂਤ ਨਹੀਂ ਹੈ; ਫੇਲ੍ਹ ਹੋਇਆ ਕਨੈਕਸ਼ਨ ਅਤੇ ਇਸਦਾ ਕਾਰਨ ਬਣੇ ਨਿਯਮ ਦਾ ਹਿਲਿਆ ਕਾਊਂਟਰ ਸਬੂਤ ਹੈ।