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 ચાલુ હોવાથી તે દેખાતી નથી.

VPN માંથી Core ને બહાર રાખવું ત્રીજી રચના છે, અને કેટલાક ઓપરેટરો માટે કાયદેસર છે, પરંતુ તે પીઅર ટ્રાફિકને તમારા સામાન્ય કનેક્શન પર મૂકે છે. તે VPN દ્વારા ઇનબાઉન્ડ એક્સેસ નથી, અને રાઉટર કે અપસ્ટ્રીમ NAT ને હજી પણ પોતાની મંજૂર એન્ટ્રીની જરૂર પડી શકે છે. બીજું કંઈ પણ બદલતા પહેલાં નક્કી કરો કે તમે ખરેખર ત્રણમાંથી કયું ચકાસી રહ્યા છો.