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

ਪਤਾ ਇੱਕ ਅਲਾਟਮੈਂਟ ਹੈ, ਫਾਰਵਰਡਿੰਗ ਨਿਯਮ ਨਹੀਂ

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

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

What you haveWhat it gives youWhat it does not
Dedicated exit addressA stable source address for outbound trafficAny inbound delivery at all
Port-forwarding add-onA provider-side mapping to your sessionPermanence across reconnects
Local DNAT ruleHandling for packets that arriveMaking packets arrive

ਇੱਕ ਉਦਾਹਰਨ ਸਮਝੌਤਾ ਇਸ ਤਰ੍ਹਾਂ ਦਿਸਦਾ ਹੈ: ਪ੍ਰਦਾਤਾ TCP 203.0.113.60:45000 ਤੁਹਾਡੇ ਜੁੜੇ ਡਿਵਾਈਸ ਦੀ HTTPS ਸੇਵਾ ਤੱਕ 8443 ਪੋਰਟ 'ਤੇ ਪਹੁੰਚਾਉਂਦਾ ਹੈ। ਇਹ ਕਿਸੇ ਹੋਰ ਵੱਲੋਂ ਸੰਰਚਿਤ ਮੈਪਿੰਗ ਦਾ ਵਰਣਨ ਹੈ, ਅਜਿਹਾ ਨਿਯਮ ਨਹੀਂ ਜੋ ਤੁਸੀਂ ਆਪਣੇ ਫਾਇਰਵਾਲ ਵਿੱਚ ਲਿਖ ਕੇ ਉਨ੍ਹਾਂ ਦੇ ਐਜ 'ਤੇ ਬਣਾ ਸਕਦੇ ਹੋ।

ਮੂਲ ਪਾਸਾ ਪੂਰਾ ਕਰੋ

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

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

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

ਉੱਚਾ ਪੋਰਟ ਇਮਾਨਦਾਰੀ ਨਾਲ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ

ਜੇ ਵਿਜ਼ਟਰ ਸਿੱਧਾ ਜੁੜਦੇ ਹਨ ਅਤੇ ਪ੍ਰਦਾਤਾ ਨੇ ਉੱਚਾ ਪੋਰਟ ਨਿਰਧਾਰਿਤ ਕੀਤਾ ਹੈ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਪੂਰਾ URL ਦਿਓ। ਇੱਕ ਆਮ DNS ਪਤਾ ਰਿਕਾਰਡ HTTPS ਬੇਨਤੀ ਵਿੱਚ ਪੋਰਟ ਨਹੀਂ ਜੋੜ ਸਕਦਾ, ਜੋ ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ 443 ਵਰਤਦੀ ਹੈ, ਅਤੇ TTL ਬਦਲਣ ਨਾਲ ਇਹ ਨਹੀਂ ਬਦਲਦਾ।

ਇੱਕ ਵੈੱਬ ਫਰੰਟਐਂਡ ਇਸਨੂੰ ਵਿਜ਼ਟਰਾਂ ਨੂੰ ਆਮ ਪੋਰਟ 'ਤੇ ਸਵੀਕਾਰ ਕਰਕੇ ਅਤੇ ਫਾਰਵਰਡ ਕੀਤੇ ਮੂਲ ਪੋਰਟ ਨਾਲ ਆਪਣਾ ਕਨੈਕਸ਼ਨ ਬਣਾ ਕੇ ਹੱਲ ਕਰ ਸਕਦਾ ਹੈ। ਹਾਲਾਂਕਿ Cloudflare ਦੇ ਡਿਫੌਲਟ ਪ੍ਰੌਕਸੀ ਪੋਰਟ ਇੱਕ ਨਿਰਧਾਰਿਤ ਸੂਚੀ ਹਨ, ਅਤੇ ਮਨਮਾਨੇ ਢੰਗ ਨਾਲ ਨਿਰਧਾਰਿਤ ਪੋਰਟ ਸਿਰਫ਼ ਪ੍ਰੌਕਸੀ ਕੀਤਾ DNS ਰਿਕਾਰਡ ਜੋੜਨ ਨਾਲ ਸਮਰਥਿਤ ਐਜ ਪੋਰਟ ਨਹੀਂ ਬਣ ਜਾਂਦਾ।

ਮੂਲ ਦੀ ਮੰਜ਼ਿਲ ਪੋਰਟ ਬਦਲਣਾ ਵਿਜ਼ਟਰ ਪੋਰਟ ਬਦਲਣ ਤੋਂ ਵੱਖਰੀ ਕਿਰਿਆ ਹੈ। Cloudflare ਦੇ Origin Rules ਬੈਕਐਂਡ ਕਨੈਕਸ਼ਨ ਲਈ ਮੰਜ਼ਿਲ-ਪੋਰਟ ਓਵਰਰਾਈਡ ਦਾ ਦਸਤਾਵੇਜ਼ ਕਰਦੇ ਹਨ, ਜੋ ਸਮਰਥਿਤ ਨਿਯਮ, ਸਕੀਮ ਅਤੇ ਹੋਸਟਨਾਮ ਤੱਕ ਸੀਮਿਤ ਹੈ। ਪੋਰਟ ਓਵਰਰਾਈਡ ਮਨਮਾਨੇ UDP ਜਾਂ ਹੋਰ ਪ੍ਰੋਟੋਕੋਲ ਲਈ ਆਮ ਰਿਲੇ ਨਹੀਂ ਹੈ।

ਜਦੋਂ ਫਰੰਟਐਂਡ TLS ਖਤਮ ਕਰਦਾ ਹੈ, ਤਾਂ ਦੋਵੇਂ ਪੜਾਅ ਪ੍ਰਮਾਣਿਤ ਕਰੋ: ਬ੍ਰਾਊਜ਼ਰ ਤੋਂ ਫਰੰਟਐਂਡ ਤੱਕ ਸਰਟੀਫਿਕੇਟ ਅਤੇ ਫਰੰਟਐਂਡ ਤੋਂ ਮੂਲ ਤੱਕ ਕਨੈਕਸ਼ਨ। VPN ਪੜਾਅ ਦੋਵੇਂ ਜਾਂਚਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦਾ, ਅਤੇ ਅੰਦਰੂਨੀ ਪਤੇ ਦਾ ਰੀਡਾਇਰੈਕਟ ਜਾਂ ਕੂਕੀਜ਼ ਵਿੱਚ ਲੀਕ ਹੋਣਾ ਇਸ ਗੱਲ ਦਾ ਆਮ ਸੰਕੇਤ ਹੈ ਕਿ ਦੋਵਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਜਨਤਕ ਨਾਮ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖ ਕੇ ਸੰਰਚਿਤ ਕੀਤਾ ਗਿਆ ਸੀ।

ਮੈਪਿੰਗ ਨੂੰ ਜੀਵਤ ਰੱਖੋ

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

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

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

ਸੰਬੰਧਿਤ ਲੇਖ