VPN ਕਲਾਇੰਟ ਅਤੇ LAN: ਕਦੋਂ ਵੱਖਰਾ ਜ਼ੋਨ ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ

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

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

ਜ਼ੋਨ ਮੈਂਬਰਸ਼ਿਪ ਅਸਲ ਵਿੱਚ ਕੀ ਨਿਯੰਤਰਿਤ ਕਰਦੀ ਹੈ

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

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

ਇਹੀ ਫ਼ਰਕ ਵੱਖਰੇ ਜ਼ੋਨ ਦੇ ਲਾਹੇਵੰਦ ਹੋਣ ਦਾ ਕਾਰਨ ਹੈ: ਤੁਸੀਂ ਹਰ ਦਿਸ਼ਾ ਅਤੇ ਹਰ ਭੂਮਿਕਾ ਸਪਸ਼ਟ ਲਿਖ ਸਕਦੇ ਹੋ। ਹਰ ਨਿਯਮ ਦੇ ਕੋਲ ਦਿਸ਼ਾ ਲਿਖੋ।

ਪਹਿਲਾ ਫੈਸਲਾ: ਇਨਪੁਟ, ਫਾਰਵਰਡ ਜਾਂ ਦੋਵੇਂ

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

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

ਦੂਜਾ ਫੈਸਲਾ: ਦੂਰਸਥ ਕਲਾਇੰਟਾਂ ਨੂੰ ਕਿਹੜੇ ਸਰੋਤ ਚਾਹੀਦੇ ਹਨ

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

ਪ੍ਰਬੰਧਨ ਇੰਟਰਫੇਸ ਨੂੰ ਆਮ ਐਪਲੀਕੇਸ਼ਨ ਪਹੁੰਚ ਤੋਂ ਵੱਖਰਾ ਰੱਖੋ। ਵਿਕੀ ਤੱਕ ਪਹੁੰਚਣ ਵਾਲੇ ਦੂਰਸਥ ਕਲਾਇੰਟ ਨੂੰ ਇਸ ਕਾਰਨ ਰਾਊਟਰ ਦਾ ਐਡਮਿਨ ਪੇਜ ਜਾਂ ਹਾਈਪਰਵਾਈਜ਼ਰ ਕੰਸੋਲ ਨਹੀਂ ਚਾਹੀਦਾ।

ਜੇ ਮਨਜ਼ੂਰ ਮੰਜ਼ਿਲ ਅੱਗੇ ਫਾਰਵਰਡ ਕਰ ਸਕਦੀ ਹੈ, ਤਾਂ ਜ਼ੋਨ ਦੀ ਸੀਮਾ ਫਾਇਰਵਾਲ 'ਤੇ ਹੀ ਰੁਕਦੀ ਹੈ, ਮੰਜ਼ਿਲ ਅੱਗੇ ਕੀ ਕਰਦੀ ਹੈ ਉੱਥੇ ਨਹੀਂ।

ਤੀਜਾ ਫੈਸਲਾ: ਸੀਮਾ ਕਿਵੇਂ ਸਾਬਤ ਕਰੋਗੇ

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

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

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