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కు ఇంకా దాని సొంత అనుమతించిన ఎంట్రీ అవసరం కావచ్చు. మరేదైనా మార్చే ముందు మూడింటిలో మీరు నిజంగా ఏది పరీక్షిస్తున్నారో ఎంచుకోండి.