NAT ਪਿੱਛੇ SoftEther: ਸਿੱਧਾ ਟ੍ਰਾਵਰਸਲ ਜਾਂ VPN Azure ਰਿਲੇ?

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

ਤਿੰਨ ਕਾਰਜਵਿਧੀਆਂ, ਤਿੰਨ ਵੱਖਰੇ ਵਾਅਦੇ

ਡਾਇਨਾਮਿਕ DNS ਨਾਮਕਰਨ ਹੈ। ਇਹ ਹੋਸਟਨਾਮ ਨੂੰ ਬਦਲਦੇ ਪਤੇ ਵੱਲ ਰੱਖਦਾ ਹੈ ਤਾਂ ਜੋ ਲੋਕ ਨੰਬਰ ਦੇ ਪਿੱਛੇ ਭੱਜਣਾ ਛੱਡ ਦੇਣ, ਅਤੇ ਇਸ ਤੋਂ ਇਲਾਵਾ ਕੁਝ ਨਹੀਂ ਕਰਦਾ। ਮੂਲ NAT ਟ੍ਰਾਵਰਸਲ ਤਾਲਮੇਲ ਹੈ: ਦੋ SoftEther ਸਿਰੇ ਜਾਣਕਾਰੀ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ ਅਤੇ ਆਪਣੇ ਵਿਚਕਾਰਲੇ ਅਨੁਵਾਦ ਯੰਤਰਾਂ ਰਾਹੀਂ ਵਰਤੋਂਯੋਗ UDP ਮਾਰਗ ਖੋਲ੍ਹਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ। VPN Azure ਇੱਕ ਰਿਲੇ ਹੈ: ਸਰਵਰ ਸੇਵਾ ਵੱਲ ਬਾਹਰ ਡਾਇਲ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਰਿਲੇ ਦੇ ਢਾਂਚੇ 'ਤੇ ਹੋਸਟਨਾਮ ਰਾਹੀਂ ਆਉਂਦੇ ਹਨ।

ਤਿੰਨੇ ਇੱਕ-ਦੂਜੇ ਦੇ ਪੂਰਕ ਹਨ, ਇੱਕੋ ਸੁਵਿਧਾ ਦੇ ਸੰਸਕਰਣ ਨਹੀਂ। ਤੈਨਾਤੀ ਨਾਮਕਰਨ ਵਰਤ ਸਕਦੀ ਹੈ ਜਦੋਂ ਕਿ ਇਸਦਾ ਕਨੈਕਸ਼ਨ ਅਸਲ ਵਿੱਚ ਟ੍ਰਾਵਰਸਲ ਜਾਂ ਰਿਲੇ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।

ਕਲਾਇੰਟ ਅਤੇ ਨੈੱਟਵਰਕ ਤੋਂ ਤੈਅ ਕਰੋ

ਚੋਣ ਕਲਾਇੰਟ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਟ੍ਰਾਵਰਸਲ ਸਿਰਫ਼ ਮੂਲ SoftEther ਕਨੈਕਸ਼ਨ ਕਾਰਜਵਿਧੀ ਵਿੱਚ ਹੁੰਦਾ ਹੈ। ਇੱਕੋ ਸਰਵਰ 'ਤੇ OpenVPN, L2TP/IPsec ਅਤੇ SSTP ਸਰੋਤੇ ਇਸਨੂੰ ਵਿਰਾਸਤ ਵਿੱਚ ਨਹੀਂ ਲੈਂਦੇ, ਭਾਵੇਂ ਉਹ ਇੱਕ ਹੋਸਟ ਸਾਂਝਾ ਕਰਦੇ ਹਨ। ਦੇਖੋ ਵਰਤੋਂਕਾਰ ਕੀ ਚਲਾਏਗਾ, ਫਿਰ ਨੈੱਟਵਰਕ ਕੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਜੋ ਕਾਰਪੋਰੇਟ ਨੈੱਟਵਰਕ ਸਿਰਫ਼ TCP 443 ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਉਹ ਤੁਹਾਨੂੰ ਉਸ ਪੋਰਟ ਦੇ ਰਿਲੇ ਵੱਲ ਧੱਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਟ੍ਰਾਵਰਸਲ ਲਈ ਲੋੜੀਂਦੇ UDP ਪੋਰਟ ਲੰਘਣ ਦੇਣ ਵਾਲਾ ਨੈੱਟਵਰਕ ਸਿੱਧਾ ਮਾਰਗ ਅਜ਼ਮਾ ਸਕਦਾ ਹੈ; ਦੋਵਾਂ ਨੂੰ ਅਸਲ ਐਗਰੈਸ ਨੀਤੀ ਦੇ ਸਾਮ੍ਹਣੇ ਜਾਂਚੋ।

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

ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸੈਸ਼ਨ ਨੇ ਕਿਹੜਾ ਟ੍ਰਾਂਸਪੋਰਟ ਚੁਣਿਆ

