ਇਹ ਲੇਖ ਲੇਖਾਂ ਦੀ ਲੜੀ ਵਿੱਚ ਤੀਜਾ ਹੈ "ਤੁਹਾਡੇ ਨੈੱਟਵਰਕ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦਾ ਨਿਯੰਤਰਣ ਕਿਵੇਂ ਕਰੀਏ।" ਲੜੀ ਦੇ ਸਾਰੇ ਲੇਖਾਂ ਦੀ ਸਮੱਗਰੀ ਅਤੇ ਲਿੰਕ ਲੱਭੇ ਜਾ ਸਕਦੇ ਹਨ ਇੱਥੇ.

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

ਬੇਸ਼ੱਕ, ਸੁਰੱਖਿਆ ਡਿਜ਼ਾਈਨ ਨੂੰ ਸਮੁੱਚੇ ਢਾਂਚੇ ਵਿੱਚ ਸੰਗਠਿਤ ਰੂਪ ਵਿੱਚ ਜੋੜਿਆ ਗਿਆ ਹੈ ਅਤੇ ਵਰਤੇ ਗਏ ਸੁਰੱਖਿਆ ਹੱਲ ਨੈੱਟਵਰਕ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਸਕੇਲੇਬਿਲਟੀ, ਭਰੋਸੇਯੋਗਤਾ, ਪ੍ਰਬੰਧਨਯੋਗਤਾ, ... ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ, ਜਿਸ ਨੂੰ ਵੀ ਧਿਆਨ ਵਿੱਚ ਰੱਖਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

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

ਸਾਡਾ ਕੰਮ ਹੁਣ ਨੈੱਟਵਰਕ ਪੱਧਰ 'ਤੇ ਸੁਰੱਖਿਆ ਨਾਲ ਜੁੜੇ ਖਤਰਿਆਂ ਦੀ ਪਛਾਣ ਕਰਨਾ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਵਾਜਬ ਪੱਧਰ ਤੱਕ ਘਟਾਉਣਾ ਹੈ।

ਨੈੱਟਵਰਕ ਸੁਰੱਖਿਆ ਆਡਿਟ

ਜੇਕਰ ਤੁਹਾਡੀ ਸੰਸਥਾ ਨੇ ISO 27k ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਹੈ, ਤਾਂ ਸੁਰੱਖਿਆ ਆਡਿਟ ਅਤੇ ਨੈੱਟਵਰਕ ਤਬਦੀਲੀਆਂ ਨੂੰ ਇਸ ਪਹੁੰਚ ਦੇ ਅੰਦਰ ਸਮੁੱਚੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਿੱਚ ਨਿਰਵਿਘਨ ਫਿੱਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਪਰ ਇਹ ਮਾਪਦੰਡ ਅਜੇ ਵੀ ਖਾਸ ਹੱਲਾਂ ਬਾਰੇ ਨਹੀਂ ਹਨ, ਸੰਰਚਨਾ ਬਾਰੇ ਨਹੀਂ, ਡਿਜ਼ਾਈਨ ਬਾਰੇ ਨਹੀਂ... ਇੱਥੇ ਕੋਈ ਸਪੱਸ਼ਟ ਸਲਾਹ ਨਹੀਂ ਹੈ, ਕੋਈ ਮਾਪਦੰਡ ਨਹੀਂ ਹਨ ਜੋ ਵਿਸਥਾਰ ਵਿੱਚ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ ਕਿ ਤੁਹਾਡਾ ਨੈੱਟਵਰਕ ਕਿਹੋ ਜਿਹਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਇਹ ਇਸ ਕੰਮ ਦੀ ਗੁੰਝਲਤਾ ਅਤੇ ਸੁੰਦਰਤਾ ਹੈ।

ਮੈਂ ਕਈ ਸੰਭਾਵਿਤ ਨੈੱਟਵਰਕ ਸੁਰੱਖਿਆ ਆਡਿਟਾਂ ਨੂੰ ਉਜਾਗਰ ਕਰਾਂਗਾ:

• ਉਪਕਰਣ ਸੰਰਚਨਾ ਆਡਿਟ (ਸਖਤ)
• ਸੁਰੱਖਿਆ ਡਿਜ਼ਾਈਨ ਆਡਿਟ
• ਪਹੁੰਚ ਆਡਿਟ
• ਪ੍ਰਕਿਰਿਆ ਆਡਿਟ

ਉਪਕਰਣ ਸੰਰਚਨਾ ਆਡਿਟ (ਸਖਤ)

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

ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਸਾਜ਼-ਸਾਮਾਨ ਦੀ ਸੰਰਚਨਾ ਕਰਨ ਵੇਲੇ ਸਾਡੇ ਕੋਲ ਸੁਰੱਖਿਆ ਲਈ "ਸਭ ਤੋਂ ਵਧੀਆ ਅਭਿਆਸਾਂ" ਸੰਬੰਧੀ ਵਿਕਰੇਤਾਵਾਂ ਤੋਂ ਸਿਫ਼ਾਰਸ਼ਾਂ ਹੁੰਦੀਆਂ ਹਨ। ਇਸ ਨੂੰ "ਸਖਤ" ਕਿਹਾ ਜਾਂਦਾ ਹੈ।

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

