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