Нема влезни peer-ови на вашиот Bitcoin јазол зад VPN?

Вашиот јазол е синхронизиран, VPN-от пријавува врска, и getpeerinfo прикажува осум или десет peer-ови. Ниту еден од нив нема inbound поставено на true. Таа комбинација е нормална и не е дефект: излезните врски докажуваат дека јазолот може да стигне до другите, и ништо во нив не докажува дека некој може да стигне до вас. Ако целта е јазол што прима влезни P2P врски преку VPN, таа насока мора да ја тестирате одделно.

Следете го пакетот од peer-от до вашиот слушач

Влезниот P2P е ланец од четири работи и се кине на најслабата алка, не на најинтересната.

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

Стандардната P2P вредност на Core на главната мрежа е 8333, но давателот може да ви даде друг јавен порт и друга дестинација на клиентската страна. Запишете ја јавната адреса, надворешниот порт и местото каде давателот навистина го доставува сообраќајот. Потоа потврдете дека вашиот план и сметка воопшто дозволуваат влезни врски, бидејќи посветена излезна адреса не е договор за проследување порти.

Оваа разлика ги фаќа оние што купуваат статична IP очекувајќи достапност. Тоа што адресата е стабилна не кажува ништо за тоа дали давателот проследува влезна порта до вашата сесија.

Проверете го слушачот пред да го проверите давателот

Core мора да слуша на адресата и портата до кои доставува мапирањето, и хост firewall-от мора да го дозволи тоа. Ако јазолот работи во контејнер или на друга LAN машина, следниот скок и неговата рута за одговор исто така припаѓаат на ланецот.

Локално правило на firewall не може да создаде мапирање кај давател што фрла влезни пакети, а мапирањето на давателот не може да стигне до процес врзан само за loopback. Двете половини мора да се согласат за истата торка, затоа првиот чекор е да ја запишете торката наместо да ја погодувате.

Држете го објавениот крајен пункт во согласност со актуелното мапирање. Статичната адреса не го прави доделениот порт или неговиот закуп траен низ повторните поврзувања, па крајен пункт објавен пред месеци сега може да не покажува кон ништо. Прочитајте ја страницата на давателот повторно по секое повторно поврзување и споредете ја со тоа што го објавува вашиот јазол. Ако портата се преместила, стариот крајен пункт сега или не е ничиј или е на некој друг.

Читајте го знаменцето за влез, не вкупниот број врски

Од овластен локален RPC контекст, ова барање само за читање ги наведува peer-овите:

bitcoin-cli getpeerinfo

RPC-референцата inbound како true за влезна врска и false за излезна. Погледнете го тоа поле. Вкупниот број над десет не докажува ништо за насоката, а вкупните бројки и категориите и онака се менуваат со конфигурацијата и изданието.

Потоа тестирајте го мапираниот крајен пункт однадвор со нова проверка на достапност што имате овластување да ја извршите, и видете дали се појавува соодветен влезен peer. Внимавајте со излезот што го лепите во тема за поддршка: адресите на peer-овите се податоци за врските на други луѓе и не треба да се објавуваат за да добиете одговор на прашањето.

Не решавајте го со изложување на RPC

RPC документацијата на Bitcoin Core изрично предупредува да не се изложува RPC интерфејсот на јавниот интернет. Врските со peer-ови и автентифицираната администрација се различни услуги, а правењето P2P достапно со објавување RPC ја менува проблема со поврзаноста за многу полош.

Ако повеќе сакате воопшто да не зависат од влезниот P2P, документираната алтернатива е onion услуга и таа има свои предуслови: достапен Tor, конфигурирана контролна автентикација и поставки за слушање што дозволуваат услугата да се создаде. Таа не се појавува само затоа што случајно работи VPN.

Исклучувањето на Core од VPN е трет дизајн и за некои оператори е легитимен, но го става сообраќајот на peer-овите на вашата обична врска. Тоа не е влезен пристап преку VPN, и рутерот или горниот NAT може сѐ уште да бара свој дозволен запис. Изберете кој од трите навистина го тестирате пред да промените нешто друго.