ਕੁਝ ਸਿਸਕੋ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮਾਂ ਲਈ ਕਈ ਉਦਾਹਰਣਾਂ।

ਸਿਸਕੋ ਆਈਓਐਸ ਕੌਂਫਿਗਰੇਸ਼ਨ ਹਾਰਡਨਿੰਗ
Cisco IOS-XR ਕੌਂਫਿਗਰੇਸ਼ਨ ਹਾਰਡਨਿੰਗ
Cisco NX-OS ਕੌਂਫਿਗਰੇਸ਼ਨ ਹਾਰਡਨਿੰਗ
ਸਿਸਕੋ ਬੇਸਲਾਈਨ ਸੁਰੱਖਿਆ ਜਾਂਚ ਸੂਚੀ

ਇਹਨਾਂ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਅਧਾਰ ਤੇ, ਹਰੇਕ ਕਿਸਮ ਦੇ ਉਪਕਰਣਾਂ ਲਈ ਸੰਰਚਨਾ ਲੋੜਾਂ ਦੀ ਇੱਕ ਸੂਚੀ ਬਣਾਈ ਜਾ ਸਕਦੀ ਹੈ. ਉਦਾਹਰਨ ਲਈ, ਇੱਕ Cisco N7K VDC ਲਈ ਇਹ ਲੋੜਾਂ ਇਸ ਤਰ੍ਹਾਂ ਲੱਗ ਸਕਦੀਆਂ ਹਨ ਇਸ ਲਈ.

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

ਸੁਰੱਖਿਆ ਡਿਜ਼ਾਈਨ ਆਡਿਟ

ਆਮ ਤੌਰ 'ਤੇ, ਇੱਕ ਐਂਟਰਪ੍ਰਾਈਜ਼ ਨੈਟਵਰਕ ਵਿੱਚ ਇੱਕ ਜਾਂ ਦੂਜੇ ਰੂਪ ਵਿੱਚ ਹੇਠਾਂ ਦਿੱਤੇ ਹਿੱਸੇ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ:

• DC (ਜਨਤਕ ਸੇਵਾਵਾਂ DMZ ਅਤੇ ਇੰਟਰਾਨੈੱਟ ਡਾਟਾ ਸੈਂਟਰ)
• ਇੰਟਰਨੈੱਟ ਪਹੁੰਚ
• ਰਿਮੋਟ ਐਕਸੈਸ VPN
• WAN ਕਿਨਾਰਾ
• ਸ਼ਾਖਾ
• ਕੈਂਪਸ (ਦਫ਼ਤਰ)
• ਕੋਰ

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

ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਹਿੱਸੇ ਲਈ, ਸੁਰੱਖਿਆ ਲੋੜਾਂ, ਜੋਖਮ ਅਤੇ, ਇਸਦੇ ਅਨੁਸਾਰ, ਹੱਲ ਵੱਖਰੇ ਹੋਣਗੇ।

ਆਉ ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਨੂੰ ਉਹਨਾਂ ਸਮੱਸਿਆਵਾਂ ਲਈ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਵੇਖੀਏ ਜੋ ਤੁਹਾਨੂੰ ਸੁਰੱਖਿਆ ਡਿਜ਼ਾਈਨ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਆ ਸਕਦੀਆਂ ਹਨ। ਬੇਸ਼ੱਕ, ਮੈਂ ਦੁਬਾਰਾ ਦੁਹਰਾਉਂਦਾ ਹਾਂ ਕਿ ਇਹ ਲੇਖ ਕਿਸੇ ਵੀ ਤਰੀਕੇ ਨਾਲ ਸੰਪੂਰਨ ਹੋਣ ਦਾ ਦਿਖਾਵਾ ਨਹੀਂ ਕਰਦਾ, ਜੋ ਇਸ ਸੱਚਮੁੱਚ ਡੂੰਘੇ ਅਤੇ ਬਹੁਪੱਖੀ ਵਿਸ਼ੇ ਵਿੱਚ ਪ੍ਰਾਪਤ ਕਰਨਾ ਆਸਾਨ (ਜੇ ਅਸੰਭਵ ਨਹੀਂ) ਨਹੀਂ ਹੈ, ਪਰ ਇਹ ਮੇਰੇ ਨਿੱਜੀ ਅਨੁਭਵ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ।

ਕੋਈ ਸੰਪੂਰਣ ਹੱਲ ਨਹੀਂ ਹੈ (ਘੱਟੋ ਘੱਟ ਅਜੇ ਨਹੀਂ). ਇਹ ਹਮੇਸ਼ਾ ਇੱਕ ਸਮਝੌਤਾ ਹੁੰਦਾ ਹੈ. ਪਰ ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਇੱਕ ਜਾਂ ਕਿਸੇ ਹੋਰ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਫੈਸਲਾ ਇਸਦੇ ਚੰਗੇ ਅਤੇ ਨੁਕਸਾਨ ਦੋਵਾਂ ਦੀ ਸਮਝ ਦੇ ਨਾਲ, ਸੁਚੇਤ ਤੌਰ 'ਤੇ ਲਿਆ ਗਿਆ ਹੈ।

