Azure P2S VPN ਦਾ ਵਾਪਸੀ ਟ੍ਰੈਫਿਕ ਸਿਰਫ਼ ਇੱਕ ਦਿਸ਼ਾ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ

ਟਨਲ ਆਈਕਨ ਹਰਾ ਹੈ, NSG ਆਗਿਆ ਦਿੰਦਾ ਦਿਸਦਾ ਹੈ, ਪ੍ਰਭਾਵੀ ਰੂਟ ਸਹੀ ਦਿਸਦੇ ਹਨ, ਫਿਰ ਵੀ VM ਜੁੜੇ ਕਲਾਇੰਟ ਵੱਲ ਵਾਪਸ ਕਨੈਕਸ਼ਨ ਨਹੀਂ ਖੋਲ੍ਹ ਸਕਦਾ। ਆਮ ਧਾਰਨਾ ਇਹ ਹੈ ਕਿ ਕੰਮ ਕਰਦਾ point-to-site ਟਨਲ ਸਮਮਿਤ ਹੁੰਦਾ ਹੈ: ਜੇ ਕਲਾਇੰਟ VM ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਤਾਂ VM ਵੀ ਕਲਾਇੰਟ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ। ਇਹੀ ਧਾਰਨਾ ਤਰਕ ਦੀ ਗਲਤੀ ਹੈ, ਸੰਰਚਨਾ ਦੀ ਨਹੀਂ। ਟਨਲ ਬਿਨਾਂ ਮੰਗੇ ਪ੍ਰਵਾਹ ਦੀ ਇੱਕ ਦਿਸ਼ਾ ਲੈ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਦੂਜੀ ਛੱਡ ਸਕਦਾ ਹੈ, ਅਤੇ ਸੁਧਾਰ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜੀ ਪਰਤ ਇਸਨੂੰ ਛੱਡ ਰਹੀ ਹੈ।

ਭਰਮ: ਜੁੜਿਆ ਟਨਲ ਦੋ-ਦਿਸ਼ਾਵੀ ਟਨਲ ਹੁੰਦਾ ਹੈ

VPN ਟਨਲ ਨੀਤੀ-ਮਾਰਗ ਹੈ, ਤਾਰ ਨਹੀਂ। ਹਰ ਦਿਸ਼ਾ ਨੂੰ ਚੋਣਕਰਤਾ, ਰੂਟ ਅਤੇ ਫਿਲਟਰ ਨਾਲ ਮਿਲਾਇਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਇੱਕ ਦਿਸ਼ਾ ਨੂੰ ਆਗਿਆ ਦੇ ਕੇ ਦੂਜੀ ਨੂੰ ਰੋਕ ਸਕਦਾ ਹੈ।

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

ਪਹੁੰਚ-ਯੋਗਤਾ ਜਾਂਚਣ ਤੋਂ ਪਹਿਲਾਂ ਦਿਸ਼ਾ ਜਾਂਚੋ

ਇੱਕ ਕਲਾਇੰਟ ਪਤਾ, ਇੱਕ VM ਪਤਾ ਅਤੇ ਇੱਕ ਪ੍ਰੋਟੋਕੋਲ ਚੁਣੋ। ਕਲਾਇੰਟ ਤੋਂ ਜੁੜੋ ਅਤੇ ਨਤੀਜਾ ਦਰਜ ਕਰੋ; ਫਿਰ ਉਹੀ ਜਾਂਚ VM ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਉਹ ਵੀ ਦਰਜ ਕਰੋ। ਜੇ ਪਹਿਲੀ ਸਫਲ ਅਤੇ ਦੂਜੀ ਅਸਫਲ ਹੋਵੇ, ਤਾਂ ਕਲਾਇੰਟ ਪੂਲ, ਗੇਟਵੇ ਸੰਬੰਧ ਅਤੇ ਕਲਾਇੰਟ ਤੋਂ VNet ਤੱਕ ਦਾ ਮਾਰਗ ਸਭ ਕੰਮ ਕਰ ਰਹੇ ਹਨ।

