ਮਲਟੀ-ਟੈਨੈਂਟ VPN: ਸਾਂਝਾ ਗੇਟਵੇ, ਪ੍ਰਤੀ ਟੈਨੈਂਟ ਜਾਂ ਪ੍ਰਤੀ ਹੋਸਟ
ਟਨਲ ਟੈਨੈਂਟ ਵਿਛੋੜਾ ਨਹੀਂ ਹੈ। ਸਾਂਝਾ ਗੇਟਵੇ, ਹਰ ਟੈਨੈਂਟ ਲਈ ਗੇਟਵੇ ਅਤੇ ਹਰ ਹੋਸਟ ਲਈ ਕਨੈਕਸ਼ਨ ਦੀ ਤੁਲਨਾ ਪਛਾਣ ਮੈਪਿੰਗ, ਰੂਟਿੰਗ ਅਤੇ ਹਟਾਉਣ ’ਤੇ ਕਰੋ।
ਤੈਅ ਕਰੋ ਕਿ ਗਾਹਕ ਨੂੰ ਕੌਣ ਦਾਖਲਾ ਦਿੰਦਾ ਹੈ ਅਤੇ ਕੀ ਉਸ ਗਾਹਕ ਨੂੰ ਦੂਜੇ ਟੈਨੈਂਟ ਦੇ ਸਰੋਤਾਂ ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਰੋਕਦਾ ਹੈ। ਇਹ ਦੋ ਫ਼ੈਸਲੇ ਹਨ, ਅਤੇ IPsec, WireGuard ਜਾਂ mesh ਉਤਪਾਦ ਚੁਣਨਾ ਕਿਸੇ ਦਾ ਵੀ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ। ਪੂਰੀ ਤਰ੍ਹਾਂ ਉੱਠਣ ਵਾਲਾ ਟਨਲ ਵੀ ਹਰ ਟੈਨੈਂਟ ਨੂੰ ਬਾਕੀ ਸਾਰਿਆਂ ਤੱਕ ਪਹੁੰਚਣ ਦੇ ਸਕਦਾ ਹੈ, ਅਤੇ ਦੋਵਾਂ ਨੂੰ ਇੱਕੋ ਚੀਜ਼ ਮੰਨਣ ਵਾਲੀ ਸਮੀਖਿਆ ਗ਼ਲਤ ਡਿਜ਼ਾਈਨ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿੰਦੀ ਹੈ। ਪਹਿਲਾਂ ਗਾਹਕ-ਤੋਂ-ਸਰੋਤ ਨਕਸ਼ਾ ਲਿਖੋ: ਪ੍ਰਬੰਧਕ, ਸਹਾਇਤਾ ਪਹੁੰਚ, ਸਾਂਝੀਆਂ ਸੇਵਾਵਾਂ ਅਤੇ ਉਹ ਰਾਹ ਜੋ ਇਨਕਾਰ ਕੀਤੇ ਹੀ ਰਹਿਣੇ ਚਾਹੀਦੇ ਹਨ।
ਉਤਪਾਦ ਨਾਲ ਨਹੀਂ, ਨਕਸ਼ੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ
ਉਹ ਨਕਸ਼ਾ ਪਹਿਲਾ ਦਸਤਾਵੇਜ਼ ਹੈ, ਅਤੇ ਹੇਠਾਂ ਦੀ ਹਰ ਚੋਣ ਸਿਰਫ਼ ਇਹ ਫ਼ੈਸਲਾ ਹੈ ਕਿ ਉਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਵਾਲੀ ਹੱਦ ਕਿੱਥੇ ਰਹਿੰਦੀ ਹੈ। ਇਸ ਨੂੰ ਸਮੀਖਿਆਯੋਗ ਰੱਖੋ: ਹਰ ਗਾਹਕ ਲਈ ਇੱਕ ਕਤਾਰ, ਹਰ ਸਾਂਝੀ ਸੇਵਾ ਲਈ ਇੱਕ ਕਤਾਰ ਅਤੇ ਇਨਕਾਰ ਕੀਤੇ ਰਾਹ ਲਿਖੇ ਹੋਏ।
ਜਿਹੜਾ ਨਕਸ਼ਾ ਕੋਈ ਪੜ੍ਹ ਨਹੀਂ ਸਕਦਾ ਉਹ ਨਕਸ਼ਾ ਕੋਈ ਲਾਗੂ ਵੀ ਨਹੀਂ ਕਰੇਗਾ।
ਇੱਕ ਦਾਖਲਾ ਬਿੰਦੂ ਅਤੇ ਉਸ ਦੀ ਮੈਪਿੰਗ ਸਮੱਸਿਆ
ਹਰ ਥਾਂ ਇੱਕ ਹੀ ਕਾਰਜਕਾਰੀ ਸਵਾਲ ਨਾਲ ਤੈਅ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਸਾਰਣੀ ਹੀ ਪੂਰੀ ਤੁਲਨਾ ਹੈ।
| Placement | The question it lives or dies on |
|---|---|
| One shared gateway | How does an admitted identity end up limited to its own resources and its own routing context? |
| A gateway per tenant | Who owns each gateway, its credentials, its policy, its updates and its eventual retirement? |
| A connection per hosted machine | How do enrollment, per-machine policy and replacement work at fleet scale? |
ਸਾਂਝਾ ਗੇਟਵੇ ਦਾਖਲੇ ਨੂੰ ਕੇਂਦਰਿਤ ਕਰਦਾ ਹੈ ਅਤੇ ਜੋਖਮ ਨੂੰ ਇੱਕ ਥਾਂ ਤੇ ਕੇਂਦਰਿਤ ਕਰਦਾ ਹੈ: ਟੈਨੈਂਟ ਦੀ ਪਛਾਣ ਅਤੇ ਉਸ ਦੀ ਨੀਤੀ ਵਿਚਕਾਰਲਾ ਸੰਬੰਧ। ਸਮੂਹ ਜਾਂ ਟਨਲ ਪਤੇ ਸਹੀ ਸਰੋਤ ਇਜਾਜ਼ਤਾਂ ਵਿੱਚ ਹੱਲ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਅਤੇ ਹਰ ਗਾਹਕ ਲਈ ਵੱਖਰਾ ਲੇਬਲ ਆਪਣੇ ਆਪ ਕੁਝ ਨਹੀਂ ਰੋਕਦਾ। ਵੱਖਰੇ ਰੂਟਿੰਗ ਸੰਦਰਭ ਪਲੇਟਫਾਰਮ ਦੇ ਸਮਰਥਨ ਅਤੇ ਪੂਰੇ ਡਿਜ਼ਾਈਨ ਨਾਲ ਓਵਰਲੈਪਿੰਗ ਪ੍ਰੀਫਿਕਸ ਰੱਖ ਸਕਦੇ ਹਨ। ਸਾਧਾਰਨ ਸਾਂਝੀ ਰੂਟਿੰਗ ਸਾਰਣੀ ਸਿਰਫ਼ ਇਸ ਲਈ ਦੋ ਇੱਕੋ ਜਿਹੇ ਮੰਜ਼ਿਲ ਪ੍ਰੀਫਿਕਸ ਵੱਖ ਨਹੀਂ ਕਰ ਸਕਦੀ ਕਿ ਉਨ੍ਹਾਂ ਪਿੱਛੇ ਦੇ ਲੋਕਾਂ ਦੇ ਖਾਤੇ ਵੱਖਰੇ ਹਨ।
ਬਹੁਤੀਆਂ ਡਿਜ਼ਾਈਨਾਂ ਲਈ ਇਹੀ ਪਰਖ ਹੈ। ਜੋ ਦੋ ਟੈਨੈਂਟ ਅੰਦਰੂਨੀ ਤੌਰ ਤੇ 10.0.0.0/8 ਨਾਲ ਨੰਬਰ ਦਿੰਦੇ ਹਨ, ਉਨ੍ਹਾਂ ਨੂੰ ਨਾਮਕਰਨ ਦੀ ਪਰੰਪਰਾ ਨਹੀਂ, ਵੱਖਰੀ ਰੂਟਿੰਗ ਹਾਲਤ ਚਾਹੀਦੀ ਹੈ।
ਹਰ ਟੈਨੈਂਟ ਲਈ ਗੇਟਵੇ ਹੱਦਾਂ ਅਤੇ ਪ੍ਰਣਾਲੀਆਂ ਖ਼ਰੀਦਦਾ ਹੈ
ਹਰ ਗਾਹਕ ਲਈ ਇੱਕ ਗੇਟਵੇ ਕੁਝ ਪ੍ਰਬੰਧਕੀ ਹੱਦਾਂ ਸਮਝਾਉਣਾ ਸੌਖਾ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ ਉਸ ਗਾਹਕ ਦਾ ਦਾਖਲਾ ਅਤੇ ਨੀਤੀ ਇਕੱਠੇ ਹੁੰਦੇ ਹਨ। ਇਹ ਉਨ੍ਹਾਂ ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਵੀ ਕਈ ਗੁਣਾ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਪ੍ਰਮਾਣ ਪੱਤਰ, ਪੈਚ, ਨਿਗਰਾਨੀ ਅਤੇ ਮਾਲਕ ਚਾਹੀਦਾ ਹੈ। ਅਤੇ ਇਹ ਜਨਤਕ ਪਤਿਆਂ ਦੀ ਇੱਕ ਵੀ ਤੈਅ ਬਣਤਰ ਥੋਪਦਾ ਨਹੀਂ: ਐਂਡਪੁਆਇੰਟ ਸਾਂਝਾ ਕਰਨਾ, ਅਨੁਵਾਦ ਅਤੇ ਪ੍ਰੋਟੋਕਾਲ ਡੀਮਲਟੀਪਲੈਕਸਿੰਗ ਇਸ ’ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ ਕਿ ਲਾਗੂ ਕਰਨਾ ਅਸਲ ਵਿੱਚ ਕਿਸ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ।
ਸੁਰੱਖਿਆ ਲਾਭ ਗਿਣਨ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਣਾਲੀਆਂ ਅਤੇ ਲੋਕ ਗਿਣੋ। ਟੀਮ ਜਿੰਨਾ ਪੈਚ ਕਰ ਸਕਦੀ ਹੈ ਉਸ ਤੋਂ ਚਾਰ ਵੱਧ ਗੇਟਵੇ ਵਾਲਾ ਡਿਜ਼ਾਈਨ ਅਮਲ ਵਿੱਚ ਵੱਧ ਅਲੱਗ ਨਹੀਂ ਹੈ।
ਜੇ ਟੈਨੈਂਟਾਂ ਦੀ ਗਿਣਤੀ ਹਰ ਮਹੀਨੇ ਬਦਲਦੀ ਹੈ, ਤਾਂ ਉਸ ਮਾਡਲ ਨੂੰ ਟੈਂਪਲੇਟ ਨਹੀਂ, ਆਟੋਮੇਸ਼ਨ ਦੀ ਕਹਾਣੀ ਚਾਹੀਦੀ ਹੈ।
ਹਰ ਹੋਸਟ ਲਈ ਕਨੈਕਸ਼ਨ ਕੰਮ ਨੂੰ ਹਿਲਾਉਂਦੇ ਹਨ
ਹਰ ਹੋਸਟ ਕੀਤੀ ਮਸ਼ੀਨ ’ਤੇ ਕਨੈਕਸ਼ਨ ਕਾਰਜਕਾਰੀ ਕੰਮ ਨੂੰ ਹਟਾਉਂਦਾ ਨਹੀਂ, ਇਸ ਨੂੰ ਮਸ਼ੀਨ ਦੇ ਜੀਵਨ ਚੱਕਰ ਵਿੱਚ ਭੇਜਦਾ ਹੈ। ਦਾਖਲਾ, ਪ੍ਰਤੀ-ਮਸ਼ੀਨ ਨੀਤੀ, ਕੁੰਜੀ ਬਦਲੀ ਅਤੇ ਤਬਦੀਲੀ ਸਭ ਪ੍ਰਬੰਧ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਉਹ ਮਸ਼ੀਨ ਵਾਂਗ ਹੀ ਉਸੇ ਸਮੇਂ ਅਸਫਲ ਹੁੰਦੇ ਹਨ। ਵੱਖਰੇ ਨੈੱਟਵਰਕਾਂ ’ਤੇ ਕੁਝ ਲੰਮੇ ਸਮੇਂ ਦੇ ਹੋਸਟਾਂ ਲਈ ਇਹ ਅਕਸਰ ਸਹੀ ਹੈ, ਅਤੇ ਜਿਸ ਬੇੜੇ ਨੇ ਪਹਿਲਾਂ ਹੀ ਇਹ ਹਿਸਾਬ ਗੁਆ ਦਿੱਤਾ ਹੈ ਕਿ ਕਿਹੜੀ ਇਮੇਜ ਕਿੱਥੇ ਚੱਲਦੀ ਹੈ, ਉਸ ਲਈ ਘੱਟ ਹੀ।
ਹਰ ਵਿਕਲਪ ਹੇਠ ਪਛਾਣ ਜਾਰੀ ਕਰਨ, ਅੱਪਡੇਟ, ਪਹੁੰਚ ਹਟਾਉਣ, ਨਿਗਰਾਨੀ ਅਤੇ ਬਹਾਲੀ ਲਈ ਭੂਮਿਕਾ ਦਾ ਨਾਮ ਦਿਓ। ਫਿਰ ਪੁੱਛੋ ਕਿ ਜਿਸ ਦਿਨ ਇੱਕ ਗਾਹਕ ਜਾਂਦਾ ਹੈ ਉਸ ਦਿਨ ਕੀ ਹੁੰਦਾ ਹੈ।
ਹਟਾਉਣਾ ਤੁਲਨਾ ਦਾ ਹਿੱਸਾ ਹੈ
ਬਹੁਤੀਆਂ ਤੁਲਨਾਵਾਂ ਹਟਾਉਣਾ ਛੱਡ ਦਿੰਦੀਆਂ ਹਨ। ਟੈਨੈਂਟ ਹਟਾਉਣ ਨਾਲ ਉਸ ਦੇ ਪ੍ਰਮਾਣ ਪੱਤਰ ਅਵੈਧ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਉਸ ਦੀ ਨੀਤੀ ਡਿਗਣੀ ਚਾਹੀਦੀ ਹੈ, ਉਸ ਦੇ ਪਤੇ ਅਤੇ ਰੂਟਿੰਗ ਹਾਲਤ ਮੁਕਤ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਅਤੇ ਬਾਕੀ ਸਭ ਅਛੂਤ ਰਹਿਣੇ ਚਾਹੀਦੇ ਹਨ। NIST ਦੀ ਜ਼ੀਰੋ-ਟਰੱਸਟ ਆਰਕੀਟੈਕਚਰ ਗਾਈਡ ਇੱਥੇ ਸਹੀ ਹਵਾਲਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਨੈੱਟਵਰਕ ਥਾਂ ’ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਥਾਂ ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਅਧਿਕਾਰ ਸਰੋਤ ’ਤੇ ਰੱਖਦੀ ਹੈ, ਅਤੇ ਇਹ ਗਾਹਕ ਦੇ ਆਪਣੇ ਹਿੱਸੇ ਅੰਦਰ ਵੀ ਲਾਗੂ ਹੁੰਦੀ ਹੈ।
ਪ੍ਰੋਟੋਕਾਲ ਬੈਂਚਮਾਰਕ ਤੋਲਣ ਤੋਂ ਪਹਿਲਾਂ ਮਨਜ਼ੂਰ ਅਤੇ ਇਨਕਾਰ ਕੀਤੇ ਪ੍ਰਵਾਹ, ਓਵਰਲੈਪਿੰਗ ਪਤਿਆਂ ਦੀ ਸੰਭਾਲ ਅਤੇ ਹਟਾਉਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਤੋਲੋ। ਫਿਰ ਤੁਸੀਂ ਚੁਣੀ ਹੱਦ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਆਵਾਜਾਈ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਢੰਗ ਚੁਣੋ। ਪੁਰਾਣਾ ਉਤਪਾਦ ਨਾਮ, ਜਾਂ ਇਹ ਦਾਅਵਾ ਕਿ ਹਰ ਕਾਰੋਬਾਰ ਨੂੰ ਇੱਕੋ ਪ੍ਰੋਟੋਕਾਲ ’ਤੇ ਮਿਆਰੀਕਰਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਤੈਅ ਨਹੀਂ ਕਰਦਾ। ਪਹਿਲਾਂ ਲਿਖਿਆ ਨਕਸ਼ਾ ਉਹ ਕਰਦਾ ਹੈ।