Azure Site VPN ਨਿਗਰਾਨੀ: ਟਨਲ ਦੀ ਸਥਿਤੀ ਨੂੰ ਅਸਲੀ ਪ੍ਰੋਬ ਨਾਲ ਜੋੜੋ

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

ਟਨਲ ਤੋਂ ਨਹੀਂ, ਫੇਲ੍ਹ ਹੋ ਰਹੇ ਲੱਛਣ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ

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

ਤਿੰਨ ਸਥਿਤੀਆਂ ਵੱਖ ਕੀਤੀਆਂ ਜਾਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ: ਟਨਲ ਬੰਦ ਹੈ, ਟਨਲ ਚਾਲੂ ਹੈ ਪਰ ਸੇਵਾ ਫੇਲ੍ਹ ਹੈ, ਅਤੇ ਨਿਗਰਾਨੀ ਸਰੋਤ ਆਪ ਹੀ ਉਪਲਬਧ ਨਹੀਂ।

ਪ੍ਰੋਬ ਉੱਥੇ ਰੱਖੋ ਜਿੱਥੇ ਵਰਤੋਂਕਾਰ ਹਨ

ਸ਼ਾਖਾ ਤੋਂ Azure ਐਪ ਲਈ, ਸਿੰਥੈਟਿਕ ਟੈਸਟ ਸ਼ਾਖਾ ਦੇ ਵਰਕਲੋਡ ਨੈੱਟਵਰਕ ਦੇ ਹੋਸਟ ਤੋਂ ਚਲਾਓ ਅਤੇ ਉਸ ਨਿਜੀ HTTPS ਪ੍ਰਵੇਸ਼ ਬਿੰਦੂ ਵੱਲ ਨਿਸ਼ਾਨਾ ਬਣਾਓ ਜਿੱਥੇ ਵਰਤੋਂਕਾਰ ਅਸਲ ਵਿੱਚ ਪਹੁੰਚਦੇ ਹਨ। ਗੇਟਵੇ ਤੋਂ ਸ਼ੁਰੂ ਕੀਤਾ ਪ੍ਰੋਬ ਵੱਖਰਾ ਸਰੋਤ ਪਤਾ ਅਤੇ ਅਕਸਰ ਵੱਖਰਾ ਨੀਤੀ ਮਾਰਗ ਵਰਤਦਾ ਹੈ, ਇਸ ਲਈ ਹਰ ਵਰਤੋਂਕਾਰ ਦੇ ਫੇਲ੍ਹ ਹੁੰਦੇ ਹੋਏ ਵੀ ਉਹ ਪਾਸ ਹੋ ਸਕਦਾ ਹੈ। Azure Connection Monitor ਟੈਸਟ ਗਰੁੱਪਾਂ ਅਤੇ ਸੀਮਾਵਾਂ ਨਾਲ TCP, ICMP ਅਤੇ HTTP ਜਾਂਚਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਸ ਦੇ ਸਥਾਨਕ ਸਰੋਤਾਂ ਦੀਆਂ ਏਜੰਟ ਲੋੜਾਂ Azure ਪਾਸੇ ਵਾਲੀਆਂ ਤੋਂ ਵੱਖਰੀਆਂ ਹਨ। ਬਲੌਗ ਤੋਂ ਸੇਵਾਮੁਕਤ ਕਲਾਸਿਕ ਨਿਗਰਾਨੀ ਵਿਧੀ ਕਾਪੀ ਕਰਨ ਦੀ ਥਾਂ ਮੌਜੂਦਾ ਸਮਰਥਿਤ ਬਣਤਰ ਜਾਂਚੋ।

ਪ੍ਰੋਬ ਨੂੰ ਤੰਗ ਅਤੇ ਬੋਰਿੰਗ ਰੱਖੋ: ਇੱਕ ਮੰਜ਼ਿਲ, ਇੱਕ ਪੋਰਟ, ਕਾਰਜ ਲੋੜ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਬਾਰੰਬਾਰਤਾ, ਅਤੇ ਉਸ ਸਰੋਤ ਲਈ ਸਪਸ਼ਟ ਇਜਾਜ਼ਤ ਨਿਯਮ।

ਸੇਵਾ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਜਾਂਚ ਚੁਣੋ

ਸੇਵਾ ਪੋਰਟ ’ਤੇ TCP ਕਨੈਕਸ਼ਨ ਟਨਲ ਰਾਹੀਂ ਆਵਾਜਾਈ ਦੀ ਪਹੁੰਚ ਸਾਬਤ ਕਰਦਾ ਹੈ ਅਤੇ TLS ਜਾਂ ਐਪ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ। HTTP ਜਾਂਚ ਸਥਿਤੀ ਦੀ ਆਸ ਜੋੜਦੀ ਹੈ ਅਤੇ ਅਜਿਹੇ ਸਰੋਤੇ ਨੂੰ ਫੜਦੀ ਹੈ ਜੋ ਕਨੈਕਸ਼ਨ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਪਰ ਸੇਵਾ ਨਹੀਂ ਦੇ ਸਕਦਾ, ਜੋ ਸਰਟੀਫਿਕੇਟ ਜਾਂ ਬੈਕਐਂਡ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਵਧੇਰੇ ਆਮ ਫੇਲ੍ਹ ਹੈ। ਟੈਸਟ ਅਸਲ ਵਿੱਚ ਪ੍ਰਮਾਣਿਤ ਨਾ ਕਰੇ ਤਾਂ ਦੋਵੇਂ ਪ੍ਰਮਾਣਿਤ ਕਾਰੋਬਾਰੀ ਲੈਣ-ਦੇਣ ਨਹੀਂ, ਇਸ ਲਈ ਡੈਸ਼ਬੋਰਡ ’ਤੇ ਇਸ ਤਰ੍ਹਾਂ ਲੇਬਲ ਨਾ ਕਰੋ। ਵਰਤੋਂਕਾਰ ਦੀ ਸ਼ਿਕਾਇਤ ਹੋਣ ’ਤੇ ਫੇਲ੍ਹ ਹੋਣ ਵਾਲੀ ਜਾਂਚ ਚੁਣੋ।

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