ਡਾਟਾ Center

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

ਕੀ ਫਾਇਰਵਾਲ ਜ਼ਰੂਰੀ ਹੈ ਜਾਂ ਨਹੀਂ?

ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਜਵਾਬ ਸਪੱਸ਼ਟ ਹੈ, ਪਰ ਸਭ ਕੁਝ ਇੰਨਾ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੈ ਜਿੰਨਾ ਇਹ ਲੱਗਦਾ ਹੈ. ਅਤੇ ਤੁਹਾਡੀ ਪਸੰਦ ਨੂੰ ਨਾ ਸਿਰਫ਼ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਕੀਮਤ.

1 ਉਦਾਹਰਨ. ਦੇਰੀ।

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

2 ਉਦਾਹਰਨ. ਪ੍ਰਦਰਸ਼ਨ.

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

3 ਉਦਾਹਰਨ. ਭਰੋਸੇਯੋਗਤਾ

ਫਾਇਰਵਾਲ, ਖਾਸ ਕਰਕੇ ਆਧੁਨਿਕ NGFW (ਨੈਕਸਟ-ਜਨਰੇਸ਼ਨ FW) ਗੁੰਝਲਦਾਰ ਯੰਤਰ ਹਨ। ਇਹ L3/L2 ਸਵਿੱਚਾਂ ਨਾਲੋਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਗੁੰਝਲਦਾਰ ਹਨ। ਉਹ ਬਹੁਤ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਅਤੇ ਸੰਰਚਨਾ ਵਿਕਲਪ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਇਹ ਕੋਈ ਹੈਰਾਨੀ ਦੀ ਗੱਲ ਨਹੀਂ ਹੈ ਕਿ ਉਹਨਾਂ ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਬਹੁਤ ਘੱਟ ਹੈ. ਜੇਕਰ ਸੇਵਾ ਦੀ ਨਿਰੰਤਰਤਾ ਨੈੱਟਵਰਕ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਹ ਚੁਣਨਾ ਪੈ ਸਕਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਚੀਜ਼ ਬਿਹਤਰ ਉਪਲਬਧਤਾ ਵੱਲ ਲੈ ਜਾਵੇਗੀ - ਫਾਇਰਵਾਲ ਨਾਲ ਸੁਰੱਖਿਆ ਜਾਂ ਨਿਯਮਤ ACLs ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਸਵਿੱਚਾਂ (ਜਾਂ ਵੱਖ-ਵੱਖ ਕਿਸਮਾਂ ਦੇ ਫੈਬਰਿਕਸ) 'ਤੇ ਬਣੇ ਨੈੱਟਵਰਕ ਦੀ ਸਰਲਤਾ।

ਉਪਰੋਕਤ ਉਦਾਹਰਨਾਂ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਸਭ ਤੋਂ ਵੱਧ ਸੰਭਾਵਨਾ ਹੋਵੇਗੀ (ਆਮ ਵਾਂਗ) ਇੱਕ ਸਮਝੌਤਾ ਲੱਭਣਾ ਪਵੇਗਾ। ਹੇਠਾਂ ਦਿੱਤੇ ਹੱਲਾਂ ਵੱਲ ਧਿਆਨ ਦਿਓ:

