VPN ਚਾਲੂ ਅਤੇ localhost ਕੰਮ ਕਰਨਾ ਬੰਦ: ਨਾਮ, ਪ੍ਰੌਕਸੀ ਜਾਂ ਬਾਈਂਡ?
ਜਦੋਂ ਖੋਜ ਸਫ਼ਿਕਸ ਜਾਂ ਪ੍ਰੌਕਸੀ ਨਿਯੰਤਰਣ ਲੈ ਲੈਂਦਾ ਹੈ ਤਾਂ localhost ਤੁਹਾਡੀ ਮਸ਼ੀਨ ਨੂੰ ਨਹੀਂ ਰਹਿੰਦਾ। ਪਹਿਲਾਂ ਨਾਮ, ਫਿਰ ਰੂਟ, ਫਿਰ ਟੂਲ ਦੀ ਕਨੈਕਸ਼ਨ ਸਟ੍ਰਿੰਗ ਠੀਕ ਕਰੋ।
ਤੁਹਾਡੇ ਡਿਵੈਲਪਮੈਂਟ ਸਰਵਰ ਨੇ ਇੱਕ ਮਿੰਟ ਪਹਿਲਾਂ ਜਵਾਬ ਦਿੱਤਾ ਸੀ, ਹੁਣ ਸੁਰੰਗ ਚਾਲੂ ਹੋਣ ਕਾਰਨ ਬੇਨਤੀ ਉਸ ਹੋਸਟ ਨਾਂ ਨਾਲ ਸਮਾਂ ਸੀਮਾ ਪਾਰ ਕਰ ਜਾਂਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਕਦੇ ਟਾਈਪ ਨਹੀਂ ਕੀਤਾ। ਲਗਭਗ ਹਰ ਕੇਸ ਨੂੰ ਦੋ ਵਿਧੀਆਂ ਸਮਝਾਉਂਦੀਆਂ ਹਨ, ਅਤੇ ਬਾਹਰੋਂ ਉਹ ਇੱਕੋ ਜਿਹੀਆਂ ਦਿਸਦੀਆਂ ਹਨ। ਖੋਜ ਸਫ਼ਿਕਸ ਛੋਟੇ ਨਾਮ ਨੂੰ ਕਾਰਪੋਰੇਟ ਨਾਮ ਬਣਾ ਦਿੰਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਪ੍ਰੌਕਸੀ ਲੂਪਬੈਕ ਟ੍ਰੈਫ਼ਿਕ ਨੂੰ ਅਜਿਹੇ ਹੋਸਟ ਭੇਜਦਾ ਹੈ ਜੋ ਉੱਥੇ ਪਹੁੰਚ ਨਹੀਂ ਸਕਦਾ। ਇਹਨਾਂ ਦੋਹਾਂ ਨੂੰ ਵੱਖ ਕਰਨ ਲਈ ਇੱਕ ਕਵੈਰੀ ਲੱਗਦੀ ਹੈ ਅਤੇ ਤੁਸੀਂ ਜੋ ਫਾਇਰਵਾਲ ਨਿਯਮ ਲਿਖਣ ਵਾਲੇ ਸੀ ਉਹ ਬਚ ਜਾਂਦਾ ਹੈ।
ਜਦੋਂ localhost ਕਾਰਪੋਰੇਟ ਜ਼ੋਨ ਵਿੱਚ ਰਿਜ਼ੌਲਵ ਹੁੰਦਾ ਹੈ
ਸੁਰੰਗ ਚਾਲੂ ਹੋਣ ਵੇਲੇ ਨਾਮ ਕਿਸ ਵਿੱਚ ਰਿਜ਼ੌਲਵ ਹੁੰਦਾ ਹੈ ਜਾਂਚੋ, ਫਿਰ ਸੁਰੰਗ ਬੰਦ ਕਰਕੇ ਉਹੀ ਕਵੈਰੀ ਚਲਾਓ ਅਤੇ ਦੋਵੇਂ ਜਵਾਬ ਤੁਲਨਾ ਕਰੋ। ਸੰਕੇਤ ਉਹ ਹੈ ਕਿ ਜਿੱਥੇ ਤੁਸੀਂ 127.0.0.1 ਦੀ ਉਮੀਦ ਕੀਤੀ ਸੀ ਉੱਥੇ ਕਾਰਪੋਰੇਟ ਰੇਂਜ ਦਾ ਪਤਾ ਮਿਲੇ। localhost.mycompany.corp ਵਰਗਾ ਰਿਕਾਰਡ ਕਲਾਇੰਟ ਵੱਲੋਂ ਉਹ ਸਫ਼ਿਕਸ ਖੋਜ ਸੂਚੀ ਵਿੱਚ ਜੋੜਨ ਸਾਰ ਲੂਪਬੈਕ ਐਂਟਰੀ ਨੂੰ ਹਰਾ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਬੇਨਤੀ ਉਸ ਪ੍ਰਾਈਵੇਟ ਹੋਸਟ ਵੱਲ ਜਾਂਦੀ ਹੈ ਜਿੱਥੇ ਉਸ ਪੋਰਟ ਉੱਤੇ ਕੁਝ ਵੀ ਨਹੀਂ ਸੁਣ ਰਿਹਾ। ਖੋਜ ਸੂਚੀ ਦਾ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਕਲਾਇੰਟ ਇੱਕ ਤੋਂ ਵੱਧ ਡੋਮੇਨ ਜੋੜ ਸਕਦਾ ਹੈ ਅਤੇ ਕ੍ਰਮ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਉਮੀਦਵਾਰ ਪਹਿਲਾਂ ਅਜ਼ਮਾਇਆ ਜਾਵੇ:
getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080
ਐਪਲੀਕੇਸ਼ਨ, ਡੇਟਾਬੇਸ ਕਲਾਇੰਟ ਜਾਂ ਨੋਟਬੁੱਕ URL ਵਿੱਚ ਹੋਸਟ ਨਾਮ ਦੀ ਥਾਂ ਸ਼ਾਬਦਿਕ ਪਤਾ ਪਾਓ, ਫਿਰ ਬੇਨਤੀ ਦੁਹਰਾਓ। ਜੇ ਅਸਫਲਤਾ ਮਿਟ ਜਾਵੇ ਤਾਂ ਤੁਹਾਡੀ ਨਾਮਕਰਨ ਦੀ ਸਮੱਸਿਆ ਸੀ ਅਤੇ ਸੁਰੰਗ ਸਿਰਫ਼ ਟ੍ਰਿਗਰ ਸੀ। ਜੇ ਉਹ ਰਹੇ ਤਾਂ ਸੁਣਨ ਵਾਲਾ ਜਾਂ ਰੂਟ ਅਗਲਾ ਸ਼ੱਕੀ ਹੈ ਅਤੇ ਨਾਮ ਸਿਰਫ਼ ਝੂਠਾ ਸੁਰਾਗ ਸੀ।
ਲੂਪਬੈਕ ਫੜਨ ਵਾਲੀਆਂ ਪ੍ਰੌਕਸੀ ਸੈਟਿੰਗਾਂ
ਸੁਰੰਗ ਉੱਠਣ ਵੇਲੇ ਲਾਗੂ ਹੋਣ ਵਾਲੀ ਸਿਸਟਮ ਪ੍ਰੌਕਸੀ 127.0.0.1 ਲਈ ਬੇਨਤੀ ਸਵੀਕਾਰ ਕਰੇਗੀ ਅਤੇ ਉਸਨੂੰ ਦੂਰ ਦੀ ਪ੍ਰੌਕਸੀ ਵੱਲ ਭੇਜੇਗੀ ਜਿਸਨੂੰ ਪਤਾ ਹੀ ਨਹੀਂ ਤੁਹਾਡਾ ਮਤਲਬ ਕੀ ਸੀ। ਖਾਲੀ ਬਾਈਪਾਸ ਸੂਚੀ ਸਥਾਨਕ ਬੇਨਤੀ ਨੂੰ ਦੂਰ ਦੀ ਬਣਾ ਦਿੰਦੀ ਹੈ, ਅਤੇ ਗਲਤੀ ਸੁਨੇਹਾ ਇਹ ਘੱਟ ਹੀ ਕਹਿੰਦਾ ਹੈ। ਲੂਪਬੈਕ ਪਤੇ ਇੱਕ ਹੁਕਮ ਲਈ ਨਹੀਂ ਬਲਕਿ ਪੂਰੇ ਸੈਸ਼ਨ ਲਈ ਬਾਈਪਾਸ ਸੂਚੀ ਵਿੱਚ ਜੋੜੋ, ਫਿਰ ਨੈੱਟਵਰਕ ਬਾਰੇ ਕੋਈ ਸਿੱਟਾ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਟੂਲ ਇਸਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ।
ਐਪਲੀਕੇਸ਼ਨ ਫਰੇਮਵਰਕ ਆਪਣੇ ਵਾਤਾਵਰਨ ਵੇਰੀਏਬਲ ਅਤੇ ਕਦੇ ਆਪਣੀ ਕਨਫਿਗਰੇਸ਼ਨ ਫਾਈਲ ਪੜ੍ਹਦੇ ਹਨ, ਇਸ ਲਈ ਇੱਕ ਟੂਲ ਲਈ ਕੰਮ ਕਰਨ ਵਾਲਾ ਬਾਈਪਾਸ ਅਗਲੇ ਲਈ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ। ਬ੍ਰਾਊਜ਼ਰ ਇੱਕ ਸੂਖਮਤਾ ਜੋੜਦੇ ਹਨ: Chromium ਅਧਾਰਿਤ ਬ੍ਰਾਊਜ਼ਰ ਲੂਪਬੈਕ ਲਈ ਪ੍ਰੌਕਸੀ ਨੂੰ ਅਪ੍ਰਤੱਖ ਤੌਰ ਤੇ ਬਾਈਪਾਸ ਕਰਦੇ ਹਨ, ਅਤੇ ਬਾਈਪਾਸ ਟੋਕਨ ਉਹ ਵਿਵਹਾਰ ਹਟਾ ਸਕਦਾ ਹੈ। ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੀ ਸੈਟਿੰਗ ਨੂੰ ਪੂਰੀ ਕਹਾਣੀ ਮੰਨਣ ਦੀ ਥਾਂ ਅਸਲ ਪ੍ਰੌਕਸੀ ਫੈਸਲਾ ਜਾਂਚੋ। ਸ਼ੈੱਲ ਤੋਂ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੀ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਲਈ ਦੋ ਹੁਕਮ ਇਹ ਤੈਅ ਕਰਦੇ ਹਨ:
curl --noproxy '*' http://127.0.0.1:8080/health
NO_PROXY=localhost,127.0.0.1,::1 your-tool
ਬਾਈਂਡ ਪਤਾ ਤੈਅ ਕਰਦਾ ਹੈ ਕੌਣ ਜੁੜ ਸਕਦਾ ਹੈ
127.0.0.1 ਉੱਤੇ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲਾ ਸਰਵਰ ਸਿਰਫ਼ ਉਸ ਮਸ਼ੀਨ ਤੋਂ ਕਨੈਕਸ਼ਨ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਜੋ ਡਿਵੈਲਪਮੈਂਟ ਲਈ ਆਮ ਤੌਰ ਤੇ ਸਹੀ ਡਿਫਾਲਟ ਹੈ। 0.0.0.0 ਉੱਤੇ ਸਰਵਰ VPN ਅਡੈਪਟਰ ਸਮੇਤ ਹਰ ਇੰਟਰਫ਼ੇਸ ਉੱਤੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਜੋ ਜ਼ਿਆਦਾਤਰ ਲੋਕਾਂ ਦੇ ਇਰਾਦੇ ਤੋਂ ਵੱਧ ਖੁਲਾਸਾ ਹੈ। ਜਦੋਂ ਸ਼ਾਬਦਿਕ ਲੂਪਬੈਕ ਪਤਾ ਅਸਫਲ ਹੋਵੇ ਤਾਂ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਬਾਈਂਡ ਜਾਂਚੋ।
ਸੁਣ ਰਹੇ ਸਾਕਟ ਨੂੰ ਵੇਖੋ ਅਤੇ ਉਹ ਪਤਾ ਲਿਖੋ ਜਿਸ ਨਾਲ ਇਹ ਬੰਨ੍ਹਿਆ ਹੋਇਆ ਹੈ, ਸਿਰਫ਼ ਪੋਰਟ ਨਹੀਂ। ਜੇ ਕਿਸੇ ਹੋਰ ਡਿਵਾਈਸ ਜਾਂ ਕੰਟੇਨਰ ਨੂੰ ਸੁਰੰਗ ਰਾਹੀਂ ਸੇਵਾ ਤੱਕ ਪਹੁੰਚਣਾ ਹੈ ਤਾਂ ਉਸ ਖਾਸ ਇੰਟਰਫ਼ੇਸ ਨਾਲ ਬਾਈਂਡ ਕਰੋ ਜੋ ਉਹ ਵਰਤੇਗਾ ਅਤੇ ਉਸ ਪੋਰਟ ਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ ਮਨਜ਼ੂਰੀ ਦਿਓ। ਜੇ ਸਿਰਫ਼ ਤੁਹਾਡੀ ਆਪਣੀ ਮਸ਼ੀਨ ਨੂੰ ਲੋੜ ਹੈ ਤਾਂ ਤੰਗ ਬਾਈਂਡ ਰੱਖੋ ਅਤੇ ਸਰਵਰ ਚੌੜਾ ਕਰਨ ਦੀ ਥਾਂ ਕਲਾਇੰਟ ਠੀਕ ਕਰੋ। ਪੋਰਟ ਫਾਰਵਰਡਿੰਗ ਜਾਂ ਸੁਰੰਗ ਪਰਤ ਦੋਵਾਂ ਨੂੰ ਜੋੜ ਸਕਦੀ ਹੈ, ਪਰ ਹਰ ਇੱਕ ਅਜਿਹਾ ਹਿੱਸਾ ਜੋੜਦੀ ਹੈ ਜਿਸਨੂੰ ਬਾਅਦ ਵਿੱਚ ਆਪਣੀ ਡੀਬੱਗਿੰਗ ਚਾਹੀਦੀ ਹੋਵੇਗੀ।
ਜਿੱਥੇ ਡੀਬੱਗਿੰਗ ਟੂਲ LAN ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ
ਡੀਬੱਗਿੰਗ ਟੂਲ ਅਜਿਹੀਆਂ ਧਾਰਨਾਵਾਂ ਲੈ ਕੇ ਚੱਲਦੇ ਹਨ ਜੋ ਸੁਰੰਗ ਚੁੱਪਚਾਪ ਤੋੜ ਦਿੰਦੀ ਹੈ। ਫ਼ੋਨ ਡੀਬੱਗਿੰਗ ਬ੍ਰਿਜ VPN ਵੱਲੋਂ ਡਿਵਾਈਸ ਦਾ ਸਬਨੈੱਟ ਫੜਨ ਉੱਤੇ ਆਪਣਾ ਡਿਵਾਈਸ ਗੁਆ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ LAN ਪਤੇ ਜਾਂ ਕੇਬਲ ਰਾਹੀਂ ਦੁਬਾਰਾ ਜੁੜਨਾ ਟਕਰਾਅ ਟਾਲਦਾ ਹੈ। ਬ੍ਰਾਊਜ਼ਰ ਆਟੋਮੇਸ਼ਨ ਹੱਬ ਉਦੋਂ ਸਮਾਂ ਸੀਮਾ ਪਾਰ ਕਰਦਾ ਹੈ ਜਦੋਂ ਹੱਬ ਸਿਰਫ਼ ਪ੍ਰੌਕਸੀ ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਹੋਵੇ, ਜਾਂ ਜਦੋਂ ਸਥਾਨਕ ਫਾਇਰਵਾਲ ਉਸਦਾ ਨਿਯੰਤਰਣ ਪੋਰਟ ਡੇਗ ਦੇਵੇ। ਦੂਰ ਦਾ ਡੀਬੱਗਰ ਉੱਥੇ ਐਲੀਵੇਸ਼ਨ ਅਤੇ ਲੂਪਬੈਕ ਪਤਾ ਮੰਗ ਸਕਦਾ ਹੈ ਜਿੱਥੇ ਕਲਾਇੰਟ ਨੇ ਰੂਟ ਦੁਬਾਰਾ ਲਿਖਿਆ ਹੋਵੇ।
ਨਿਯੰਤਰਣ ਪੋਰਟ ਅਤੇ ਡੇਟਾ ਪੋਰਟ ਵੱਖਰੇ ਪਛਾਣੋ, ਕਿਉਂਕਿ ਅਕਸਰ ਇੱਕ ਬਚਦਾ ਹੈ ਦੂਜਾ ਨਹੀਂ। ਫਿਰ ਤੈਅ ਕਰੋ ਕਿ ਸੁਧਾਰ ਟੂਲ ਦੀ ਕਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਹੈ, ਉਸ ਸਬਨੈੱਟ ਲਈ ਰੂਟ ਵਿੱਚ, ਜਾਂ ਸਪਲਿਟ ਸੁਰੰਗ ਨਿਯਮ ਵਿੱਚ। ਹਰ ਡਿਵੈਲਪਰ ਮਸ਼ੀਨ ਉੱਤੇ hosts ਫਾਈਲ ਸੋਧਣਾ ਸਭ ਤੋਂ ਮਾੜੇ ਢੰਗ ਨਾਲ ਸਕੇਲ ਹੁੰਦਾ ਹੈ ਅਤੇ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਭੁੱਲ ਜਾਂਦਾ ਹੈ। ਉਸ ਸੈਟਿੰਗ ਨੂੰ ਤਰਜੀਹ ਦਿਓ ਜੋ ਪ੍ਰੋਫਾਈਲ ਨਾਲ ਰਹਿੰਦੀ ਹੈ ਅਤੇ ਜਿਸਨੂੰ ਸੁਰੰਗ ਦਾ ਮਾਲਕ ਕੋਈ ਵੀ ਸਮੀਖਿਆ ਕਰ ਸਕਦਾ ਹੈ।
ਅਸਫਲ ਹੋਣ ਵਾਲੇ ਪਹਿਲੇ ਪੜਾਅ ਉੱਤੇ ਰੁਕੋ
ਤਿੰਨ ਪੜਾਵਾਂ ਵਿੱਚ ਹੇਠਾਂ ਉਤਰੋ: ਨਾਮ ਹੱਲ ਕਰੋ, ਸ਼ਾਬਦਿਕ ਪਤੇ ਲਈ ਸਾਕਟ ਖੋਲ੍ਹੋ, ਫਿਰ ਟੂਲ ਨੂੰ ਆਪਣਾ ਕਨੈਕਸ਼ਨ ਬਣਾਉਣ ਦਿਓ। ਹਰ ਪੜਾਅ ਇੱਕ ਪਰਤ ਹਟਾਉਂਦਾ ਹੈ, ਇਸ ਲਈ ਪਹਿਲੀ ਅਸਫਲਤਾ ਠੀਕ ਕਰਨ ਵਾਲੀ ਪਰਤ ਦਾ ਨਾਮ ਦੱਸਦੀ ਹੈ ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਸਭ ਕੁਝ ਬਿਨਾਂ ਜਾਂਚ ਰਹਿੰਦਾ ਹੈ। ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਨਤੀਜਾ ਲਿਖੋ, ਕਿਉਂਕਿ ਮਾਪ ਤੋਂ ਪਹਿਲਾਂ ਲਾਗੂ ਕੀਤਾ ਸੁਧਾਰ ਕਿਸਮਤ ਤੋਂ ਵੱਖ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ। ਜੇ ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ ਅਸਫਲ ਹੋਵੇ ਅਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕੰਮ ਕਰੇ ਤਾਂ ਟੂਲ ਸ਼ੁਰੂ ਹੋਣ ਵੇਲੇ ਸੁਰੰਗ ਤਿਆਰ ਨਹੀਂ ਸੀ।
ਸਥਿਰ ਉਡੀਕ ਦੀ ਥਾਂ ਰੂਟ ਦੀ ਉਡੀਕ ਕਰਨ ਵਾਲੀ ਸੀਮਿਤ ਤਿਆਰੀ ਜਾਂਚ ਰੱਖੋ, ਅਤੇ ਅਸਫਲ ਪੜਾਅ ਨੂੰ ਲਾਗ ਵਿੱਚ ਰੱਖੋ ਤਾਂ ਜੋ ਅਗਲਾ ਵਿਅਕਤੀ ਵੇਖ ਸਕੇ ਕਿ ਕਿੱਥੇ ਰੁਕਿਆ। ਆਪਣੇ ਆਪ ਠੀਕ ਹੋਣ ਵਾਲਾ ਟੂਲ ਠੀਕ ਨਹੀਂ ਹੋਇਆ, ਉਹ ਕਿਸਮਤ ਵਾਲਾ ਹੈ, ਅਤੇ ਕਿਸਮਤ ਕਿਸੇ ਹੋਰ ਦੀ ਮਸ਼ੀਨ ਉੱਤੇ ਖ਼ਤਮ ਹੁੰਦੀ ਹੈ। ਸੁਰੰਗ ਸਭ ਤੋਂ ਅਖੀਰ ਵਿੱਚ ਬਦਲੋ, ਅਤੇ ਸਿਰਫ਼ ਉਸ ਪੜਾਅ ਲਈ ਜੋ ਸੱਚਮੁੱਚ ਅਸਫਲ ਹੋਇਆ। ਇਹੀ ਕ੍ਰਮ ਕੰਮ ਕਰਨ ਵਾਲੇ ਬਿਲਡ ਵੱਲ ਵਾਪਸ ਜਾਣ ਦਾ ਸਭ ਤੋਂ ਛੋਟਾ ਰਾਹ ਵੀ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਤੁਹਾਨੂੰ ਉਹ ਹਿੱਸਾ ਦੁਬਾਰਾ ਬਣਾਉਣ ਤੋਂ ਰੋਕਦਾ ਹੈ ਜੋ ਕਦੇ ਸ਼ਾਮਲ ਹੀ ਨਹੀਂ ਸੀ।