הצומת שלך מסונכרן, ה-VPN מדווח על חיבור, ו- getpeerinfo מציג שמונה או עשרה עמיתים. לאף אחד מהם אין inbound מוגדר ל-true. השילוב הזה נורמלי ואינו תקלה: חיבורים יוצאים מוכיחים שהצומת יכול להגיע לאחרים, ושום דבר בהם אינו מוכיח שמישהו יכול להגיע אליך. אם המטרה היא צומת שמקבל חיבורי P2P נכנסים דרך VPN, עליך לבדוק את הכיוון הזה בנפרד.

עקוב אחר החבילה מהעמית אל המאזין שלך

P2P נכנס הוא שרשרת של ארבעה דברים, והוא נכשל בחוליה החלשה ולא בחוליה המעניינת ביותר.

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

ברירת המחדל של P2P ב-Core ברשת הראשית היא 8333, אבל הספק יכול לתת לך פורט ציבורי אחר ויעד אחר בצד הלקוח. רשום את הכתובת הציבורית, את הפורט החיצוני ואת המקום שאליו הספק באמת מוסר את התעבורה. אחר כך ודא שהתוכנית והחשבון שלך בכלל מתירים חיבורים נכנסים, כי כתובת יציאה ייעודית אינה חוזה העברת פורטים.

ההבחנה הזו תופסת אנשים שקונים IP סטטי בציפייה לנגישות. העובדה שהכתובת יציבה לא אומרת דבר על כך שהספק מעביר פורט נכנס לסשן שלך.

בדוק את המאזין לפני שאתה בודק את הספק

Core חייב להאזין בכתובת ובפורט שאליהם המיפוי מוסר, וחומת האש של המארח חייבת להתיר זאת. אם הצומת רץ בקונטיינר או במכונה אחרת ב-LAN, גם הקפיצה הבאה ונתיב התשובה שלה שייכים לשרשרת.

כלל חומת אש מקומי לא יכול ליצור מיפוי אצל ספק שזורק חבילות נכנסות, ומיפוי של ספק לא יכול להגיע לתהליך שמקושר רק ל-loopback. שני החצאים חייבים להסכים על אותה טאפל, ולכן הצעד הראשון הוא לרשום את הטאפל ולא לנחש אותו.

שמור על נקודת הקצה המוכרזת עקבית עם המיפוי הפעיל. כתובת סטטית אינה הופכת פורט שהוקצה או את החכירה שלו לקבועים בין התחברויות מחדש, כך שנקודת קצה שפורסמה לפני חודשים עשויה כעת לא להצביע על דבר. קרא שוב את עמוד הספק לאחר כל התחברות מחדש והשווה אותו למה שהצומת שלך מכריז. אם הפורט זז, נקודת הקצה הישנה כעת או שאינה של אף אחד או שהיא של מישהו אחר.

קרא את דגל הנכנסים, לא את סך החיבורים

מהקשר RPC מקומי מורשה, שאילתה זו לקריאה בלבד מפרטת עמיתים:

bitcoin-cli getpeerinfo

הפניה ל-RPC מגדירה את inbound כ-true לחיבור נכנס וכ-false לחיבור יוצא. הסתכל על השדה הזה. סכום מעל עשר אינו מוכיח דבר על הכיוון, והסכומים והקטגוריות משתנים עם התצורה והגרסה בכל מקרה.

לאחר מכן בדוק את נקודת הקצה הממופה מבחוץ בבדיקת נגישות חדשה שאתה מורשה להריץ, וראה אם מופיע עמית נכנס מתאים. היזהר עם הפלט שאתה מדביק בשרשור תמיכה: כתובות של עמיתים הן פרטי חיבור של אנשים אחרים, ואין צורך לפרסם אותן כדי ששאלתך תיענה.

אל תפתור את זה על ידי חשיפת RPC

התיעוד של RPC ב-Bitcoin Core מזהיר במפורש מפני חשיפת ממשק ה-RPC לאינטרנט הציבורי. חיבורים לעמיתים וניהול מאומת הם שירותים שונים, והפיכת P2P לנגיש על ידי פרסום RPC מחליפה בעיית קישוריות בבעיה גרועה בהרבה.

אם אתה מעדיף לא להיות תלוי ב-P2P נכנס כלל, שירות onion הוא החלופה המתועדת, ויש לו דרישות מקדימות משלו: Tor זמין, אימות בקרה מוגדר והגדרות האזנה שמאפשרות ליצור את השירות. הוא לא מופיע רק מפני ש-VPN במקרה פועל.

החרגת Core מה-VPN היא עיצוב שלישי, ולגיטימי עבור חלק מהמפעילים, אבל היא שמה את תעבורת העמיתים על החיבור הרגיל שלך. זו אינה גישה נכנסת דרך ה-VPN, ונתב או NAT במעלה הזרם עדיין עשוי להזדקק לרשומה מורשית משלו. בחר איזה מהשלושה אתה באמת בודק לפני שאתה משנה משהו אחר.

מאמרים קשורים