• ਜੇਕਰ ਤੁਸੀਂ ਡਾਟਾ ਸੈਂਟਰ ਦੇ ਅੰਦਰ ਫਾਇਰਵਾਲਾਂ ਦੀ ਵਰਤੋਂ ਨਾ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਸ ਬਾਰੇ ਸੋਚਣ ਦੀ ਲੋੜ ਹੈ ਕਿ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਘੇਰੇ ਦੇ ਆਲੇ ਦੁਆਲੇ ਪਹੁੰਚ ਨੂੰ ਕਿਵੇਂ ਸੀਮਤ ਕਰਨਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਇੰਟਰਨੈਟ ਤੋਂ ਸਿਰਫ਼ ਲੋੜੀਂਦੀਆਂ ਪੋਰਟਾਂ (ਕਲਾਇੰਟ ਟ੍ਰੈਫਿਕ ਲਈ) ਅਤੇ ਕੇਵਲ ਜੰਪ ਹੋਸਟਾਂ ਤੋਂ ਡੇਟਾ ਸੈਂਟਰ ਤੱਕ ਪ੍ਰਬੰਧਕੀ ਪਹੁੰਚ ਖੋਲ੍ਹ ਸਕਦੇ ਹੋ। ਜੰਪ ਹੋਸਟਾਂ 'ਤੇ, ਸਾਰੀਆਂ ਜ਼ਰੂਰੀ ਜਾਂਚਾਂ ਕਰੋ (ਪ੍ਰਮਾਣਿਕਤਾ/ਪ੍ਰਮਾਣਿਕਤਾ, ਐਂਟੀਵਾਇਰਸ, ਲੌਗਿੰਗ, ...)
• ਤੁਸੀਂ PSEFABRIC ਵਿੱਚ ਵਰਣਿਤ ਸਕੀਮ ਦੇ ਸਮਾਨ, ਖੰਡਾਂ ਵਿੱਚ ਡੇਟਾ ਸੈਂਟਰ ਨੈਟਵਰਕ ਦੇ ਇੱਕ ਲਾਜ਼ੀਕਲ ਭਾਗ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ ਉਦਾਹਰਨ p002. ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਰੂਟਿੰਗ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਕੌਂਫਿਗਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਦੇਰੀ-ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਂ ਉੱਚ-ਤੀਬਰਤਾ ਵਾਲਾ ਟ੍ਰੈਫਿਕ ਇੱਕ ਹਿੱਸੇ (p002, VRF ਦੇ ਮਾਮਲੇ ਵਿੱਚ) "ਅੰਦਰ" ਜਾਂਦਾ ਹੈ ਅਤੇ ਫਾਇਰਵਾਲ ਵਿੱਚੋਂ ਨਹੀਂ ਲੰਘਦਾ। ਫਾਇਰਵਾਲ ਰਾਹੀਂ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਵਿਚਕਾਰ ਆਵਾਜਾਈ ਜਾਰੀ ਰਹੇਗੀ। ਤੁਸੀਂ ਫਾਇਰਵਾਲ ਰਾਹੀਂ ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੀਡਾਇਰੈਕਟ ਕਰਨ ਤੋਂ ਬਚਣ ਲਈ VRF ਦੇ ਵਿਚਕਾਰ ਲੀਕ ਹੋਣ ਵਾਲੇ ਰੂਟ ਦੀ ਵਰਤੋਂ ਵੀ ਕਰ ਸਕਦੇ ਹੋ
• ਤੁਸੀਂ ਪਾਰਦਰਸ਼ੀ ਮੋਡ ਵਿੱਚ ਫਾਇਰਵਾਲ ਦੀ ਵਰਤੋਂ ਵੀ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਸਿਰਫ਼ ਉਹਨਾਂ VLAN ਲਈ ਜਿੱਥੇ ਇਹ ਕਾਰਕ (ਲੇਟੈਂਸੀ/ਕਾਰਗੁਜ਼ਾਰੀ) ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹਨ। ਪਰ ਤੁਹਾਨੂੰ ਹਰੇਕ ਵਿਕਰੇਤਾ ਲਈ ਇਸ ਮਾਡ ਦੀ ਵਰਤੋਂ ਨਾਲ ਜੁੜੀਆਂ ਪਾਬੰਦੀਆਂ ਦਾ ਧਿਆਨ ਨਾਲ ਅਧਿਐਨ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ
• ਤੁਸੀਂ ਸਰਵਿਸ ਚੇਨ ਆਰਕੀਟੈਕਚਰ ਦੀ ਵਰਤੋਂ ਕਰਨ 'ਤੇ ਵਿਚਾਰ ਕਰ ਸਕਦੇ ਹੋ। ਇਹ ਫਾਇਰਵਾਲ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਲੋੜੀਂਦੇ ਟਰੈਫ਼ਿਕ ਨੂੰ ਲੰਘਣ ਦੀ ਇਜਾਜ਼ਤ ਦੇਵੇਗਾ। ਸਿਧਾਂਤ ਵਿੱਚ ਵਧੀਆ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਪਰ ਮੈਂ ਇਸ ਹੱਲ ਨੂੰ ਉਤਪਾਦਨ ਵਿੱਚ ਕਦੇ ਨਹੀਂ ਦੇਖਿਆ ਹੈ. ਅਸੀਂ ਲਗਭਗ 5 ਸਾਲ ਪਹਿਲਾਂ Cisco ACI/Juniper SRX/F3 LTM ਲਈ ਸੇਵਾ ਲੜੀ ਦੀ ਜਾਂਚ ਕੀਤੀ ਸੀ, ਪਰ ਉਸ ਸਮੇਂ ਇਹ ਹੱਲ ਸਾਡੇ ਲਈ "ਕੱਚਾ" ਜਾਪਦਾ ਸੀ।

ਸੁਰੱਖਿਆ ਦਾ ਪੱਧਰ

ਹੁਣ ਤੁਹਾਨੂੰ ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣ ਦੀ ਲੋੜ ਹੈ ਕਿ ਤੁਸੀਂ ਟ੍ਰੈਫਿਕ ਨੂੰ ਫਿਲਟਰ ਕਰਨ ਲਈ ਕਿਹੜੇ ਸਾਧਨ ਵਰਤਣਾ ਚਾਹੁੰਦੇ ਹੋ. ਇੱਥੇ ਕੁਝ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹਨ ਜੋ ਆਮ ਤੌਰ 'ਤੇ NGFW ਵਿੱਚ ਮੌਜੂਦ ਹੁੰਦੀਆਂ ਹਨ (ਉਦਾਹਰਨ ਲਈ, ਇੱਥੇ):