ਅਗਲਾ ਕਦਮ ਸਬੂਤ ਹੈ, ਹੋਰ ਨਿਯਮ ਨਹੀਂ। VM ਸਬਨੈੱਟ 'ਤੇ NSG ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਜਾਂਚੋ, VM ਦੇ NIC 'ਤੇ ਪ੍ਰਭਾਵੀ ਰੂਟ ਪੜ੍ਹੋ, ਅਤੇ ਕਲਾਇੰਟ ਵੱਲੋਂ ਟ੍ਰੈਫਿਕ ਭੇਜਦੇ ਸਮੇਂ VM 'ਤੇ ਪੈਕੇਟ ਫੜੋ। ਬਿਨਾਂ ਜਵਾਬ ਆਉਣ ਵਾਲੀ ਬੇਨਤੀ ਫਿਲਟਰ ਜਾਂ ਵਾਪਸੀ-ਮਾਰਗ ਦੀ ਸਮੱਸਿਆ ਹੈ; ਕਦੇ ਨਾ ਆਉਣ ਵਾਲੀ ਬੇਨਤੀ ਮਾਰਗ ਦੀ ਸਮੱਸਿਆ ਹੈ। ਅਸਫਲ ping ਨੂੰ VM ਦੀ ਅਪਹੁੰਚ ਦਾ ਸਬੂਤ ਨਾ ਮੰਨੋ, ਕਿਉਂਕਿ TCP ਦੇ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਵੀ ICMP ਨੀਤੀ ਜਵਾਬ ਛੱਡ ਸਕਦੀ ਹੈ।

IKEv2 point-to-site ਵਾਪਸੀ ਮਾਰਗ ਹੀ ਆਮ ਸ਼ੱਕੀ ਹੈ

ਇਸ ਲੇਖ ਪਿੱਛੇ ਦੀ Azure ਰਿਪੋਰਟ ਵਿੱਚ, ਇੱਕ ਕਲਾਇੰਟ IKEv2 ਰਾਹੀਂ VM ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਸੀ, ਪਰ VM ਤੋਂ ਕਲਾਇੰਟ ਵੱਲ ਆਉਣ ਵਾਲਾ ICMP ਉਦੋਂ ਤੱਕ ਅਸਫਲ ਰਿਹਾ ਜਦੋਂ ਤੱਕ ਗੇਟਵੇ ਦੀ ਟਨਲ ਕਿਸਮ OpenVPN 'ਤੇ ਨਹੀਂ ਬਦਲੀ ਗਈ। ਰਿਪੋਰਟਰ ਦੱਸਦਾ ਹੈ ਕਿ Microsoft ਨੇ IKEv2 point-to-site ਮਾਰਗ ਵਿੱਚ ਸੀਮਾ ਦੀ ਪੁਸ਼ਟੀ ਕੀਤੀ, ਜਿੱਥੇ VM ਤੋਂ ਕਲਾਇੰਟ ਵੱਲ ਵਾਪਸੀ ਟ੍ਰੈਫਿਕ ਸਮਮਿਤ ਤੌਰ 'ਤੇ ਰੂਟ ਨਹੀਂ ਹੁੰਦਾ ਜਦੋਂ ਤੱਕ ਕਲਾਇੰਟ ਨੇ ਸੈਸ਼ਨ ਸ਼ੁਰੂ ਨਾ ਕੀਤਾ ਹੋਵੇ। IKEv2 ਟ੍ਰੈਫਿਕ ਚੋਣਕਰਤਾਵਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਗੇਟਵੇ ਨੇ ਉਸ ਮਾਮਲੇ ਵਿੱਚ ਵਾਪਸੀ ਦਿਸ਼ਾ ਦਾ ਸਤਿਕਾਰ ਨਹੀਂ ਕੀਤਾ।

ਇਸ ਨਾਲ OpenVPN ਆਮ ਤੌਰ 'ਤੇ ਵਧੀਆ ਟਨਲ ਕਿਸਮ ਨਹੀਂ ਬਣਦਾ। ਇਸ ਨਾਲ ਇਸ ਕੰਮ-ਭਾਰ ਲਈ ਜਾਂਚ ਮੈਟ੍ਰਿਕਸ ਵਿੱਚ ਟਨਲ ਕਿਸਮ ਇੱਕ ਚਲ ਬਣ ਜਾਂਦੀ ਹੈ।

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

ਭਰਮ: ਬ੍ਰਾਡਕਾਸਟ ਖੋਜ VNet ਦੀ ਸੀਮਾ ਪਾਰ ਕਰਦੀ ਹੈ

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

