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

ਸਾਕਟ, ਬਾਈਂਡ ਸੈਟਿੰਗ, ਫਾਇਰਵਾਲ ਨਿਯਮ ਅਤੇ URL — ਇਸੇ ਕ੍ਰਮ ਵਿੱਚ ਕੰਮ ਕਰੋ।

ਸਾਕਟ ਇੱਕ ਹੋਰ ਸੰਕਰਾ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ

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

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

IPv6 ਤੀਜਾ ਕੇਸ ਜੋੜਦਾ ਹੈ, ਕਿਉਂਕਿ ਸਾਕਟ ਵਿਕਲਪਾਂ ਦੇ ਆਧਾਰ ਉੱਤੇ IPv4 ਅਤੇ IPv6 ਸਵੀਕਾਰ ਕਰ ਸਕਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਨੂੰ ਖ਼ਿਆਲ ਵਿੱਚ ਰੱਖਣਾ ਔਖਾ ਹੁੰਦਾ ਹੈ। ਸੂਚੀ ਵਿੱਚ ਪਤਾ ਪਰਿਵਾਰ ਪੜ੍ਹੋ। ਇੱਕ ਪਰਿਵਾਰ ਲਈ ਵਾਈਲਡਕਾਰਡ ਐਂਟਰੀ ਦੂਜੇ ਦਾ ਵਰਣਨ ਨਹੀਂ ਕਰਦੀ।

ਸੁਣਨ ਵਾਲਾ ਪਤਾ ਪੜ੍ਹੋ

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

Get-NetTCPConnection -State Listen -LocalPort 8080 | Select-Object LocalAddress,LocalPort,OwningProcess
Get-Process -Id (Get-NetTCPConnection -State Listen -LocalPort 8080).OwningProcess
ipconfig | Select-String -Pattern 'IPv4'
Get-NetFirewallRule -DisplayName '*8080*' | Format-Table DisplayName,Enabled,Profile,Direction,Action

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

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

ਬਾਈਂਡ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਰਾਹੀਂ ਬਦਲੋ

ਫ਼ਰੇਮਵਰਕ ਦੇ ਦਸਤਾਵੇਜ਼ੀ ਲਿਸਨ-ਪਤਾ ਵਿਕਲਪ ਦੀ ਵਰਤੋਂ ਕਰੋ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰੋ। ਜੇ ਲੈਪਟਾਪ ਕੋਲ ਨਿੱਜੀ ਪਤਾ 10.77.0.1 ਹੈ, ਤਾਂ ਫੋਨ ਦਾ URL http://10.77.0.1:8080/ ਬਣ ਜਾਂਦਾ ਹੈ ਅਤੇ ਉਹ ਪਤਾ VPN ਰਾਹੀਂ ਰੂਟ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ; ਸੈਟਅਪ ਦੀ ਹੋਰ ਕੋਈ ਚੀਜ਼ ਨਹੀਂ ਬਦਲਦੀ।

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

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

ਇੱਕ ਨਿਯਮ ਖੋਲ੍ਹੋ, ਪੂਰਾ ਨੈੱਟਵਰਕ ਨਹੀਂ

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

ਉਹ ਸਰੋਤ ਪਤਾ ਵਰਤੋ ਜੋ Windows ਅਸਲ ਵਿੱਚ ਵੇਖਦਾ ਹੈ, ਗੇਟਵੇ ਵੱਲੋਂ ਕੀਤੇ ਕਿਸੇ ਵੀ ਅਨੁਵਾਦ ਸਮੇਤ, ਕਿਉਂਕਿ ਮੂਲ ਕਲਾਇੰਟ ਪਤੇ ਲਈ ਲਿਖਿਆ ਨਿਯਮ ਅਨੁਵਾਦਿਤ ਪਤੇ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਏਗਾ।

ਲੋਡ ਹੋ ਕੇ ਐਪਲੀਕੇਸ਼ਨ ਗਲਤੀ ਦਿਖਾਉਣ ਵਾਲਾ ਪੰਨਾ ਤਰੱਕੀ ਹੈ: HTTP ਰੱਦ ਹੋਣਾ TCP ਕਨੈਕਸ਼ਨ ਨਾ ਹੋਣ ਨਾਲੋਂ ਵੱਖਰੀ ਅਸਫ਼ਲਤਾ ਹੈ, ਅਤੇ ਅਗਲੀ ਜਾਂਚ ਨੈੱਟਵਰਕ ਦੀ ਨਹੀਂ, ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਆਪਣੀ ਪਹੁੰਚ ਨੀਤੀ ਦੀ ਹੈ।

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

ਸੰਬੰਧਿਤ ਲੇਖ