Azure P2S VPN ਵਿੱਚ ਸਥਿਰ IP: ਕਲਾਇੰਟ ਦਾ ਪਤਾ ਕਿਉਂ ਬਦਲਦਾ ਹੈ
Azure point-to-site ਹਰ ਕਨੈਕਸ਼ਨ ਉੱਤੇ ਪੂਲ ਵਿੱਚੋਂ ਅਗਲਾ ਖਾਲੀ ਪਤਾ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਕਲਾਇੰਟ ਦਾ ਸਥਿਰ IP ਨਹੀਂ ਹੁੰਦਾ। ਇਸ ਦੀ ਬਜਾਏ ਰੇਂਜਾਂ ਜਾਂ ਪਛਾਣ ਉੱਤੇ ਪਹੁੰਚ ਆਧਾਰਿਤ ਕਰੋ।
ਹਰ Azure point-to-site ਕਲਾਇੰਟ ਪਰਮਾਣਿਕਰਨ ਸਮੇਂ ਪੂਲ ਵਿੱਚੋਂ ਪਤਾ ਲੈਂਦਾ ਹੈ ਅਤੇ ਉਸ ਨੂੰ ਸਿਰਫ਼ ਉਸ ਕਨੈਕਸ਼ਨ ਦੇ ਚੱਲਣ ਤੱਕ ਹੀ ਰੱਖਦਾ ਹੈ। ਕੋਈ ਰਾਖਵਾਂਕਰਨ ਸਾਰਣੀ ਨਹੀਂ, ਪ੍ਰਤੀ-ਵਰਤੋਂਕਾਰ ਮੈਪਿੰਗ ਨਹੀਂ, ਅਤੇ “ਇਸ ਵਿਅਕਤੀ ਨੂੰ ਹਮੇਸ਼ਾ 172.16.0.10 ਦਿਓ” ਦਾ ਅਰਥ ਰੱਖਣ ਵਾਲੀ ਕੋਈ ਗੇਟਵੇ ਸੈਟਿੰਗ ਨਹੀਂ। ਇਹੋ ਇੱਕ ਵਿਧੀ ਉਹ ਦੋਵੇਂ ਲੱਛਣ ਸਮਝਾਉਂਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਨਾਲ ਲੋਕ ਬਾਅਦ ਵਿੱਚ ਮਿਲਦੇ ਹਨ: ਪਹਿਲਾਂ ਮਿਲਦੇ ਵਰਤੋਂਕਾਰ ਨਾਲ ਹੁਣ ਨ ਮਿਲਣ ਵਾਲਾ NSG ਨਿਯਮ, ਅਤੇ ਕਿਸੇ ਵੱਲੋਂ ਜਾਣ-ਬੁੱਝ ਕੇ ਨ ਜੋੜੀ ਗਈ ਮਸ਼ੀਨ ਨੂੰ ਚੁੱਪਚਾਪ ਅੰਦਰ ਆਉਣ ਦੇਣ ਵਾਲੀ ਇਜਾਜ਼ਤ ਸੂਚੀ। ਨਿਯਮ ਨੂੰ ਹੋਰ ਚਤੁਰ IP ਨਿਯਮ ਨਾਲ ਬਦਲਣਾ ਦੋਹਾਂ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਠੀਕ ਨਹੀਂ ਕਰਦਾ, ਕਿਉਂਕਿ ਨਿਯਮ ਜਿਸ ਚੀਜ਼ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ ਉਹ ਤੁਹਾਡੇ ਕੰਟਰੋਲ ਤੋਂ ਬਾਹਰ ਦੇ ਸਮਾਂ-ਸਾਰਣੀ ਅਨੁਸਾਰ ਦੁਬਾਰਾ ਵੰਡੀ ਜਾਂਦੀ ਹੈ।
ਪੂਲ ਸਮਰੱਥਾ ਹੈ, ਪਛਾਣ ਨਹੀਂ। ਇਹ ਇਸ ਲਈ ਹੈ ਕਿ ਇੱਕੋ ਸਮੇਂ ਦੇ ਟਨਲਾਂ ਨੂੰ ਵਿਲੱਖਣ ਪਤੇ ਮਿਲਣ, ਅਤੇ ਲੀਜ਼ ਖ਼ਤਮ ਹੁੰਦੇ ਹੀ ਇਹ ਉਨ੍ਹਾਂ ਨੂੰ ਮੁੜ ਵਰਤਦਾ ਹੈ। ਜਦੋਂ ਇਹ ਸਪਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਲਾਹੇਵੰਦ ਸਵਾਲ “ਇਸ ਕਲਾਇੰਟ ਨੂੰ ਕਿਵੇਂ ਪਿੰਨ ਕਰਾਂ” ਰਹਿੰਦਾ ਨਹੀਂ ਅਤੇ “ਗੇਟਵੇ ਜਿਸ ਨੂੰ ਮੁੜ ਨਹੀਂ ਵਰਤੇਗਾ ਉਸ ਦੇ ਖਿਲਾਫ਼ ਮੈਂ ਕੀ ਨਿਯਮ ਲਿਖ ਸਕਦਾ ਹਾਂ” ਬਣ ਜਾਂਦਾ ਹੈ।
ਕਲਾਇੰਟ ਕਨੈਕਟ ਹੋਣ ਵੇਲੇ ਗੇਟਵੇ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦਾ ਹੈ
ਗੇਟਵੇ ਸੰਰਚਿਤ ਕਲਾਇੰਟ ਪਤਾ ਪੂਲ ਰੱਖਦਾ ਹੈ ਅਤੇ ਉਸ ਨੂੰ ਲੀਜ਼ ਸਾਰਣੀ ਵਜੋਂ ਵਰਤਦਾ ਹੈ। ਕਨੈਕਟ ਹੋਣ ਵੇਲੇ ਇਹ ਅਗਲਾ ਖਾਲੀ ਪਤਾ, ਅਮਲ ਵਿੱਚ ਸਭ ਤੋਂ ਘੱਟ ਉਪਲਬਧ, ਲੈਂਦਾ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਦੇ ਡਿਸਕਨੈਕਟ ਹੋਣ ਜਾਂ ਲੀਜ਼ ਖ਼ਤਮ ਹੋਣ ਤੱਕ ਉਹ ਟਨਲ ਅਡਾਪਟਰ ਨੂੰ ਦਿੰਦਾ ਹੈ। ਫ਼ੈਸਲਾ ਕ੍ਰਮ ਕਰਦਾ ਹੈ, ਪਛਾਣ ਨਹੀਂ: ਸ਼ਾਂਤ ਸਮੇਂ ਤੋਂ ਬਾਅਦ ਪਹਿਲਾਂ ਮੁੜ ਕਨੈਕਟ ਕਰਨ ਵਾਲੇ ਨੂੰ ਉਸ ਪਲ ਸੰਜੋਗ ਨਾਲ ਖਾਲੀ ਪਏ ਸਭ ਤੋਂ ਘੱਟ ਪਤੇ ਮਿਲਦੇ ਹਨ।
ਪੂਲ ਦਾ ਆਕਾਰ ਵਿਵਹਾਰ ਲੁਕਾਉਂਦਾ ਹੈ। ਪਰਖਿਆਂ ਦੀ ਗਿਣਤੀ ਤੋਂ ਇੱਕ-ਦੋ ਪਤੇ ਵੱਡਾ ਲੈਬ ਪੂਲ ਨਿਸਚਿਤ ਜਿਹਾ ਲੱਗਦਾ ਹੈ, ਕਿਉਂਕਿ ਉਹੋ ਲੈਪਟਾਪ ਹਰ ਸਵੇਰ ਉਸੇ ਕ੍ਰਮ ਵਿੱਚ ਮੁੜ ਕਨੈਕਟ ਕਰਦਾ ਹੈ। ਤੀਜੀ ਮਸ਼ੀਨ ਸ਼ਾਮਲ ਕਰੋ, ਪੂਲ ਦਾ ਆਕਾਰ ਬਦਲੋ, ਜਾਂ ਦੁਪਹਿਰ ਦੇ ਖਾਣੇ ਵੇਲੇ ਸੈਸ਼ਨ ਕਨੈਕਟਿਡ ਛੱਡੋ — ਪੈਟਰਨ ਟੁੱਟ ਜਾਂਦਾ ਹੈ। ਪਤਾ ਕਦੇ ਸਥਿਰ ਨਹੀਂ ਸੀ; ਕਤਾਰ ਸਥਿਰ ਸੀ।
point-to-site ਸੰਰਚਨਾ ਵਿੱਚ ਕੋਈ ਵੀ ਬਦਲਾਅ ਲੀਜ਼ ਥਾਂ ਵੀ ਰੀਸੈਟ ਕਰਦਾ ਹੈ। ਵੱਖਰੀ ਪਰਮਾਣਿਕਰਨ ਕਿਸਮ, ਬਦਲੇ ਆਕਾਰ ਦਾ ਪੂਲ, ਨਵੀਂ ਪੂਲ ਰੇਂਜ, ਜਾਂ ਤੋੜ ਕੇ ਮੁੜ ਬਣਾਇਆ ਗੇਟਵੇ — ਸਾਰੇ ਕਲਾਇੰਟਾਂ ਨੂੰ ਉਨ੍ਹਾਂ ਦੇ ਪੁਰਾਣੇ ਪਤਿਆਂ ਨਾਲ ਹੁਣ ਨ ਮਿਲਦੇ ਪੂਲ ਵਿੱਚ ਵਾਪਸ ਭੇਜਦੇ ਹਨ। ਉਸ ਬਦਲਾਅ ਵਿੱਚ ਕੁਝ ਵੀ ਤੁਹਾਡੇ NSG ਨੂੰ ਨਹੀਂ ਛੂਹੰਦਾ, ਇਸ ਲਈ ਖ਼ਰਾਬੀ ਆਪਣੇ ਆਪ ਹੋਈ ਜਾਪਦੀ ਹੈ।
ਇਹ ਲਗਭਗ ਇੱਕ ਮਿੰਟ ਵਿੱਚ ਵੇਖ ਸਕਦੇ ਹੋ। ਕਨੈਕਟ ਕਰੋ, ਕਲਾਇੰਟ ਦੇ ਕਨੈਕਸ਼ਨ ਵੇਰਵਿਆਂ ਵਿੱਚ ਟਨਲ ਪਤਾ ਨੋਟ ਕਰੋ, ਡਿਸਕਨੈਕਟ ਕਰੋ, ਦੂਜੀ ਮਸ਼ੀਨ ਕਨੈਕਟ ਕਰੋ, ਫਿਰ ਪਹਿਲੀ ਮੁੜ ਕਨੈਕਟ ਕਰੋ। ਵਾਪਸ ਮਿਲਣ ਵਾਲਾ ਪਤਾ ਇਸ ਉੱਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਦੂਜੀ ਮਸ਼ੀਨ ਕੀ ਰੱਖੀ ਹੋਈ ਹੈ, ਅਤੇ ਕੋਈ ਵੀ ਪੋਰਟਲ ਸੈਟਿੰਗ ਮੰਗ ਉੱਤੇ ਪਿਛਲਾ ਪਤਾ ਬਹਾਲ ਨਹੀਂ ਕਰੇਗੀ।
ਕਲਾਇੰਟ IP ਉੱਤੇ ਆਧਾਰਿਤ NSG ਅਸਲ ਵਿੱਚ ਕਨੈਕਸ਼ਨ ਕ੍ਰਮ ਬਾਰੇ ਇੱਕ ਨਿਯਮ ਹੈ
ਲੋਕ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਜੋ ਨਿਯਮ ਲਿਖਦੇ ਹਨ ਉਹ ਸਪਸ਼ਟ ਹੈ: ਪ੍ਰਬੰਧਨ VM ਦੇ NIC ਜਾਂ ਉਸ ਦੇ ਸਬਨੈੱਟ ਉੱਤੇ ਇਨਬਾਊਂਡ ਨਿਯਮ, ਸਰੋਤ ਵਜੋਂ VPN ਕਲਾਇੰਟ ਦਾ ਅੰਦਰੂਨੀ ਪਤਾ। ਇਹ ਛੋਟਾ ਹੈ, ਲਿਖੇ ਜਾਣ ਵਾਲੇ ਦਿਨ ਪਰਖ ਪਾਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਪੂਲ ਵਿੱਚ ਇੱਕ ਤੋਂ ਵੱਧ ਖਾਲੀ ਪਤਾ ਹੁੰਦਿਆਂ ਹੀ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦਾ ਹੈ।
ਇਸ ਤੋਂ ਫੇਲ੍ਹ ਹੋਣ ਦੇ ਦੋ ਢੰਗ ਨਿਕਲਦੇ ਹਨ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਬੱਗ ਵਰਗਾ ਦਿਸਦਾ ਹੈ। ਕਾਨੂੰਨੀ ਵਰਤੋਂਕਾਰ ਨੂੰ ਨਾਂਹ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਨਿਯਮ ਜਿਸ ਪਤੇ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ ਉਹ ਉਸ ਵੇਲੇ ਕਿਸੇ ਹੋਰ ਕੋਲ ਹੈ, ਅਤੇ ਇਹ ਪਰੇਸ਼ਾਨ ਕਰਨ ਵਾਲੀ ਸਹਾਇਤਾ ਟਿਕਟ ਵਜੋਂ ਆਉਂਦਾ ਹੈ। ਜਾਂ ਅਣਚਾਹੇ ਵਰਤੋਂਕਾਰ ਨੂੰ ਇਜਾਜ਼ਤ ਮਿਲ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਉਸ ਨੂੰ ਨਿਯਮ ਜਿਸ ਪਤੇ ਉੱਤੇ ਅਜੇ ਵੀ ਭਰੋਸਾ ਕਰਦਾ ਹੈ ਉਹ ਵਿਰਾਸਤ ਵਿੱਚ ਮਿਲਿਆ ਹੈ, ਅਤੇ ਇਹ ਕੁਝ ਵੀ ਵਜੋਂ ਨਹੀਂ ਆਉਂਦਾ ਜਦ ਤੱਕ ਕੋਈ ਪਹੁੰਚ ਦਾ ਆਡਿਟ ਨ ਕਰੇ।
ਨਿਯਮ ਲੀਜ਼ ਦਾ ਪਿੱਛਾ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਪ੍ਰਭਾਵੀ ਨੀਤੀ “ਜੋ ਪਹਿਲਾਂ ਕਨੈਕਟ ਕਰਦਾ ਹੈ ਉਸ ਨੂੰ ਪ੍ਰਬੰਧਨ ਪਹੁੰਚ ਮਿਲਦੀ ਹੈ” ਪੜ੍ਹੀ ਜਾਂਦੀ ਹੈ। ਇਹ ਇਰਾਦੇ ਦੇ ਭੇਸ ਵਿੱਚ ਕਨੈਕਸ਼ਨ ਕ੍ਰਮ ਦਾ ਵਰਣਨ ਹੈ, ਅਤੇ ਕੋਈ ਨਿਯਮ ਸਫ਼ਾਈ ਇਸ ਨੂੰ ਇਰਾਦੇ ਦਾ ਪ੍ਰਗਟਾਵਾ ਨਹੀਂ ਬਣਾਉਂਦੀ।
ਕਲਾਇੰਟ ਲੀਜ਼ ਅਤੇ ਗੇਟਵੇ ਪਤਾ ਵੱਖਰੀਆਂ ਵਸਤੂਆਂ ਹਨ
ਬਹੁਤੀ ਉਲਝਣ ਇੱਕ ਸ਼ਬਦ ਤੋਂ ਆਉਂਦੀ ਹੈ। ਗੇਟਵੇ ਕੋਲ ਤੁਲਨਾਤਮਕ ਤੌਰ ਉੱਤੇ ਸਥਿਰ ਜਨਤਕ IP ਹੈ; ਕਲਾਇੰਟ ਕੋਲ ਪੂਲ ਵਿੱਚੋਂ ਨਿੱਜੀ ਪਤੇ ਹਨ, ਜੋ ਸਥਿਰ ਨਹੀਂ। ਜ਼ੋਨ-ਰਿਡੰਡੈਂਟ ਨਾ ਹੋਣ ਵਾਲੇ VPN ਗੇਟਵੇ ਲਈ ਜਨਤਕ IP ਗਤੀਸ਼ੀਲ ਢੰਗ ਨਾਲ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਪਰ ਇਹ ਆਕਾਰ ਬਦਲਾਅ, ਰੀਸੈਟ ਅਤੇ ਰੁਟੀਨ ਸੰਭਾਲ ਨੂੰ ਝੱਲ ਲੈਂਦਾ ਹੈ — ਇਹ ਤਦ ਬਦਲਦਾ ਹੈ ਜਦੋਂ ਗੇਟਵੇ ਆਪ ਮਿਟਾ ਕੇ ਮੁੜ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ। ਜ਼ੋਨ-ਰਿਡੰਡੈਂਟ ਅਤੇ ਜ਼ੋਨਲ ਗੇਟਵੇ SKU Standard SKU ਦਾ ਜਨਤਕ IP ਵਰਤਦੇ ਹਨ, ਅਤੇ ਉਹ ਅਲਾਟਮੈਂਟ ਸਥਿਰ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
ਇਹੋ ਸਥਿਰਤਾ ਆਨ-ਪ੍ਰੀਮਾਈਸਿਜ਼ ਸਾਥੀ ਨੂੰ ਆਪਣੀ ਸੰਰਚਨਾ ਵਿੱਚ ਲੋੜੀਂਦੀ ਹੈ, ਅਤੇ ਇਹ ਵਿਅਕਤੀਗਤ ਕਲਾਇੰਟ ਦੀ ਪਛਾਣ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ। ਜਦੋਂ ਸਾਥੀ ਪੁੱਛਦਾ ਹੈ ਕਿ ਉਹ ਕਿਹੜਾ ਪਤਾ ਵੇਖੇਗਾ, ਤਾਂ ਜਵਾਬ site-to-site ਵਿੱਚ ਗੇਟਵੇ ਦਾ ਜਨਤਕ IP, ਜਾਂ ਸਾਂਝੀ NAT ਰੇਂਜ ਹੈ — ਕਦੇ ਵੀ ਲੈਪਟਾਪ ਦੀ ਟਨਲ ਲੀਜ਼ ਨਹੀਂ।
ਗਰੁੱਪ ਪੂਲ ਤੁਹਾਨੂੰ ਉਹ ਰੇਂਜ ਦਿੰਦੇ ਹਨ ਜਿਸ ਦੇ ਖਿਲਾਫ਼ ਨਿਯਮ ਲਿਖਣਾ ਲਾਹੇਵੰਦ ਹੈ
Virtual WAN point-to-site ਵਰਤੋਂਕਾਰ ਗਰੁੱਪਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਹਰ ਗਰੁੱਪ ਨੂੰ ਆਪਣਾ ਕਲਾਇੰਟ ਪਤਾ ਪੂਲ ਦਿੱਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਮੈਂਬਰਸ਼ਿਪ ਪਛਾਣ ਨਾਲ ਤੈਅ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਕਲਾਇੰਟ ਜਿਸ ਰੇਂਜ ਵਿੱਚ ਪੈਂਦਾ ਹੈ ਉਹ ਅਨੁਮਾਨਯੋਗ ਹੋ ਜਾਂਦੀ ਹੈ: ਕਾਰਜ ਇੱਕ ਰੇਂਜ ਵਿੱਚ, ਠੇਕੇਦਾਰ ਦੂਜੀ ਵਿੱਚ, ਅਤੇ ਰੇਂਜ ਉਹ ਚੀਜ਼ ਹੈ ਜਿਸ ਦਾ ਨਾਮ ਫਾਇਰਵਾਲ ਜਾਂ NSG ਨਿਯਮ ਅਨੁਮਾਨ ਲਾਏ ਬਿਨਾਂ ਲੈ ਸਕਦਾ ਹੈ।
ਨਤੀਜੇ ਵਜੋਂ ਬਣੇ ਨਿਯਮ ਸਮੂਹ ਦਾ ਆਕਾਰ ਇਹੋ ਜਿਹਾ ਹੈ ਜਿਸ ਦੀ ਤੁਸੀਂ ਸਮੀਖਿਆ ਕਰ ਸਕਦੇ ਹੋ:
- ਹਰ ਦਰਸ਼ਕ ਲਈ ਇੱਕ ਪੂਲ, ਸਿਰਾਂ ਦੀ ਗਿਣਤੀ ਦੀ ਬਜਾਏ ਇੱਕੋ ਸਮੇਂ ਦੇ ਸੈਸ਼ਨਾਂ ਦੇ ਸਿਖਰ ਲਈ ਮਾਪਿਆ;
- ਗਰੁੱਪ ਮੈਂਬਰਸ਼ਿਪ ਪਛਾਣ ਰਾਹੀਂ ਸੰਭਾਲੀ ਜਾਂਦੀ ਹੈ, ਕੋਈ ਸ਼ਾਮਲ ਹੁੰਦਿਆਂ ਹੀ ਨਿਯਮ ਸੋਧ ਕੇ ਨਹੀਂ;
- NSG ਜਾਂ Azure Firewall ਨਿਯਮ ਪੂਲ ਰੇਂਜਾਂ ਦੇ ਖਿਲਾਫ਼ ਲਿਖੇ ਜਾਂਦੇ ਹਨ, ਕਦੇ ਵੀ ਵਿਅਕਤੀਗਤ ਲੀਜ਼ਾਂ ਦੇ ਖਿਲਾਫ਼ ਨਹੀਂ;
- ਉਹਨਾਂ ਦਰਸ਼ਕਾਂ ਲਈ ਵੱਖਰਾ ਹੱਬ ਜਾਂ ਗੇਟਵੇ ਜਿਨ੍ਹਾਂ ਨੂੰ ਕਦੇ ਰੇਂਜ ਸਾਂਝੀ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ।
| Rule target | Survives a reconnect | What it still cannot express |
|---|---|---|
| Client tunnel address | No | Follows connection order and admits whoever holds the address next |
| Whole client pool | Yes | Grants every connected client identical access |
| Virtual WAN group pool | Yes | Only as reliable as group membership |
| Gateway public IP | Until the gateway is recreated | Identifies the site, not the person |
ਪੂਰਾ ਪੂਲ ਇਜਾਜ਼ਤ ਸੂਚੀ ਵਿੱਚ ਪਾਉਣਾ ਇਮਾਨਦਾਰ ਪਰ ਮੋਟਾ ਹੈ: ਉਸ ਰੇਂਜ ਵਿੱਚ ਹਰ ਕਨੈਕਟਿਡ ਕਲਾਇੰਟ ਨੂੰ ਇੱਕੋ ਪਹੁੰਚ ਮਿਲਦੀ ਹੈ। ਇਹ ਉਹ ਨੀਤੀ ਫ਼ੈਸਲਾ ਹੈ ਜੋ ਸਮੀਖਿਆ ਦੌਰਾਨ ਖੋਜਣ ਦੀ ਬਜਾਏ ਉੱਚੀ ਆਵਾਜ਼ ਵਿੱਚ ਕਹਿਣਾ ਚਾਹੀਦਾ ਹੈ। ਜਿਸ ਨੂੰ ਅਜੇ ਵੀ ਪ੍ਰਤੀ-ਵਿਅਕਤੀ ਜਵਾਬ ਚਾਹੀਦਾ ਹੈ ਉਹ ਭੂਮਿਕਾ ਨਿਯੋਜਨਾਂ ਰਾਹੀਂ ਸਰੋਤ ਕੋਲ ਹੁੰਦਾ ਹੈ, ਪੈਕਟ ਫਿਲਟਰ ਕੋਲ ਨਹੀਂ।
ਜਦੋਂ ਤੈਨਾਤੀ Virtual WAN ਉੱਤੇ ਨਹੀਂ ਜਾ ਸਕਦੀ
ਬਹੁਤ ਸਾਰੇ ਗੇਟਵੇ ਆਮ VPN ਗੇਟਵੇ ਹੀ ਰਹਿੰਦੇ ਹਨ, ਅਤੇ Virtual WAN ਉੱਤੇ ਜਾਣਾ ਮਾਮੂਲੀ ਬਦਲਾਅ ਨਹੀਂ। ਵਿਹਾਰਕ ਜਵਾਬ ਇਹ ਹੈ ਕਿ ਪ੍ਰਤੀ-ਵਰਤੋਂਕਾਰ ਫ਼ੈਸਲਾ ਪੈਕਟ ਫਿਲਟਰ ਤੋਂ ਉਸ ਚੀਜ਼ ਵੱਲ ਭੇਜੋ ਜੋ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦੀ ਹੈ ਕਿ ਵਰਤੋਂਕਾਰ ਕੌਣ ਹੈ।
ਸਰੋਤ-ਪੱਧਰ ਦੀ ਪਛਾਣ ਸਭ ਤੋਂ ਸਸਤਾ ਸੰਸਕਰਣ ਹੈ। Storage, SQL ਅਤੇ Key Vault ਸਾਰੇ ਪ੍ਰਤੀ-ਵਰਤੋਂਕਾਰ ਜਾਂ ਪ੍ਰਤੀ-ਗਰੁੱਪ ਭੂਮਿਕਾ ਨਿਯੋਜਨਾਂ ਨਾਲ Entra ID ਪਰਮਾਣਿਕਰਨ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ VPN ਨੂੰ ਸਿਰਫ਼ ਨੈੱਟਵਰਕ ਪਹੁੰਚ ਸਿੱਧ ਕਰਨੀ ਪੈਂਦੀ ਹੈ। ਨਾਮ ਵਾਲੇ ਖਾਤਿਆਂ ਵਾਲਾ ਜੰਪ ਹੋਸਟ ਪ੍ਰਬੰਧਕੀ ਕੰਮ ਲਈ ਉਹੋ ਕੰਮ ਕਰਦਾ ਹੈ, ਕਿਉਂਕਿ ਹੋਸਟ ਵਿਅਕਤੀ ਨੂੰ ਦਰਜ ਕਰਦਾ ਹੈ ਅਤੇ ਟਨਲ ਸਿਰਫ਼ ਪੈਕਟ ਢੋਂਦਾ ਹੈ। ਕਲਾਇੰਟਾਂ ਨੂੰ DNS ਵਿੱਚ ਦਰਜ ਕਰਨਾ ਅਤੇ ਸੰਖਿਆ ਦੀ ਬਜਾਏ ਨਾਮ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦੇਣਾ ਨਿਯਮ ਨੂੰ ਇੱਕ ਪਰਤ ਉੱਪਰ ਚੁੱਕਦਾ ਹੈ। ਐਪਲੀਕੇਸ਼ਨ-ਪੱਧਰ ਦੀ ਪਛਾਣ — ਸਰਟੀਫਿਕੇਟ ਵਿਸ਼ਾ, ਟੋਕਨ ਦਾਅਵਾ, ਗਰੁੱਪ ਮੈਂਬਰਸ਼ਿਪ — ਤਦ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਫ਼ੈਸਲਾ ਲੈਣ ਲਈ ਨੈੱਟਵਰਕ ਨਹੀਂ, ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ।
ਜੋ ਸਾਥੀ ਸਥਿਰ ਸਰੋਤ ਪਤੇ ਉੱਤੇ ਜ਼ੋਰ ਦਿੰਦਾ ਹੈ, ਉਸ ਲਈ ਜਵਾਬ ਨਿਰਧਾਰਿਤ ਪੀਅਰ ਪ੍ਰੀਫਿਕਸ ਨਾਲ site-to-site ਜਾਂ ExpressRoute ਹੈ। ਉਹ ਪੀਅਰ ਪ੍ਰੀਫਿਕਸ ਨੂੰ ਮਨਜ਼ੂਰੀ ਦਿੰਦੇ ਹਨ, ਉਨ੍ਹਾਂ ਦੇ ਪਾਸੇ ਦਿਸਣ ਵਾਲਾ ਪਤਾ ਗੇਟਵੇ ਦਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਲੈਪਟਾਪ ਰੀਬੂਟ ਕਰੇ ਤਾਂ ਉਹ ਨਹੀਂ ਬਦਲਦਾ।
ਹੋਰ ਇਜਾਜ਼ਤ ਸੂਚੀ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਪੂਲ ਜਾਂਚੋ
ਪੂਲ ਦੇ ਦੋ ਗੁਣ ਉਹ ਵਿਵਹਾਰ ਪੈਦਾ ਕਰਦੇ ਹਨ ਜਿਸ ਦਾ ਦੋਸ਼ ਲੋਕ ਕਲਾਇੰਟ ਉੱਤੇ ਪਾਉਂਦੇ ਹਨ। ਬਹੁਤ ਛੋਟਾ ਪੂਲ ਲੀਜ਼ਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਮੁੜ ਵਰਤਦਾ ਹੈ, ਇਸ ਲਈ ਪਤੇ ਲਗਾਤਾਰ ਸਰਕਦੇ ਦਿਸਦੇ ਹਨ ਅਤੇ ਪਤੇ ਉੱਤੇ ਆਧਾਰਿਤ ਕੋਈ ਵੀ ਨਿਯਮ ਡਿਜ਼ਾਈਨ ਤੋਂ ਹੀ ਡਗਮਗਾਉਂਦਾ ਲੱਗਦਾ ਹੈ। ਜੋ ਪੂਲ ਆਨ-ਪ੍ਰੀਮਾਈਸਿਜ਼ ਰੇਂਜਾਂ ਜਾਂ ਵਰਚੁਅਲ ਨੈੱਟਵਰਕ ਥਾਂ ਨਾਲ ਓਵਰਲੈਪ ਹੁੰਦਾ ਹੈ ਉਹ ਰੂਟਿੰਗ ਅਸਪਸ਼ਟਤਾ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜਿਸ ਨੂੰ ਕੋਈ ਫਾਇਰਵਾਲ ਨਿਯਮ ਠੀਕ ਨਹੀਂ ਕਰਦਾ।
ਕਿਸੇ ਨਿਯਮ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਤਿੰਨ ਚੀਜ਼ਾਂ ਇੱਕ ਪੰਨੇ ਉੱਤੇ ਰੱਖੋ: point-to-site ਪੂਲ, ਵਰਚੁਅਲ ਨੈੱਟਵਰਕ ਪਤਾ ਥਾਂ ਅਤੇ ਆਨ-ਪ੍ਰੀਮਾਈਸਿਜ਼ ਰੇਂਜਾਂ। ਇਨ੍ਹਾਂ ਦਾ ਓਵਰਲੈਪ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ, ਅਤੇ ਪੂਲ ਨੂੰ ਹਰ ਇੱਕੋ ਸਮੇਂ ਦੇ ਕਲਾਇੰਟ ਲਈ ਥਾਂ ਤੇ ਮੁੜ ਕਨੈਕਟ ਲਈ ਕੁਝ ਮਾਰਜਿਨ ਚਾਹੀਦਾ ਹੈ।
ਫਿਰ ਇਸ ਕ੍ਰਮ ਵਿੱਚ ਚੱਕਰ ਬੰਦ ਕਰੋ:
- ਦੋ ਮਸ਼ੀਨਾਂ ਤੋਂ ਦੋਵੇਂ ਕ੍ਰਮਾਂ ਵਿੱਚ ਕਨੈਕਟ ਕਰੋ ਅਤੇ ਪਤਿਆਂ ਦੀ ਤੁਲਨਾ ਕਰੋ; ਜੇ ਉਹ ਬਦਲ ਸਕਦੇ ਹਨ, ਤਾਂ ਪਤੇ ਉੱਤੇ ਆਧਾਰਿਤ ਕੋਈ ਨਿਯਮ ਸੁਰੱਖਿਅਤ ਨਹੀਂ।
- ਜਾਂਚੋ ਕਿ ਗੇਟਵੇ Virtual WAN ਹੈ ਜਾਂ ਨਹੀਂ; ਜੇ ਹੈ, ਤਾਂ ਪ੍ਰਤੀ-ਪਤਾ ਨਿਯਮਾਂ ਦੀ ਬਜਾਏ ਗਰੁੱਪ ਪੂਲ ਵਰਤੋ।
- ਪੁੱਛੋ ਕਿ ਜਦੋਂ ਨਿਯਮ ਗ਼ਲਤ ਵਿਅਕਤੀ ਨਾਲ ਮਿਲਦਾ ਹੈ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ; ਜਵਾਬ ਪਹੁੰਚ ਘਟਨਾ ਹੋਵੇ, ਤਾਂ ਕੰਟਰੋਲ ਪਛਾਣ ਵੱਲ ਭੇਜੋ।
- ਕਿਹੜੀ ਰੇਂਜ ਕਿਹੜੇ ਗਰੁੱਪ ਦੀ ਹੈ, ਇਹ NSG ਪਰਿਭਾਸ਼ਾਵਾਂ ਵਾਲੇ ਉਸੇ ਭੰਡਾਰ ਵਿੱਚ ਦਰਜ ਕਰੋ।
- ਪੂਲ, ਪਰਮਾਣਿਕਰਨ ਜਾਂ ਗੇਟਵੇ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਮੁੜ ਪਰਖ ਕਰੋ, ਕਿਉਂਕਿ ਉਹ ਬਦਲਾਅ ਐਲਾਨ ਕੀਤੇ ਬਿਨਾਂ ਮੈਪਿੰਗ ਮੁੜ ਲਿਖਦੇ ਹਨ।