ਬ੍ਰਾਡਕਾਸਟ ਖੋਜ ਨੂੰ DNS ਨਾਮ, ਡਾਇਰੈਕਟਰੀ ਸੇਵਾ ਜਾਂ ਸਪਸ਼ਟ ਸਾਥੀ-ਸੂਚੀ ਨਾਲ ਬਦਲੋ। ਜੇ ਐਪਲੀਕੇਸ਼ਨ ਕੋਲ unicast ਬਦਲ ਨਹੀਂ ਹੈ, ਤਾਂ ਡਿਜ਼ਾਈਨ ਨੂੰ ਚੌੜਾ ਟਨਲ ਨਹੀਂ, ਵੱਖਰੀ ਖੋਜ ਕਾਰਵਿਧੀ ਚਾਹੀਦੀ ਹੈ।

ਕੀ ਬਦਲਣਾ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਕਿਵੇਂ ਸਾਬਤ ਕਰਨਾ ਹੈ

ਜੇ ਦਿਸ਼ਾ-ਜਾਂਚ ਸਿਰਫ਼ IKEv2 'ਤੇ ਅਸਫਲ ਹੋਵੇ, ਤਾਂ ਗੇਟਵੇ ਦੀ ਟਨਲ ਕਿਸਮ, ਕਲਾਇੰਟ ਪਤਾ ਪੂਲ ਅਤੇ ਸਹੀ ICMP ਜਾਂ TCP ਜਾਂਚ ਦਰਜ ਕਰੋ, ਫਿਰ ਪ੍ਰਭਾਵਿਤ ਕਲਾਇੰਟਾਂ ਲਈ ਮਨਜ਼ੂਰ OpenVPN ਪ੍ਰੋਫਾਈਲ ਦਾ ਮੁਲਾਂਕਣ ਕਰੋ। ਜੇ ਇਹ ਹਰ ਟਨਲ ਕਿਸਮ 'ਤੇ ਅਸਫਲ ਹੋਵੇ, ਤਾਂ ਵਾਪਸੀ ਮਾਰਗ 'ਤੇ ਕੰਮ ਕਰੋ: ਕਲਾਇੰਟ ਪਤਾ VM ਸਬਨੈੱਟ ਤੋਂ ਰੂਟ ਕਰਨ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਵਰਤੋਂਕਾਰ-ਪਰਿਭਾਸ਼ਿਤ ਕੋਈ ਵੀ ਰੂਟ ਯੋਗ ਅਗਲੇ ਹੌਪ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਫਾਇਰਵਾਲ ਨੂੰ ਆਉਣ ਵਾਲਾ ਪ੍ਰਵਾਹ ਸਵੀਕਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। NSG ਅਤੇ ਰੂਟ ਦੇ ਸਬੂਤ ਟਿਕਟ ਨਾਲ ਜੋੜੋ।

ping ਨਾਲ ਨਹੀਂ, ਐਪਲੀਕੇਸ਼ਨ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ। ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਸਫਲ ICMP ਅਦਲਾ-ਬਦਲੀ ਸੇਵਾ ਪੋਰਟ, ਇਸਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਜਾਂ ਨਾਮ-ਹੱਲ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦੀ। ਦੁਬਾਰਾ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਜਾਂਚ ਦੁਹਰਾਓ, ਕਿਉਂਕਿ ਪੂਲ ਤੋਂ ਵੱਖਰਾ ਪਤਾ ਮਿਲਣ ਵਾਲਾ ਕਲਾਇੰਟ ਨਤੀਜਾ ਬਦਲ ਸਕਦਾ ਹੈ। ਫਿਰ ਕਲਾਇੰਟ ਦੇ ਸੌਣ ਅਤੇ ਜਾਗਣ ਤੋਂ ਬਾਅਦ ਇੱਕ ਵਾਰ ਹੋਰ ਦੁਹਰਾਓ, ਕਿਉਂਕਿ ਮੁੜ ਸ਼ੁਰੂ ਹੋਈ ਸੈਸ਼ਨ ਵਿੱਚ ਹੀ ਇੱਕ-ਦਿਸ਼ਾਵੀ ਵਿਵਹਾਰ ਅਕਸਰ ਮੁੜ ਦਿਸਦਾ ਹੈ।