Azure NVA ਜਾਂਚ: ਜਵਾਬ ਕਿਉਂ ਕਿਸੇ ਹੋਰ ਫਾਇਰਵਾਲ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ

ਸ਼ਾਖਾ ਤੋਂ Azure ਤੱਕ ਦਾ ਪ੍ਰਵਾਹ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਸਹੀ ਢੰਗ ਨਾਲ ਰੂਟ ਹੋ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਫੇਲ੍ਹ ਹੋ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵੱਖ-ਵੱਖ ਡਿਵਾਈਸਾਂ ਵਿੱਚੋਂ ਲੰਘਦੀਆਂ ਹਨ। ਬੇਨਤੀ VPN ਰਾਹੀਂ ਸ਼ਾਖਾ ਛੱਡਦੀ ਹੈ, NVA A ਉੱਤੇ ਉਤਰਦੀ ਹੈ ਅਤੇ ਵਰਕਲੋਡ ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ। ਜਵਾਬ ਵਰਕਲੋਡ ਛੱਡਦਾ ਹੈ, NVA B ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨ ਵਾਲੇ ਰੂਟ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ ਅਤੇ ਉੱਥੇ ਹੀ ਮਰ ਜਾਂਦਾ ਹੈ। ਉਸ ਤਸਵੀਰ ਦਾ ਹਰ ਰੂਟ ਵੈਧ ਹੈ, ਅਤੇ TCP ਸੈਸ਼ਨ ਫਿਰ ਵੀ ਟੁੱਟਿਆ ਹੋਇਆ ਹੈ।

Request: branch -> VPN gateway -> NVA A -> workload
Reply:   workload -> NVA B -> VPN gateway -> branch

ਇਹੀ ਖਾਲੀ ਥਾਂ ਇੱਥੇ ਪੂਰਾ ਵਿਸ਼ਾ ਹੈ: ਰੂਟਿੰਗ ਕਨਵਰਜੈਂਸ ਅਤੇ ਸੈਸ਼ਨ-ਸਥਿਤੀ ਦੀ ਮਾਲਕੀ ਆਕ੍ਰਿਤੀ ਵਿੱਚ ਇੱਕੋ ਜਿਹੀਆਂ ਦਿਸਣ ਵਾਲੀਆਂ ਵੱਖਰੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹਨ।

Route Server ਅਸਲ ਵਿੱਚ ਕੀ ਪ੍ਰੋਗਰਾਮ ਕਰਦਾ ਹੈ

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

ਇਸ ਲਈ ਰੂਟ ਸਿੱਖਣਾ ਪਹੁੰਚਯੋਗਤਾ ਸਾਬਤ ਕਰਦਾ ਹੈ। ਇਹ ਇਸ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਦੂਜੇ ਸਿਰੇ ਦੀ ਡਿਵਾਈਸ ਨੇ ਇਹ ਪ੍ਰਵਾਹ ਪਹਿਲਾਂ ਦੇਖਿਆ ਹੈ ਜਾਂ ਨਹੀਂ।

ਡਿਜ਼ਾਈਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਪੜ੍ਹੋ

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

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

ਸਥਿਤੀ ਕਿੱਥੇ ਰਹਿੰਦੀ ਹੈ

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

ਇਸੇ ਲਈ ਦੋ ਸਿਹਤਮੰਦ NVA ਜਾਂਚ ਲਈ ਸਿਹਤ-ਜਾਂਚ ਨਹੀਂ ਹਨ। ਸਿਹਤ ਪਹੁੰਚਯੋਗਤਾ ਬਾਰੇ ਹੈ; ਜਾਂਚ ਇਸ ਬਾਰੇ ਹੈ ਕਿ ਕਿਹੜਾ ਇੰਸਟੈਂਸ ਸੈਸ਼ਨ ਰੱਖਦਾ ਹੈ।

ਸਮਰਥਿਤ HA ਮਾਡਲ ਅਤੇ ਹਰ ਇੱਕ ਕੀ ਵਾਅਦਾ ਕਰਦਾ ਹੈ

Microsoft's guidance on Virtual WAN ਰੂਟਿੰਗ ਇਰਾਦੇ ਬਾਰੇ Microsoft ਦੀ ਅਗਵਾਈ ਦੋਹਰੀ-ਭੂਮਿਕਾ ਕਨੈਕਟੀਵਿਟੀ ਅਤੇ ਫਾਇਰਵਾਲ NVA ਲਈ ਸੀਮਤ ਵਿਵਹਾਰ ਦੱਸਦੀ ਹੈ, ਜਿੱਥੇ ਸਿੱਧੀ ਰੂਟਿੰਗ ਹੱਬ ਦੀ ਆਮ ਸਮਮਿਤੀ ਲਾਗੂ ਕਰਨ ਨੂੰ ਬਾਈਪਾਸ ਕਰ ਸਕਦੀ ਹੈ। ਉਹ ਨੋਟ ਤੁਹਾਡੇ ਚੁਣੇ ਟੋਪੋਲੋਜੀ ਉੱਤੇ ਰੋਕਾਂ ਵਜੋਂ ਪੜ੍ਹੋ, ਸਰਗਰਮ-ਸਰਗਰਮ ਡਿਜ਼ਾਈਨ ਉੱਤੇ ਪਾਬੰਦੀ ਵਜੋਂ ਨਹੀਂ। ਜੋ ਵਿਕਰੇਤਾ ਜੋੜੀ ਸਥਿਤੀ ਸਿੰਕ ਕਰਦੀ ਹੈ, ਜਾਂ ਪ੍ਰਤੀ ਪ੍ਰਵਾਹ ਸਟੀਅਰ ਕਰਦੀ ਹੈ, ਉਹ ਸਮਰਥਿਤ ਹੋ ਸਕਦੀ ਹੈ। ਜੋ ਬਰਾਬਰ-ਲਾਗਤ ਜੋੜੀ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੁਝ ਨਹੀਂ ਕਰਦੀ, ਉਹ ਨਹੀਂ।

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

ਇਸ ਉੱਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਟੈਸਟ ਕਰਨਾ ਹੈ

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

ਹਰ ਪ੍ਰਵਾਹ ਨੂੰ ਉਸ ਡਿਵਾਈਸ ਨਾਲ ਸੰਬੰਧਿਤ ਕਰੋ ਜਿਸਨੇ ਉਸਨੂੰ ਸੰਭਾਲਿਆ। ਇੱਕ NVA ਉੱਤੇ ਪੈਕੇਟ ਕੈਪਚਰ ਲਗਭਗ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ ਜੇ ਜਵਾਬ ਕਦੇ ਉੱਥੇ ਵਾਪਸ ਨਹੀਂ ਆਇਆ।

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