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 ಇನ್ನೂ ತನ್ನದೇ ಅನುಮತಿಸಿದ ನಮೂದನ್ನು ಬಯಸಬಹುದು. ಬೇರೆ ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಮೂರರಲ್ಲಿ ಯಾವುದನ್ನು ನೀವು ನಿಜವಾಗಿ ಪರೀಕ್ಷಿಸುತ್ತಿದ್ದೀರಿ ಎಂದು ಆರಿಸಿ.