ਦੋਵੇਂ ਸੰਕੇਤ ਬਣਾਏ ਬਿਨਾਂ Elastic ਵਿੱਚ ਲਿਆਓ

VPN ਗੇਟਵੇ ਟਨਲ ਦੇ ਬਾਹਰ ਅਤੇ ਅੰਦਰ ਜਾਣ ਵਾਲੇ ਬਾਈਟਾਂ ਅਤੇ ਪੈਕੇਟ ਡ੍ਰੌਪ ਕਾਊਂਟਰ ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਮੈਟ੍ਰਿਕ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਟਨਲ ਤੇ IKE ਘਟਨਾਵਾਂ ਸਮੇਤ ਸ਼੍ਰੇਣੀਆਂ ਵਿੱਚ ਨਿਦਾਨ ਲੌਗ ਭੇਜ ਸਕਦਾ ਹੈ। Connection Monitor ਦੇ ਨਤੀਜੇ Azure Monitor ਰਾਹੀਂ ਮੈਟ੍ਰਿਕ ਵਜੋਂ ਅਤੇ Log Analytics ਵਰਕਸਪੇਸ ਰਾਹੀਂ ਲੌਗ ਰਿਕਾਰਡ ਵਜੋਂ ਆਉਂਦੇ ਹਨ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਆਪਣੇ ਆਪ Elastic ਇੰਡੈਕਸ ਵਿੱਚ ਨਹੀਂ ਦਿਸਦਾ। ਮੈਟ੍ਰਿਕ ਲਈ ਇੱਕ ਸਮਰਥਿਤ ਪਾਈਪਲਾਈਨ ਅਤੇ ਲੌਗ ਲਈ ਦੂਜੀ ਚੁਣੋ, ਆਮ ਤੌਰ ’ਤੇ Azure Event Hub ਇਨਪੁਟ ਜਾਂ Azure Monitor ਏਕੀਕਰਣ, ਅਤੇ ਇੰਡੈਕਸ ਪੈਟਰਨ ’ਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚੋ ਕਿ ਸਥਾਪਿਤ ਏਕੀਕਰਣ ਅਸਲ ਵਿੱਚ ਕੀ ਲੈਂਦਾ ਹੈ।

ਉਹ ਲੇਬਲ ਰੱਖੋ ਜੋ ਅਪਰੇਟਰ ਨੂੰ ਦੋਵੇਂ ਡੇਟਾਸੈਟ ਜੋੜਨ ਦਿੰਦੇ ਹਨ: ਪ੍ਰੋਬ ਲਈ ਸਰੋਤ ਐਂਡਪੌਇੰਟ, ਮੰਜ਼ਿਲ, ਪ੍ਰੋਟੋਕੋਲ ਅਤੇ ਪੋਰਟ, ਅਤੇ ਗੇਟਵੇ ਲਈ ਟਨਲ ਪਛਾਣ ਤੇ ਸਾਥੀ ਪਤਾ।

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

ਰੰਗ ’ਤੇ ਨਹੀਂ, ਫ਼ਰਕ ’ਤੇ ਚੇਤਾਵਨੀ ਦਿਓ

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

ਕੱਲ੍ਹ ਦੇ ਸਫਲ ਨਮੂਨਿਆਂ ਨਾਲ ਭਰਿਆ ਡੈਸ਼ਬੋਰਡ ਅੱਜ ਸਿਹਤਮੰਦ ਮਾਰਗ ਵਜੋਂ ਨਹੀਂ ਪੜ੍ਹਿਆ ਜਾਣਾ ਚਾਹੀਦਾ।

ਲਿਖਤ ਵਿੱਚ ਸਮਝੌਤਾ ਛੋਟਾ ਹੈ: ਟਨਲ ਮੈਟ੍ਰਿਕ ਦੱਸਦਾ ਹੈ ਕਿ ਗੇਟਵੇ ਨੇ ਗੱਲਬਾਤ ਕੀਤੀ, ਪ੍ਰੋਬ ਦੱਸਦਾ ਹੈ ਕਿ ਮਾਰਗ ਉੱਥੋਂ ਕੰਮ ਕਰਦਾ ਹੈ ਜਿੱਥੇ ਵਰਤੋਂਕਾਰ ਬੈਠਦੇ ਹਨ, ਅਤੇ ਪਾਈਪਲਾਈਨ ਸਿਹਤ ਦੱਸਦੀ ਹੈ ਕਿ ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਜਵਾਬ ਮੌਜੂਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਡੈਸ਼ਬੋਰਡ ’ਤੇ ਬਾਕੀ ਸਭ ਟਿੱਪਣੀ ਹੈ।