N2N ਓਵਰਲੇ ਪ੍ਰੌਕਸੀ ਨਹੀਂ ਹੈ: ਦੋਵੇਂ ਕਨੈਕਸ਼ਨ ਲਿਖੋ

Firefox 127.0.0.1:8000 ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ, N2N ਕਿਨਾਰਾ ਚਾਲੂ ਹੈ, ਪੀਅਰ ਆਪਣੇ ਓਵਰਲੇ ਪਤੇ 'ਤੇ ping ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਅਜੇ ਵੀ ਦੱਸਦਾ ਹੈ ਕਿ ਪ੍ਰੌਕਸੀ ਨੇ ਕਨੈਕਸ਼ਨ ਇਨਕਾਰ ਕੀਤਾ। ਇਸ ਲੜੀ ਵਿੱਚ ਕੁਝ ਵੀ ਵਿਰੋਧਾਭਾਸੀ ਨਹੀਂ। ਓਵਰਲੇ ਹੋਸਟ ਨੂੰ ਨਿੱਜੀ ਨੈੱਟਵਰਕ 'ਤੇ ਪਹੁੰਚਯੋਗ ਪਤਾ ਦਿੰਦਾ ਹੈ; ਇਹ ਪ੍ਰੌਕਸੀ ਪ੍ਰੋਟੋਕੋਲ ਬੋਲਣ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ ਬਣਾਉਂਦਾ। ਬ੍ਰਾਊਜ਼ਰ ਪੀਅਰ ਵੱਲ ਮਾਰਗ ਨਹੀਂ ਮੰਗ ਰਿਹਾ। ਇਹ ਸਥਾਨਕ ਲਿਸਨਰ ਮੰਗ ਰਿਹਾ ਹੈ।

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

ਦੋ ਕਨੈਕਸ਼ਨ, ਇੱਕ ਨਹੀਂ

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

ਪੀਅਰ ਨੂੰ ping ਕਰਨਾ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਓਵਰਲੇ ਕਿਨਾਰੇ ਦੇ ਪਤਿਆਂ ਦਰਮਿਆਨ ਪੈਕਟ ਪਹੁੰਚਾ ਸਕਦਾ ਹੈ। ਇਹ ਪੋਰਟ 8000 'ਤੇ ਲਿਸਨਰ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਨਾ ਹੀ ਇਹ ਕਿ ਉਹ ਹੋਸਟ ਮੂਲ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ। ਵੱਖਰੀਆਂ ਫੇਲ੍ਹਾਂ, ਵੱਖਰੇ ਸੁਧਾਰ।

ਲਿਸਨਰ ਕਿੱਥੇ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ

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

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

localhost ਪੀਅਰ ਨਹੀਂ ਹੈ

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

ਸੁਪਰਨੋਡ ਕਿਨਾਰਿਆਂ ਨੂੰ ਇੱਕ-ਦੂਜੇ ਨੂੰ ਲੱਭਣ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ; ਉਹ ਪ੍ਰੌਕਸੀ ਸੇਵਾ ਨਹੀਂ। ਸੁਪਰਨੋਡ ਪਤੇ ਨੂੰ ਪ੍ਰੌਕਸੀ ਐਂਡਪੌਇੰਟ ਮੰਨਣ ਨਾਲ ਉਹੀ ਇਨਕਾਰ ਮਿਲਦਾ ਹੈ, ਨਾਲ ਹੀ ਉਲਝਣ ਦਾ ਵਾਧੂ ਕਦਮ।

ਮਾਰਗ handshake ਨਹੀਂ ਕਰ ਸਕਦਾ

ਪਤਾ ਸਹੀ ਹੋਣ 'ਤੇ ਵੀ, ਰੂਟਿੰਗ ਪ੍ਰੌਕਸੀ ਕਰਨਾ ਨਹੀਂ ਹੈ। HTTP ਪ੍ਰੌਕਸੀ ਕਨੈਕਸ਼ਨ CONNECT ਬੇਨਤੀ ਜਾਂ ਪੂਰਨ-ਰੂਪ ਬੇਨਤੀ ਲਾਈਨ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਅਤੇ SOCKS ਪ੍ਰੌਕਸੀ ਸੰਸਕਰਣ ਅਤੇ ਢੰਗ ਦੀ ਗੱਲਬਾਤ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ। ਰਾਊਟਰ ਜਾਂ ਓਵਰਲੇ ਬਾਈਟ ਅੱਗੇ ਭੇਜਦਾ ਹੈ; ਇਹ ਉਨ੍ਹਾਂ ਸੁਨੇਹਿਆਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਨਹੀਂ ਕਰਦਾ ਜਾਂ ਤੁਹਾਡੀ ਥਾਂ ਅਗਲਾ ਕਨੈਕਸ਼ਨ ਨਹੀਂ ਖੋਲ੍ਹਦਾ। ਇਸੇ ਲਈ ping ਅਤੇ SSH ਲਈ ਕੰਮ ਕਰਨ ਵਾਲਾ ਮਾਰਗ ਬ੍ਰਾਊਜ਼ਰ ਪ੍ਰੌਕਸੀ ਲਈ ਫੇਲ੍ਹ ਹੋ ਸਕਦਾ ਹੈ: ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਸਹਿਯੋਗ ਕਰਨ ਵਾਲੀ ਪ੍ਰਕਿਰਿਆ ਚਾਹੀਦੀ ਹੈ, ਸਿਰਫ਼ ਪਹੁੰਚ ਨਹੀਂ।

ਜੇ ਟੀਚਾ ਸਿਰਫ਼ ਪੀਅਰ 'ਤੇ ਸੇਵਾ ਤੱਕ ਪਹੁੰਚਣਾ ਹੈ, ਤਾਂ ਪ੍ਰੌਕਸੀ ਸੈਟਿੰਗ ਹਟਾਓ ਅਤੇ ਸੇਵਾ ਦਾ ਓਵਰਲੇ ਪਤਾ ਸਿੱਧਾ ਵਰਤੋ।

ਹੱਦਾਂ ਕ੍ਰਮ ਵਿੱਚ ਪਰਖੋ

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

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