VPN ਪਿੱਛੇ ਤੁਹਾਡੇ Bitcoin ਨੋਡ 'ਤੇ ਕੋਈ ਇਨਬਾਊਂਡ ਪੀਅਰ ਨਹੀਂ?

ਤੁਹਾਡਾ ਨੋਡ ਸਿੰਕ ਹੋ ਗਿਆ ਹੈ, VPN ਕਹਿੰਦਾ ਹੈ ਕਿ ਕਨੈਕਟ ਹੈ, ਅਤੇ getpeerinfo ਅੱਠ ਜਾਂ ਦਸ ਪੀਅਰ ਦਿਖਾਉਂਦਾ ਹੈ। ਉਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਕੋਲ ਵੀ inbound true 'ਤੇ ਸੈੱਟ ਨਹੀਂ ਹੈ। ਇਹ ਸੰਜੋਗ ਆਮ ਹੈ ਅਤੇ ਇਹ ਖਰਾਬੀ ਨਹੀਂ: ਆਊਟਬਾਊਂਡ ਕਨੈਕਸ਼ਨ ਸਾਬਤ ਕਰਦੇ ਹਨ ਕਿ ਨੋਡ ਦੂਜਿਆਂ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਵਿੱਚ ਕੁਝ ਵੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਕੋਈ ਤੁਹਾਡੇ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ। ਜੇ ਟੀਚਾ VPN ਰਾਹੀਂ ਇਨਕਮਿੰਗ P2P ਕਨੈਕਸ਼ਨ ਸਵੀਕਾਰ ਕਰਨ ਵਾਲਾ ਨੋਡ ਹੈ, ਤਾਂ ਉਸ ਦਿਸ਼ਾ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਜਾਂਚਣਾ ਪਵੇਗਾ।

ਪੈਕੇਟ ਨੂੰ ਪੀਅਰ ਤੋਂ ਆਪਣੇ ਲਿਸਨਰ ਤੱਕ ਟ੍ਰੈਕ ਕਰੋ

ਇਨਬਾਊਂਡ P2P ਚਾਰ ਚੀਜ਼ਾਂ ਦੀ ਚੇਨ ਹੈ, ਅਤੇ ਇਹ ਸਭ ਤੋਂ ਕਮਜ਼ੋਰ ਕੜੀ 'ਤੇ ਟੁੱਟਦੀ ਹੈ, ਸਭ ਤੋਂ ਦਿਲਚਸਪ ਕੜੀ 'ਤੇ ਨਹੀਂ।

other peer
  -> provider's public address and assigned port
  -> the permitted VPN mapping
  -> Bitcoin Core's P2P listener

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

ਇਹ ਫ਼ਰਕ ਉਹਨਾਂ ਨੂੰ ਫੜਦਾ ਹੈ ਜੋ ਪਹੁੰਚ ਦੀ ਉਮੀਦ ਵਿੱਚ ਸਟੈਟਿਕ IP ਖਰੀਦਦੇ ਹਨ। ਪਤੇ ਦਾ ਸਥਿਰ ਹੋਣਾ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ ਕਿ ਪ੍ਰਦਾਤਾ ਤੁਹਾਡੇ ਸੈਸ਼ਨ 'ਤੇ ਇਨਬਾਊਂਡ ਪੋਰਟ ਫਾਰਵਰਡ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ ਨਹੀਂ।

ਪ੍ਰਦਾਤਾ ਜਾਂਚਣ ਤੋਂ ਪਹਿਲਾਂ ਲਿਸਨਰ ਜਾਂਚੋ

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

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

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

ਇਨਬਾਊਂਡ ਫਲੈਗ ਪੜ੍ਹੋ, ਕੁੱਲ ਕਨੈਕਸ਼ਨ ਨਹੀਂ

ਇੱਕ ਅਧਿਕਾਰਤ ਸਥਾਨਕ RPC ਸੰਦਰਭ ਤੋਂ, ਇਹ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਵਾਲੀ ਕਿਊਰੀ ਪੀਅਰਾਂ ਦੀ ਸੂਚੀ ਦਿੰਦੀ ਹੈ:

bitcoin-cli getpeerinfo

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

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

RPC ਨੂੰ ਖੋਲ੍ਹ ਕੇ ਇਸਨੂੰ ਹੱਲ ਨਾ ਕਰੋ

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

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

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