• ਸਟੇਟਫੁੱਲ ਫਾਇਰਵਾਲਿੰਗ (ਡਿਫੌਲਟ)
• ਐਪਲੀਕੇਸ਼ਨ ਫਾਇਰਵਾਲਿੰਗ
• ਖਤਰੇ ਦੀ ਰੋਕਥਾਮ (ਐਂਟੀਵਾਇਰਸ, ਐਂਟੀ-ਸਪਾਈਵੇਅਰ, ਅਤੇ ਕਮਜ਼ੋਰੀ)
• URL ਫਿਲਟਰਿੰਗ
• ਡਾਟਾ ਫਿਲਟਰਿੰਗ (ਸਮੱਗਰੀ ਫਿਲਟਰਿੰਗ)
• ਫਾਈਲ ਬਲਾਕਿੰਗ (ਫਾਇਲ ਕਿਸਮਾਂ ਨੂੰ ਬਲੌਕ ਕਰਨਾ)
• dos ਸੁਰੱਖਿਆ

ਅਤੇ ਨਾ ਹੀ ਸਭ ਕੁਝ ਸਪੱਸ਼ਟ ਹੈ. ਇਹ ਜਾਪਦਾ ਹੈ ਕਿ ਸੁਰੱਖਿਆ ਦਾ ਪੱਧਰ ਜਿੰਨਾ ਉੱਚਾ ਹੋਵੇਗਾ, ਉੱਨਾ ਹੀ ਵਧੀਆ ਹੈ. ਪਰ ਤੁਹਾਨੂੰ ਇਹ ਵੀ ਵਿਚਾਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ

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

ਹਮੇਸ਼ਾ ਵਾਂਗ, ਤੁਹਾਨੂੰ ਆਪਣੇ ਨੈੱਟਵਰਕ ਲਈ ਸਭ ਤੋਂ ਵਧੀਆ ਹੱਲ ਲੱਭਣ ਦੀ ਲੋੜ ਹੈ।

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

ਇਸ ਲਈ, ਨਾਜ਼ੁਕ ਹਿੱਸਿਆਂ ਵਿੱਚ, ਵੱਖ-ਵੱਖ ਕੰਪਨੀਆਂ ਦੀਆਂ ਪੇਸ਼ਕਸ਼ਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਇੱਕ ਚੰਗਾ ਹੱਲ ਹੋ ਸਕਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਫਾਇਰਵਾਲ 'ਤੇ ਐਂਟੀਵਾਇਰਸ ਨੂੰ ਚਾਲੂ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਹੋਸਟਾਂ 'ਤੇ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਐਂਟੀਵਾਇਰਸ ਸੁਰੱਖਿਆ (ਕਿਸੇ ਹੋਰ ਨਿਰਮਾਤਾ ਤੋਂ) ਦੀ ਵਰਤੋਂ ਵੀ ਕਰ ਸਕਦੇ ਹੋ।

ਵਿਭਾਜਨ

ਅਸੀਂ ਡੇਟਾ ਸੈਂਟਰ ਨੈਟਵਰਕ ਦੇ ਲਾਜ਼ੀਕਲ ਸੈਗਮੈਂਟੇਸ਼ਨ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ. ਉਦਾਹਰਨ ਲਈ, VLAN ਅਤੇ ਸਬਨੈੱਟ ਵਿੱਚ ਵੰਡਣਾ ਵੀ ਲਾਜ਼ੀਕਲ ਸੈਗਮੈਂਟੇਸ਼ਨ ਹੈ, ਪਰ ਅਸੀਂ ਇਸਦੀ ਸਪੱਸ਼ਟਤਾ ਦੇ ਕਾਰਨ ਇਸ 'ਤੇ ਵਿਚਾਰ ਨਹੀਂ ਕਰਾਂਗੇ। FW ਸੁਰੱਖਿਆ ਜ਼ੋਨ, VRF (ਅਤੇ ਵੱਖ-ਵੱਖ ਵਿਕਰੇਤਾਵਾਂ ਦੇ ਸਬੰਧ ਵਿੱਚ ਉਹਨਾਂ ਦੇ ਐਨਾਲਾਗ), ਲਾਜ਼ੀਕਲ ਡਿਵਾਈਸਾਂ (PA VSYS, Cisco N7K VDC, Cisco ACI ਕਿਰਾਏਦਾਰ, ...), ... ਵਰਗੀਆਂ ਸੰਸਥਾਵਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ ਦਿਲਚਸਪ ਵਿਭਾਜਨ।

ਅਜਿਹੇ ਲਾਜ਼ੀਕਲ ਸੈਗਮੈਂਟੇਸ਼ਨ ਅਤੇ ਵਰਤਮਾਨ ਵਿੱਚ ਡਿਮਾਂਡ ਡੇਟਾ ਸੈਂਟਰ ਡਿਜ਼ਾਈਨ ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਵਿੱਚ ਦਿੱਤੀ ਗਈ ਹੈ PSEFABRIC ਪ੍ਰੋਜੈਕਟ ਦਾ p002.

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

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

ਅਕਸਰ ਵੰਡ ਸਿਰਫ਼ FW ਸੁਰੱਖਿਆ ਜ਼ੋਨ 'ਤੇ ਆਧਾਰਿਤ ਹੁੰਦੀ ਹੈ। ਫਿਰ ਤੁਹਾਨੂੰ ਹੇਠਾਂ ਦਿੱਤੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣ ਦੀ ਲੋੜ ਹੈ:

