ਤੁਹਾਡੇ VPN ਟਨਲ ਪਤੇ ਇਨਬਾਉਂਡ ਪੋਰਟ ਕਿਉਂ ਨਹੀਂ ਖੋਲ੍ਹਦਾ
ਟਨਲ ਪਤਾ ਤੁਹਾਡੇ ਕਲਾਇੰਟ ਨੂੰ ਉਹਨਾਂ ਸਾਥੀਆਂ ਸਾਹਮਣੇ ਪਛਾਣਦਾ ਹੈ ਜੋ ਉੱਥੇ ਰੂਟ ਕਰ ਸਕਦੇ ਹਨ, ਅਤੇ ਕਦੇ ਵੀ ਸਰੋਤਾ ਨਹੀਂ ਬਣਾਉਂਦਾ। ਬਾਈਂਡ, ਵਾਪਸੀ ਮਾਰਗ ਅਤੇ ਫਿਰ ਨੀਤੀ ਜਾਂਚੋ।
ਦਫ਼ਤਰ ਦੇ VPN ਨਾਲ ਜੁੜੋ, ਪੋਰਟ 8443 'ਤੇ ਇੱਕ ਛੋਟੀ ਸੇਵਾ ਸ਼ੁਰੂ ਕਰੋ, ਟਨਲ ਪਤਾ ਸਹਿਕਰਮੀ ਨੂੰ ਭੇਜੋ ਅਤੇ ਦੇਖੋ ਕਿ ਕਨੈਕਸ਼ਨ ਅਸਫਲ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕਿ ਕਲਾਇੰਟ ਅਜੇ ਵੀ ਜੁੜਿਆ ਹੋਣ ਦੀ ਰਿਪੋਰਟ ਦਿੰਦਾ ਹੈ। ਟਨਲ ਵਿੱਚ ਕੁਝ ਵੀ ਟੁੱਟਿਆ ਨਹੀਂ ਹੈ: ਪਤਾ ਦਿੱਤਾ ਜਾ ਚੁੱਕਾ ਹੈ, ਸੈਸ਼ਨ ਸਰਗਰਮ ਹੈ, ਅਤੇ ਜਵਾਬ ਲੈ ਜਾਣ ਵਾਲੇ ਪੈਕਟ ਕਦੇ ਵੀ ਸਵੀਕਾਰ ਨਹੀਂ ਕੀਤੇ ਜਾਂਦੇ। ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਤਿੰਨ ਜਾਂਚਾਂ ਕ੍ਰਮ ਵਿੱਚ ਕਰੋ ਅਤੇ ਜੋ ਅਸਫਲ ਹੋਵੇ ਉਸੇ 'ਤੇ ਰੁਕੋ, ਕਿਉਂਕਿ ਹਰ ਇੱਕ ਦਾ ਹੱਲ ਵੱਖਰਾ ਹੈ ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਹੀ VPN ਨਾਲ ਸਬੰਧਤ ਹੈ।
ਸ਼ੁਰੂਆਤ ਇਸ ਗੱਲ ਤੋਂ ਕਰੋ ਕਿ ਸਾਕਟ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਬਾਈਂਡ ਹੈ
ਕੁਝ ਵੀ ਰੂਟ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ, ਕਿਸੇ ਚੀਜ਼ ਨੂੰ ਅਜਿਹੇ ਪਤੇ 'ਤੇ ਸੁਣਨਾ ਚਾਹੀਦਾ ਹੈ ਜਿੱਥੇ ਕਾਲਰ ਪਹੁੰਚ ਸਕੇ। ਡਿਵੈਲਪਮੈਂਟ ਸਰਵਰ ਆਮ ਦੋਸ਼ੀ ਹਨ, ਕਿਉਂਕਿ ਉਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤੇ ਡਿਫ਼ਾਲਟ ਰੂਪ ਵਿੱਚ loopback 'ਤੇ ਬਾਈਂਡ ਹੁੰਦੇ ਹਨ ਅਤੇ ਸਿਰਫ਼ ਉਸੇ ਮਸ਼ੀਨ ਤੋਂ ਆਉਣ ਵਾਲੇ ਕਨੈਕਸ਼ਨ ਸਵੀਕਾਰ ਕਰਦੇ ਹਨ। ਟਨਲ ਪਤਾ ਉਸ ਬਾਈਂਡਿੰਗ ਨੂੰ ਨਹੀਂ ਬਦਲਦਾ, ਅਤੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ VPN ਦੇ ਸ਼ਾਮਲ ਹੋਣ ਤੋਂ ਬਹੁਤ ਪਹਿਲਾਂ ਕਨੈਕਸ਼ਨ ਨੂੰ ਰੱਦ ਕਰ ਦੇਵੇਗਾ।
ss -ltnp | grep 8443
netstat -ano | findstr 8443ਸਥਿਤੀ ਨਹੀਂ, ਸਥਾਨਕ ਪਤਾ ਕਾਲਮ ਪੜ੍ਹੋ। 127.0.0.1:8443 ਦਾ ਮਤਲਬ ਸਿਰਫ਼ loopback ਹੈ, ਅਤੇ ਹੱਲ 0.0.0.0 ਜਾਂ ਟਨਲ ਪਤੇ 'ਤੇ ਹੀ ਬਾਈਂਡ ਕਰਨਾ ਹੈ। 0.0.0.0:8443 ਹਰ ਇੰਟਰਫ਼ੇਸ 'ਤੇ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਜੋ ਉਸ ਨਾਲੋਂ ਵਿਸਤ੍ਰਿਤ ਹੈ ਜਿੰਨਾ ਬਹੁਤੇ ਲੋਕ ਸੋਚਦੇ ਹਨ ਜਦੋਂ ਮਸ਼ੀਨ ਦਾ ਜਨਤਕ ਪਤਾ ਵੀ ਹੋਵੇ; 10.64.7.15:8443 ਸੰਕੀਰਣ ਸੰਸਕਰਣ ਹੈ ਜੋ ਸਿਰਫ਼ ਉੱਥੇ ਸੁਣਦਾ ਹੈ ਜਿੱਥੇ ਸਹਿਕਰਮੀ ਪਹੁੰਚ ਸਕਦਾ ਹੈ। ਉਸੇ ਆਉਟਪੁੱਟ ਵਿੱਚ ਪ੍ਰਕਿਰਿਆ ਦਾ ਨਾਮ ਵੀ ਦੇਖੋ, ਕਿਉਂਕਿ ਪਿਛਲੇ ਟੈਸਟ ਤੋਂ ਬਚਿਆ ਹੋਇਆ ਇੱਕ ਆਵਾਰਾ ਇੰਸਟੈਂਸ ਆਮ ਕਾਰਨ ਹੈ ਕਿ ਪੋਰਟ ਖੁੱਲ੍ਹਾ ਦਿਸਦਾ ਹੈ ਅਤੇ ਗਲਤ ਸਮੱਗਰੀ ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ।
ਫਿਰ ਪੁੱਛੋ ਕਿ ਕੀ ਕੋਈ ਉਸ ਪਤੇ 'ਤੇ ਰੂਟ ਕਰ ਸਕਦਾ ਹੈ
ਟਨਲ ਪਤੇ ਦਾ ਅਰਥ ਸਿਰਫ਼ ਉਹਨਾਂ ਸਾਥੀਆਂ ਲਈ ਹੈ ਜੋ ਉਸ ਪ੍ਰੀਫ਼ਿਕਸ ਨੂੰ ਟਨਲ ਵਿੱਚ ਭੇਜਣ ਲਈ ਸੰਰਚਿਤ ਹਨ। ਸਹਿਕਰਮੀ ਦੀ ਮਸ਼ੀਨ ਦੀ ਆਪਣੀ ਸਾਰਣੀ ਹੈ, ਅਤੇ ਜੇ ਟਨਲ ਸਬਨੈੱਟ ਲਈ ਮਾਰਗ ਨਹੀਂ ਹੈ ਤਾਂ ਪੈਕਟ ਡਿਫ਼ਾਲਟ ਗੇਟਵੇ ਵੱਲ ਜਾਂਦਾ ਹੈ ਅਤੇ ਅਜਿਹੀ ਥਾਂ 'ਤੇ ਮਰ ਜਾਂਦਾ ਹੈ ਜਿਸਨੂੰ ਪਤੇ ਦੇ ਹੋਣ ਦਾ ਕੋਈ ਪਤਾ ਨਹੀਂ। ਇਹ ਕਾਲਰ ਪਾਸੇ ਦਾ ਰੂਟਿੰਗ ਸਵਾਲ ਹੈ, ਤੁਹਾਡੇ ਪਾਸੇ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ।
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
ਦੋ ਕਲਾਇੰਟਾਂ ਵਿਚਕਾਰਲਾ ਸਰਵਰ ਵੀ ਓਨਾ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਆਮ ਰਿਮੋਟ ਪਹੁੰਚ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਹਰ ਕਲਾਇੰਟ ਗੇਟਵੇ ਵੱਲ ਬਾਹਰੀ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਦਾ ਹੈ ਅਤੇ ਗੇਟਵੇ ਉਹਨਾਂ ਪ੍ਰਵਾਹਾਂ ਦੀ ਸਥਿਤੀ ਰੱਖਦਾ ਹੈ, ਇਸ ਲਈ ਜਵਾਬ ਉਸ ਰਾਹੀਂ ਵਾਪਸ ਆਉਂਦੇ ਹਨ ਜਿਸਨੂੰ ਉਹ ਪਹਿਲਾਂ ਹੀ ਜਾਣਦਾ ਹੈ। ਇੱਕ ਕਲਾਇੰਟ ਤੋਂ ਦੂਜੇ ਤੱਕ ਕਨੈਕਸ਼ਨ ਨਵਾਂ ਪ੍ਰਵਾਹ ਹੈ ਜਿਸਨੂੰ ਗੇਟਵੇ ਨੂੰ ਸਵੀਕਾਰ ਕਰਕੇ ਅੱਗੇ ਭੇਜਣਾ ਪੈਂਦਾ ਹੈ, ਅਤੇ ਬਹੁਤ ਸਾਰੀਆਂ ਤੈਨਾਤੀਆਂ ਕਲਾਇੰਟਾਂ ਨੂੰ ਇੱਕ ਦੂਜੇ ਤੋਂ ਵੱਖ ਰੱਖਣ ਲਈ ਇਸਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ ਬੰਦ ਰੱਖਦੀਆਂ ਹਨ। ਖਪਤਕਾਰ VPN ਸੇਵਾਵਾਂ ਆਮ ਤੌਰ 'ਤੇ ਡਿਫ਼ਾਲਟ ਰੂਪ ਵਿੱਚ ਵੱਖ ਰੱਖਦੀਆਂ ਹਨ; ਕਾਰਪੋਰੇਟ ਗੇਟਵੇ ਕਦੇ-ਕਦਾਈਂ ਸਮੂਹ ਅਨੁਸਾਰ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ।
ਹੋਸਟ 'ਤੇ ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਦਿਸ਼ਾ ਜਾਂਚੋ। ਜੇ ਟਨਲ ਪਤਾ ਗੇਟਵੇ ਆਪਣੇ ਆਪ ਤੋਂ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਪਰ ਸਾਥੀ ਤੋਂ ਨਹੀਂ, ਤਾਂ ਫ਼ਰਕ ਗੇਟਵੇ ਦੀ ਕਲਾਇੰਟ-ਤੋਂ-ਕਲਾਇੰਟ ਸੈਟਿੰਗ ਹੈ, ਅਤੇ ਸਥਾਨਕ ਫਾਇਰਵਾਲ ਦਾ ਕੋਈ ਵੀ ਸੋਧ ਉਸਦੀ ਥਾਂ ਨਹੀਂ ਲੈ ਸਕਦਾ।
ਅਖ਼ੀਰ ਵਿੱਚ, ਉਹ ਨੀਤੀ ਲੱਭੋ ਜੋ ਪ੍ਰਵਾਹ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ
ਰੂਟ ਕੀਤੇ ਪੈਕਟ ਅਤੇ ਜਵਾਬ ਦੇਣ ਵਾਲੀ ਸੇਵਾ ਵਿਚਕਾਰ ਨੀਤੀ ਦੀਆਂ ਤਿੰਨ ਪਰਤਾਂ ਹਨ: VPN ਸਰਵਰ ਦਾ ਫ਼ਾਰਵਰਡਿੰਗ ਫ਼ੈਸਲਾ, ਹੋਸਟ ਫਾਇਰਵਾਲ, ਅਤੇ ਇੰਸਟੈਂਸ ਅੱਗੇ ਕੋਈ ਵੀ ਕਲਾਊਡ ਸੁਰੱਖਿਆ ਸਮੂਹ। ਤਿੰਨੇ ਸਹਿਮਤ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਅਤੇ ਉਹ ਵੱਖਰੇ ਤਰੀਕਿਆਂ ਨਾਲ ਅਸਫਲ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਉੱਪਰ ਦਿੱਤੀ ਸਾਰਣੀ ਦਾ ਲੱਛਣ ਬ੍ਰਾਊਜ਼ਰ ਦੇ ਗਲਤੀ ਸੰਦੇਸ਼ ਨਾਲੋਂ ਵਧੇਰੇ ਲਾਹੇਵੰਦ ਹੈ।
ਸਫਲ ਬਾਈਂਡ ਤੋਂ ਬਾਅਦ ਲੋਕ ਜਿਸ ਪਰਤ ਨੂੰ ਭੁੱਲ ਜਾਂਦੇ ਹਨ ਉਹ ਹੋਸਟ ਫਾਇਰਵਾਲ ਹੈ, ਕਿਉਂਕਿ LAN ਇੰਟਰਫ਼ੇਸ 'ਤੇ ਪੋਰਟ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਵਾਲਾ ਨਿਯਮ ਟਨਲ ਇੰਟਰਫ਼ੇਸ 'ਤੇ ਆਪਣੇ ਆਪ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦਾ। ਇੰਟਰਫ਼ੇਸ-ਸੀਮਤ ਨਿਯਮ ਸਹੀ ਡਿਜ਼ਾਈਨ ਹਨ ਅਤੇ ਦਫ਼ਤਰ ਤੋਂ ਚੱਲਣ ਵਾਲੀ ਪਰ ਘਰ ਤੋਂ ਨਾ ਚੱਲਣ ਵਾਲੀ ਸੇਵਾ ਦਾ ਆਮ ਕਾਰਨ ਵੀ ਹਨ। ਨਿਯਮ ਦਾ ਪੋਰਟ ਨੰਬਰ ਨਹੀਂ, ਉਸਦਾ ਦਾਇਰਾ ਪੜ੍ਹੋ।
ਸਥਿਤੀ-ਆਧਾਰਿਤ ਫਿਲਟਰਿੰਗ ਉਲਟੀ ਸਥਿਤੀ ਦੀ ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ। ਤੁਹਾਡੇ ਲੈਪਟਾਪ ਤੋਂ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਕਨੈਕਸ਼ਨ ਸਥਿਤੀ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਉਸਦੇ ਜਵਾਬ ਇਨਬਾਉਂਡ ਨਿਯਮ ਤੋਂ ਬਿਨਾਂ ਸਵੀਕਾਰ ਹੁੰਦੇ ਹਨ। ਸਹਿਕਰਮੀ ਦਾ ਕਨੈਕਸ਼ਨ ਪਿੱਛੇ ਸਥਿਤੀ ਤੋਂ ਬਿਨਾਂ ਬਿਲਕੁਲ ਨਵਾਂ ਪ੍ਰਵਾਹ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਸਪੱਸ਼ਟ ਇਜਾਜ਼ਤ ਚਾਹੀਦੀ ਹੈ। ਇਹੀ ਅਸਮਾਨਤਾ ਪੂਰਾ ਕਾਰਨ ਹੈ ਕਿ ਤੁਹਾਡੀ ਆਪਣੀ ਮਸ਼ੀਨ 'ਤੇ ਚੱਲਦਾ ਬ੍ਰਾਊਜ਼ਰ ਸੈਸ਼ਨ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ ਕਿ ਸੇਵਾ ਬਾਹਰੋਂ ਪਹੁੰਚਯੋਗ ਹੈ ਜਾਂ ਨਹੀਂ।
ਜਦੋਂ ਇੱਕ ਜਾਂਚ ਅਸਫਲ ਹੋਵੇ ਤਾਂ ਟਨਲ ਨਹੀਂ, ਡਿਜ਼ਾਈਨ ਬਦਲੋ
ਜੇ ਲੋੜ ਇਹ ਹੈ ਕਿ ਸਹਿਕਰਮੀ ਤੁਹਾਡੀ ਸਥਾਨਕ ਸੇਵਾ ਖੋਲ੍ਹੇ, ਤਾਂ ਇਮਾਨਦਾਰ ਜਵਾਬ ਆਮ ਤੌਰ 'ਤੇ ਇਨਬਾਉਂਡ ਪਹੁੰਚ ਲਈ ਬਣਾਇਆ ਗਿਆ ਕੋਈ ਤੰਤਰ ਹੁੰਦਾ ਹੈ। ਉਲਟਾ SSH ਟਨਲ ਸਭ ਤੋਂ ਛੋਟਾ ਹੈ: ਤੁਹਾਡੀ ਮਸ਼ੀਨ ਬਾਹਰ ਵੱਲ ਅਜਿਹੇ ਹੋਸਟ ਨਾਲ ਜੁੜਦੀ ਹੈ ਜਿੱਥੇ ਸਹਿਕਰਮੀ ਪਹਿਲਾਂ ਹੀ ਪਹੁੰਚ ਸਕਦਾ ਹੈ, ਅਤੇ ਸਰੋਤਾ ਉਸੇ ਹੋਸਟ 'ਤੇ ਹੁੰਦਾ ਹੈ।
ssh -N -R 8443:127.0.0.1:8443 [email protected]ਰਿਲੇ ਨੂੰ ਆਪਣੇ SSH ਸਰਵਰ ਸੰਰਚਨਾ ਵਿੱਚ GatewayPorts clientspecified ਚਾਹੀਦਾ ਹੈ, ਨਹੀਂ ਤਾਂ ਅੱਗੇ ਭੇਜਿਆ ਸਰੋਤਾ ਰਿਲੇ 'ਤੇ loopback ਨਾਲ ਬੱਝ ਜਾਂਦਾ ਹੈ ਅਤੇ ਸਹਿਕਰਮੀ ਨੂੰ ਪਹਿਲਾਂ ਵਾਂਗ ਹੀ ਉਹੀ ਇਨਕਾਰ ਮਿਲਦਾ ਹੈ। ਦੁਪਹਿਰ ਤੋਂ ਵੱਧ ਚੱਲਣ ਵਾਲੀ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਲਈ ਸਿਹਤ ਜਾਂਚ ਅਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਨਾਮ ਲਈ ਸਰਟੀਫਿਕੇਟ ਵਾਲਾ ਲੋਡ ਬੈਲੰਸਰ ਜਾਂ ingress ਵਧੀਆ ਸਾਧਨ ਹੈ, ਅਤੇ ਜਦੋਂ ਦੋ ਨੈੱਟਵਰਕਾਂ ਨੂੰ ਸੱਚਮੁੱਚ ਗੱਲ ਕਰਨੀ ਹੋਵੇ ਤਾਂ ਦੋਵੇਂ ਸਬਨੈੱਟਾਂ ਲਈ ਮਾਰਗ ਵਾਲਾ ਸਾਈਟ-ਤੋਂ-ਸਾਈਟ ਟਨਲ ਸਹੀ ਜਵਾਬ ਹੈ।
ਇਹਨਾਂ ਡਿਜ਼ਾਈਨਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਐਕਸਪੋਜ਼ਰ ਨੂੰ ਸਪੱਸ਼ਟ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਮੁੱਖ ਗੱਲ ਹੈ। VPN ਪੈਕਟਾਂ ਨੂੰ ਉਹਨਾਂ ਨੈੱਟਵਰਕਾਂ ਵਿਚਕਾਰ ਲਿਜਾਂਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਵਰਤੋਂ ਦੀ ਇਜਾਜ਼ਤ ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ ਹੀ ਸੀ; ਇਹ ਸੇਵਾ ਪ੍ਰਕਾਸ਼ਿਤ ਨਹੀਂ ਕਰਦਾ ਅਤੇ ਲੈਪਟਾਪ ਨੂੰ ਇੰਟਰਨੈੱਟ ਵੱਲ ਦੇਖਦੇ ਹੋਸਟ ਵਿੱਚ ਨਹੀਂ ਬਦਲਦਾ। ਤਿੰਨ ਪਰਤਾਂ ਵਿੱਚੋਂ ਕਿਹੜੀ ਬਦਲਣੀ ਹੈ ਇਹ ਤੈਅ ਕਰਨਾ ਕੰਮ ਹੈ, ਅਤੇ ਟਨਲ ਉਹਨਾਂ ਵਿੱਚੋਂ ਘੱਟ ਹੀ ਇੱਕ ਹੁੰਦਾ ਹੈ।