ਕੀ ਤੁਹਾਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ Pritunl ਸਰਵਰ ਦਾ ਨਾਮ ਬਦਲਣ ਨਾਲ ਇਸਦਾ ਐਂਡਪੌਇੰਟ ਬਦਲ ਜਾਂਦਾ ਹੈ?

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

ਜਿਸ ਨਾਮ ਨਾਲ ਕਲਾਇੰਟ ਜੁੜਦੇ ਹਨ ਉਹ ਹੋਸਟ ਦੇ ਇੱਕ ਹੀ ਫੀਲਡ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ

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

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

ਤਿੰਨ ਫੀਲਡਾਂ ਜੋ ਇੱਕੋ ਜਿਹੀਆਂ ਦਿਸਦੀਆਂ ਹਨ ਅਤੇ ਹਨ ਨਹੀਂ

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

DNS ਨਾਮ ਵੀ ਕੋਈ ਪੋਰਟ ਮੈਪਿੰਗ ਜਾਂ ਸੁਣਨ ਵਾਲਾ ਨਹੀਂ ਲੈ ਕੇ ਚੱਲਦਾ। ਜੇ ਸੇਵਾ 1194 UDP 'ਤੇ ਸੁਣਦੀ ਹੈ, ਨਾਮ ਫਿਰ ਵੀ ਉਸ ਹੋਸਟ ਵੱਲ ਹੱਲ ਹੁੰਦਾ ਹੈ ਜਿਸਨੂੰ 1194 UDP ਸਵੀਕਾਰ ਕਰਨਾ ਪਵੇਗਾ। ਪੋਰਟ 443 'ਤੇ HTTP ਰਿਵਰਸ ਪ੍ਰੌਕਸੀ ਜੋ ਵੈੱਬ ਕੰਸੋਲ ਦਿੰਦੀ ਹੈ ਉਹ VPN ਟ੍ਰਾਂਸਪੋਰਟ ਦਾ ਐਂਡਪੌਇੰਟ ਨਹੀਂ ਹੈ, ਭਾਵੇਂ ਦੋਵੇਂ ਇੱਕੋ ਨਾਮ ਸਾਂਝਾ ਕਰਦੇ ਹੋਣ।

ਟਨਲ ਦੇ ਅੰਦਰ ਡੋਮੇਨ-ਆਧਾਰਿਤ ਰੂਟਿੰਗ ਇੱਕ ਹੋਰ ਵੱਖਰੀ ਪਰਤ ਹੈ। ਬਾਹਰੀ ਐਂਡਪੌਇੰਟ ਦਾ ਨਾਮ ਦੇਣਾ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ ਕਿ ਕਲਾਇੰਟ ਕਿਹੜੀਆਂ ਨਿੱਜੀ ਮੰਜ਼ਿਲਾਂ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ।

ਨਵਾਂ ਨਾਮ ਮੌਜੂਦ ਕਲਾਇੰਟਾਂ ਨੂੰ ਭੇਜੋ

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

ਜਦੋਂ ਵੈੱਬ ਕੰਸੋਲ ਲੋਡ ਬੈਲੰਸਰ ਪਿੱਛੇ ਹੁੰਦਾ ਹੈ, Pritunl ਸਿੰਕ ਮਾਰਗ ਲਈ ਵੱਖਰੀ ਸਿੰਕ ਪਤਾ ਸੈਟਿੰਗ ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਰਦਾ ਹੈ। ਸਿਰਫ਼ ਇਸ ਲਈ ਕਿ ਦੋਵੇਂ Pritunl ਹਨ, VPN ਸੁਣਨ ਵਾਲੇ ਲਈ ਕੰਸੋਲ ਦਾ ਹੋਸਟਨਾਮ ਦੁਬਾਰਾ ਨਾ ਵਰਤੋ।

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

ਅਸਲ ਕਨੈਕਸ਼ਨ ਨਾਲ ਬਦਲਾਅ ਨੂੰ ਸਵੀਕਾਰ ਕਰੋ

ਰੈਜ਼ੋਲਿਊਸ਼ਨ ਸਭ ਤੋਂ ਕਮਜ਼ੋਰ ਸੰਭਵ ਟੈਸਟ ਹੈ। dig +short vpn.example.net ਪਤਾ ਵਾਪਸ ਦਿੰਦਾ ਹੈ ਤਾਂ ਇਹ ਸਿਰਫ਼ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਰਿਕਾਰਡ ਮੌਜੂਦ ਹੈ।

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

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