• ਤੁਹਾਨੂੰ ਕਿਹੜੇ ਸੁਰੱਖਿਆ ਖੇਤਰਾਂ ਦੀ ਲੋੜ ਹੈ
• ਤੁਸੀਂ ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਜ਼ੋਨ ਲਈ ਸੁਰੱਖਿਆ ਦੇ ਕਿਸ ਪੱਧਰ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ
• ਕੀ ਇੰਟਰਾ-ਜ਼ੋਨ ਟ੍ਰੈਫਿਕ ਨੂੰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਆਗਿਆ ਦਿੱਤੀ ਜਾਵੇਗੀ?
• ਜੇਕਰ ਨਹੀਂ, ਤਾਂ ਹਰੇਕ ਜ਼ੋਨ ਵਿੱਚ ਕਿਹੜੀਆਂ ਟ੍ਰੈਫਿਕ ਫਿਲਟਰਿੰਗ ਨੀਤੀਆਂ ਲਾਗੂ ਕੀਤੀਆਂ ਜਾਣਗੀਆਂ
• ਜ਼ੋਨਾਂ ਦੇ ਹਰੇਕ ਜੋੜੇ (ਸਰੋਤ/ਮੰਜ਼ਿਲ) ਲਈ ਕਿਹੜੀਆਂ ਟ੍ਰੈਫਿਕ ਫਿਲਟਰਿੰਗ ਨੀਤੀਆਂ ਲਾਗੂ ਕੀਤੀਆਂ ਜਾਣਗੀਆਂ

TCAM

ਇੱਕ ਆਮ ਸਮੱਸਿਆ ਹੈ ਨਾਕਾਫ਼ੀ TCAM (ਟਰਨਰੀ ਕੰਟੈਂਟ ਐਡਰੈਸੇਬਲ ਮੈਮੋਰੀ), ਰੂਟਿੰਗ ਅਤੇ ਐਕਸੈਸ ਦੋਵਾਂ ਲਈ। IMHO, ਸਾਜ਼ੋ-ਸਾਮਾਨ ਦੀ ਚੋਣ ਕਰਦੇ ਸਮੇਂ ਇਹ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਮੁੱਦਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ, ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਇਸ ਮੁੱਦੇ ਨੂੰ ਢੁਕਵੀਂ ਦੇਖਭਾਲ ਨਾਲ ਇਲਾਜ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਉਦਾਹਰਨ 1. ਫਾਰਵਰਡਿੰਗ ਟੇਬਲ TCAM।

ਆਓ ਵਿਚਾਰ ਕਰੀਏ ਪਾਲੋ ਆਲਟੋ 7 ਕਿ ਫਾਇਰਵਾਲ
ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ IPv4 ਫਾਰਵਰਡਿੰਗ ਟੇਬਲ ਦਾ ਆਕਾਰ* = 32K
ਇਸ ਤੋਂ ਇਲਾਵਾ, ਸਾਰੇ VSYS ਲਈ ਰੂਟਾਂ ਦੀ ਇਹ ਗਿਣਤੀ ਆਮ ਹੈ।

ਮੰਨ ਲਓ ਕਿ ਤੁਹਾਡੇ ਡਿਜ਼ਾਈਨ ਦੇ ਅਨੁਸਾਰ ਤੁਸੀਂ 4 VSYS ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕਰਦੇ ਹੋ.
ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ VSYSs BGP ਦੁਆਰਾ ਕਲਾਊਡ ਦੇ ਦੋ MPLS PEs ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਹੈ ਜੋ ਤੁਸੀਂ BB ਵਜੋਂ ਵਰਤਦੇ ਹੋ। ਇਸ ਤਰ੍ਹਾਂ, 4 VSYS ਇੱਕ ਦੂਜੇ ਨਾਲ ਸਾਰੇ ਖਾਸ ਰੂਟਾਂ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ ਅਤੇ ਰੂਟਾਂ ਦੇ ਲਗਭਗ ਇੱਕੋ ਸੈੱਟ (ਪਰ ਵੱਖ-ਵੱਖ NHs) ਦੇ ਨਾਲ ਇੱਕ ਫਾਰਵਰਡਿੰਗ ਟੇਬਲ ਹੈ। ਕਿਉਂਕਿ ਹਰੇਕ VSYS ਦੇ 2 BGP ਸੈਸ਼ਨ ਹੁੰਦੇ ਹਨ (ਉਸੇ ਸੈਟਿੰਗ ਦੇ ਨਾਲ), ਫਿਰ MPLS ਦੁਆਰਾ ਪ੍ਰਾਪਤ ਕੀਤੇ ਹਰੇਕ ਰੂਟ ਵਿੱਚ 2 NH ਅਤੇ, ਇਸਦੇ ਅਨੁਸਾਰ, ਫਾਰਵਰਡਿੰਗ ਟੇਬਲ ਵਿੱਚ 2 FIB ਐਂਟਰੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। ਜੇਕਰ ਅਸੀਂ ਮੰਨਦੇ ਹਾਂ ਕਿ ਡੇਟਾ ਸੈਂਟਰ ਵਿੱਚ ਇਹ ਇੱਕੋ ਇੱਕ ਫਾਇਰਵਾਲ ਹੈ ਅਤੇ ਇਸਨੂੰ ਸਾਰੇ ਰੂਟਾਂ ਬਾਰੇ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੋਵੇਗਾ ਕਿ ਸਾਡੇ ਡੇਟਾ ਸੈਂਟਰ ਵਿੱਚ ਕੁੱਲ ਰੂਟਾਂ ਦੀ ਸੰਖਿਆ 32K/(4 * 2) = 4K ਤੋਂ ਵੱਧ ਨਹੀਂ ਹੋ ਸਕਦੀ।