ਕਨੈਕਸ਼ਨ ਸਥਿਤੀ ਹੀ ਵਰਤੇ ਜਾ ਰਹੇ ਮਾਰਗ ਦਾ ਇੱਕੋ-ਇੱਕ ਇਮਾਨਦਾਰ ਸਰੋਤ ਹੈ। ਇਸਨੂੰ ਸਰਵਰ 'ਤੇ ਪੜ੍ਹੋ, ਅਤੇ ਕਲਾਇੰਟ ਨੂੰ ਮਿਲੇ ਹੋਸਟਨਾਮ ਨੂੰ ਹੱਲ ਕਰੋ।

vpncmd /SERVER localhost /HUB VPN /CMD:SessionList
vpncmd /SERVER localhost /HUB VPN /CMD:SessionGet <session-name>
nslookup alice.vpnazure.net

SessionList ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਸੈਸ਼ਨ ਜੁੜੇ ਹੋਏ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ 'ਤੇ SessionGet ਕਨੈਕਸ਼ਨ ਦੀ ਕਿਸਮ ਦੱਸਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਇਹ ਵੀ ਸ਼ਾਮਲ ਹੈ ਕਿ ਸੈਸ਼ਨ ਰਿਲੇ ਰਾਹੀਂ ਆਇਆ ਜਾਂ ਨਹੀਂ। ਰਿਲੇ ਦੇ ਢਾਂਚੇ 'ਤੇ ਹੱਲ ਹੋਣ ਵਾਲਾ ਰਿਕਾਰਡ ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਸੈਸ਼ਨ ਤੀਜੀ ਧਿਰ ਰਾਹੀਂ ਲੰਘਦਾ ਹੈ, ਜਿਸਨੂੰ ਤੁਸੀਂ ਟੈਸਟ ਵਿੱਚ ਉਹ ਮਾਰਗ ਰੋਕ ਕੇ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹੋ। ਮੂਲ ਕਲਾਇੰਟ ਨਾਲ, UDP ਤੇਜ਼ੀ ਡੇਟਾ ਮਾਰਗ ਨੂੰ ਕੰਟਰੋਲ ਮਾਰਗ ਤੋਂ ਦੂਰ ਲੈ ਜਾ ਸਕਦੀ ਹੈ, ਇਸ ਲਈ ਇੱਕ ਨਿਰੀਖਣ ਪੂਰੇ ਸੈਸ਼ਨ ਦਾ ਵਰਣਨ ਨਹੀਂ ਕਰਦਾ। ਪਤਾ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਪੁਰਾਣਾ ਡਾਇਨਾਮਿਕ DNS ਨਾਮ, ਅਤੇ ਬੈਕਐਂਡ ਮਾਰਗ ਗੈਰਹਾਜ਼ਰ ਹੋਣ 'ਤੇ ਵੀ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਰਿਲੇ, ਦੋ ਫੇਲ੍ਹ ਹੋਣ ਦੇ ਢੰਗ ਹਨ ਜਿਹਨਾਂ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਜਾਂਚਣਾ ਚਾਹੀਦਾ ਹੈ। ਡਿਜ਼ਾਈਨ ਨੇ ਜੋ ਚਾਹਿਆ ਉਹ ਨਹੀਂ, ਤੁਸੀਂ ਜੋ ਮਾਪਿਆ ਉਹ ਲਿਖੋ।

ਚੁਣਿਆ ਮਾਰਗ ਕਿਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਇਸਦੀ ਯੋਜਨਾ ਬਣਾਓ

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

ਹੋਸਟਨਾਮ, ਪ੍ਰੋਟੋਕੋਲ, ਸੁਵਿਧਾ ਸੈਟਿੰਗਾਂ ਅਤੇ ਨਿਰੀਖਿਤ ਟ੍ਰਾਂਸਪੋਰਟ ਲਿਖੋ। ਉਹੀ ਚਾਰ-ਭਾਗ ਰਿਕਾਰਡ ਅਗਲੇ ਵਿਅਕਤੀ ਨੂੰ ਕੰਮ ਕਰਨ ਵਾਲਾ ਕਨੈਕਸ਼ਨ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦਿੰਦਾ ਹੈ।