SoftEther VPN Azure: ਰੀਲੇ ਮਾਰਗ, ਖੁੱਲ੍ਹਾ ਪੋਰਟ ਨਹੀਂ

ਤੁਹਾਡਾ ਸਰਵਰ ਅਜਿਹੇ ਰਾਊਟਰ ਪਿੱਛੇ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਕੌਨਫਿਗਰ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਇਸ ਲਈ ਪੋਰਟ ਫਾਰਵਰਡ ਕਰਨ ਦੀ ਸਪਸ਼ਟ ਯੋਜਨਾ ਉਪਲਬਧ ਨਹੀਂ ਹੈ। VPN Azure ਠੀਕ ਉਸੇ ਹਾਲਤ ਲਈ ਹੈ, ਅਤੇ ਪਹਿਲੇ ਕਨੈਕਸ਼ਨ ਦੀ ਦਿਸ਼ਾ ਪਲਟ ਕੇ ਇਸਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ: ਸਰਵਰ ਬਾਹਰ ਇੱਕ ਰੀਲੇ ਨਾਲ ਜੁੜਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਸਰਵਰ ਦੀ ਥਾਂ ਰੀਲੇ ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ। ਉਸ ਪਲਟਾਅ ਨੂੰ ਸਮਝਣਾ ਦੱਸਦਾ ਹੈ ਕਿ ਸੇਵਾ ਕੀ ਠੀਕ ਕਰਦੀ ਹੈ ਅਤੇ ਅੱਗੇ ਤੁਹਾਨੂੰ ਕਿਹੜੀਆਂ ਹੱਦਾਂ ਮਿਲਣਗੀਆਂ।

ਮਾਰਗ ਵਿੱਚ ਕੀ ਬਦਲਦਾ ਹੈ

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

ਰੀਲੇ ਉਸ ਸਰਵਰ ਨੂੰ ਆਪਣੇ ਡੋਮੇਨ ਉੱਤੇ ਨਾਮ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਉੱਥੇ ਜੁੜਨ ਲਈ ਕੌਨਫਿਗਰ ਹੁੰਦੇ ਹਨ।

ਉਹ ਨਾਮ ਰੀਲੇ ਸੇਵਾ ਦਾ ਹੈ, ਜੋ Microsoft Azure VPN Gateway ਨਹੀਂ ਹੈ, ਭਾਵੇਂ ਦੋਵਾਂ ਨੂੰ Azure ਕੁਝ ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਉਨ੍ਹਾਂ ਨੂੰ ਬਦਲਵੇਂ ਮੰਨਣ ਨਾਲ ਅਜਿਹੀ ਕੌਨਫਿਗਰੇਸ਼ਨ ਬਣਦੀ ਹੈ ਜੋ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦੀ।

ਕਿਹੜੇ ਪ੍ਰੋਟੋਕੋਲ ਰੀਲੇ ਪਾਰ ਕਰਦੇ ਹਨ

ਰੀਲੇ SoftEther ਪ੍ਰੋਟੋਕੋਲ ਲੈ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਪ੍ਰੋਜੈਕਟ SSTP ਨੂੰ ਕਲਾਇੰਟ ਵਿਕਲਪ ਵਜੋਂ ਦਰਜ ਕਰਦਾ ਹੈ, ਜੋ ਲਾਹੇਵੰਦ ਹੈ ਕਿਉਂਕਿ Windows ਨਾਲ SSTP ਕਲਾਇੰਟ ਆਉਂਦਾ ਹੈ। ਪਰ ਇਹ ਹੋਸਟ ਉੱਤੇ ਹਰ ਲਿਸਨਰ ਲਈ ਆਮ ਵਾਹਕ ਨਹੀਂ ਬਣਦਾ: OpenVPN ਲਿਸਨਰ, IPsec ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਅਤੇ L2TP ਸੇਵਾ ਨੂੰ ਆਪੋ-ਆਪਣਾ ਪਹੁੰਚਯੋਗ ਅੰਤ ਬਿੰਦੂ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਸਿਰਫ਼ SoftEther ਸਰਵਰ ਜੁੜਿਆ ਹੋਣ ਕਰਕੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਰੀਲੇ ਰਾਹੀਂ ਨਹੀਂ ਜਾਂਦਾ।

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

ਰੀਲੇ ਤੁਹਾਡੇ ਲਈ ਕੀ ਨਹੀਂ ਕਰਦਾ

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

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

ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਵਰਤੋਂਕਾਰ ਪ੍ਰਮਾਣੀਕਰਨ ਸਰਵਰ ਦੀ ਹੀ ਜ਼ਿੰਮੇਵਾਰੀ ਰਹਿੰਦੀ ਹੈ, ਅਤੇ ਰੀਲੇ ਕਦੇ ਵੀ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦਾ।

ਇਸਨੂੰ ਨਿਰਭਰਤਾ ਵਜੋਂ ਚਲਾਓ

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

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

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