ਹੁਣ, ਜੇਕਰ ਅਸੀਂ ਮੰਨ ਲੈਂਦੇ ਹਾਂ ਕਿ ਸਾਡੇ ਕੋਲ 2 ਡਾਟਾ ਸੈਂਟਰ ਹਨ (ਇੱਕੋ ਡਿਜ਼ਾਈਨ ਦੇ ਨਾਲ), ਅਤੇ ਅਸੀਂ ਡਾਟਾ ਸੈਂਟਰਾਂ (ਉਦਾਹਰਨ ਲਈ, vMotion ਲਈ) ਦੇ ਵਿਚਕਾਰ VLANs ਨੂੰ "ਖਿੱਚਿਆ" ਵਰਤਣਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਤਾਂ ਰੂਟਿੰਗ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਹੋਸਟ ਰੂਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। . ਪਰ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ 2 ਡਾਟਾ ਸੈਂਟਰਾਂ ਲਈ ਸਾਡੇ ਕੋਲ 4096 ਤੋਂ ਵੱਧ ਸੰਭਵ ਹੋਸਟ ਨਹੀਂ ਹੋਣਗੇ ਅਤੇ, ਬੇਸ਼ਕ, ਇਹ ਕਾਫ਼ੀ ਨਹੀਂ ਹੋ ਸਕਦਾ.

ਉਦਾਹਰਨ 2. ACL TCAM।

ਜੇਕਰ ਤੁਸੀਂ L3 ਸਵਿੱਚਾਂ (ਜਾਂ ਹੋਰ ਹੱਲ ਜੋ L3 ਸਵਿੱਚਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਉਦਾਹਰਨ ਲਈ, Cisco ACI) 'ਤੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਫਿਲਟਰ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਸਾਜ਼ੋ-ਸਾਮਾਨ ਦੀ ਚੋਣ ਕਰਦੇ ਸਮੇਂ TCAM ACL ਵੱਲ ਧਿਆਨ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ।

ਮੰਨ ਲਓ ਕਿ ਤੁਸੀਂ Cisco Catalyst 4500 ਦੇ SVI ਇੰਟਰਫੇਸਾਂ 'ਤੇ ਪਹੁੰਚ ਨੂੰ ਕੰਟਰੋਲ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ। ਫਿਰ, ਜਿਵੇਂ ਕਿ ਇਸ ਤੋਂ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਹ ਲੇਖ, ਇੰਟਰਫੇਸ 'ਤੇ ਆਊਟਗੋਇੰਗ (ਨਾਲ ਹੀ ਆਉਣ ਵਾਲੇ) ਟ੍ਰੈਫਿਕ ਨੂੰ ਕੰਟਰੋਲ ਕਰਨ ਲਈ, ਤੁਸੀਂ ਸਿਰਫ 4096 TCAM ਲਾਈਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ। ਜੋ ਕਿ TCAM3 ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਤੁਹਾਨੂੰ ਲਗਭਗ 4000 ਹਜ਼ਾਰ ACEs (ACL ਲਾਈਨਾਂ) ਦੇਵੇਗਾ।

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

ਉੱਚ ਉਪਲਬਧਤਾ

ਸਵਾਲ ਇਹ ਹੈ: ਕੀ ਮੈਨੂੰ ਫਾਇਰਵਾਲ ਲਈ HA ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਜਾਂ "ਸਮਾਂਤਰ ਵਿੱਚ" ਦੋ ਸੁਤੰਤਰ ਬਕਸੇ ਸਥਾਪਤ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ ਅਤੇ, ਜੇਕਰ ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਅਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਦੂਜੇ ਰਾਹੀਂ ਆਵਾਜਾਈ ਨੂੰ ਰੂਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?

ਇਹ ਜਾਪਦਾ ਹੈ ਕਿ ਜਵਾਬ ਸਪੱਸ਼ਟ ਹੈ - HA ਦੀ ਵਰਤੋਂ ਕਰੋ. ਇਹ ਸਵਾਲ ਅਜੇ ਵੀ ਉੱਠਣ ਦਾ ਕਾਰਨ ਇਹ ਹੈ ਕਿ, ਬਦਕਿਸਮਤੀ ਨਾਲ, ਸਿਧਾਂਤਕ ਅਤੇ ਇਸ਼ਤਿਹਾਰਬਾਜ਼ੀ 99 ਅਤੇ ਅਭਿਆਸ ਵਿੱਚ ਪਹੁੰਚਯੋਗਤਾ ਦੇ ਕਈ ਦਸ਼ਮਲਵ ਪ੍ਰਤੀਸ਼ਤ ਇੰਨੇ ਗੁਲਾਬ ਤੋਂ ਬਹੁਤ ਦੂਰ ਹਨ। HA ਤਰਕਪੂਰਨ ਤੌਰ 'ਤੇ ਕਾਫ਼ੀ ਗੁੰਝਲਦਾਰ ਚੀਜ਼ ਹੈ, ਅਤੇ ਵੱਖ-ਵੱਖ ਉਪਕਰਣਾਂ 'ਤੇ, ਅਤੇ ਵੱਖ-ਵੱਖ ਵਿਕਰੇਤਾਵਾਂ (ਕੋਈ ਅਪਵਾਦ ਨਹੀਂ ਸਨ) ਦੇ ਨਾਲ, ਅਸੀਂ ਸਮੱਸਿਆਵਾਂ ਅਤੇ ਬੱਗ ਅਤੇ ਸੇਵਾ ਰੋਕਾਂ ਨੂੰ ਫੜ ਲਿਆ ਹੈ।

ਜੇ ਤੁਸੀਂ HA ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਵਿਅਕਤੀਗਤ ਨੋਡਾਂ ਨੂੰ ਬੰਦ ਕਰਨ, ਸੇਵਾ ਨੂੰ ਰੋਕੇ ਬਿਨਾਂ ਉਹਨਾਂ ਵਿਚਕਾਰ ਸਵਿਚ ਕਰਨ ਦਾ ਮੌਕਾ ਹੋਵੇਗਾ, ਜੋ ਕਿ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਅੱਪਗਰੇਡ ਕਰਨ ਵੇਲੇ, ਪਰ ਉਸੇ ਸਮੇਂ ਤੁਹਾਡੇ ਕੋਲ ਜ਼ੀਰੋ ਸੰਭਾਵਨਾ ਤੋਂ ਬਹੁਤ ਦੂਰ ਹੈ ਕਿ ਦੋਵੇਂ ਨੋਡ ਉਸੇ ਸਮੇਂ ਟੁੱਟ ਜਾਵੇਗਾ, ਅਤੇ ਇਹ ਵੀ ਕਿ ਅਗਲਾ ਅਪਗ੍ਰੇਡ ਵਿਕਰੇਤਾ ਦੇ ਵਾਅਦੇ ਅਨੁਸਾਰ ਸੁਚਾਰੂ ਢੰਗ ਨਾਲ ਨਹੀਂ ਜਾਵੇਗਾ (ਇਸ ਸਮੱਸਿਆ ਤੋਂ ਬਚਿਆ ਜਾ ਸਕਦਾ ਹੈ ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਪ੍ਰਯੋਗਸ਼ਾਲਾ ਦੇ ਉਪਕਰਣਾਂ 'ਤੇ ਅਪਗ੍ਰੇਡ ਦੀ ਜਾਂਚ ਕਰਨ ਦਾ ਮੌਕਾ ਹੈ)।

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

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

ਪ੍ਰਬੰਧਨਯੋਗਤਾ

ਸਿਧਾਂਤ ਵਿੱਚ, HA ਨਿਯੰਤਰਣਯੋਗਤਾ ਬਾਰੇ ਵੀ ਹੈ। 2 ਬਾਕਸਾਂ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਕੌਂਫਿਗਰ ਕਰਨ ਅਤੇ ਸੰਰਚਨਾਵਾਂ ਨੂੰ ਸਮਕਾਲੀਕਰਨ ਵਿੱਚ ਰੱਖਣ ਦੀ ਸਮੱਸਿਆ ਨਾਲ ਨਜਿੱਠਣ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਇੰਨਾ ਪ੍ਰਬੰਧਿਤ ਕਰਦੇ ਹੋ ਜਿਵੇਂ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਡਿਵਾਈਸ ਸੀ।

ਪਰ ਸ਼ਾਇਦ ਤੁਹਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰੇ ਡੇਟਾ ਸੈਂਟਰ ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਫਾਇਰਵਾਲ ਹਨ, ਫਿਰ ਇਹ ਸਵਾਲ ਇੱਕ ਨਵੇਂ ਪੱਧਰ 'ਤੇ ਉੱਠਦਾ ਹੈ. ਅਤੇ ਸਵਾਲ ਸਿਰਫ ਸੰਰਚਨਾ ਬਾਰੇ ਨਹੀਂ ਹੈ, ਸਗੋਂ ਇਸ ਬਾਰੇ ਵੀ ਹੈ

• ਬੈਕਅੱਪ ਸੰਰਚਨਾ
• ਅੱਪਡੇਟ
• ਅੱਪਗਰੇਡ
• ਨਿਗਰਾਨੀ
• ਲਾਗਿੰਗ

ਅਤੇ ਇਹ ਸਭ ਕੇਂਦਰੀ ਪ੍ਰਬੰਧਨ ਪ੍ਰਣਾਲੀਆਂ ਦੁਆਰਾ ਹੱਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ.

ਇਸ ਲਈ, ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਤੁਸੀਂ ਪਾਲੋ ਆਲਟੋ ਫਾਇਰਵਾਲ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਪੈਨੋਰਾਮਾ ਅਜਿਹਾ ਹੱਲ ਹੈ।

ਜਾਰੀ ਰੱਖਣ ਲਈ

ਸਰੋਤ: www.habr.com