בריכת כרייה דרך VPN: לשמור את הסשן במסלול הנכון
כורה בריכה פותח סשן Stratum יוצא אחד, לא פורט peer. הצב את המנהרה מתחת לתהליך הזה וקרא את המסלול והפותר ממרחב השמות שלו.
תוכנת הכרייה מחזיקה שקע אחד פתוח לכתובת אחת, וכל שאלה על המנהרה, המסלול והעבודה שנזקפה תלויה בשקע הזה. השקע הזה הוא סשן לקוח יוצא לנקודת הקצה של הבריכה, לא מאזין שמקבל peer-ים. המסלול שלהלן עוקב אחריו מארבעת הערכים שהבריכה הנפיקה ועד לחלק שהבריכה באמת רשמה, והוא משאיר את שאר השירותים במארח לנפשם. כל שלב מפיק תשובה שאפשר להשוות, לא רושם.
התחל בנקודת הקצה שהבריכה באמת הנפיקה
הבריכה נותנת לך ארבעה ערכים שמרכיבים את כל החוזה: שם מארח או כתובת, פורט, גרסת פרוטוקול ומחרוזת חשבון. קח אותם מלוח הבקרה של הבריכה או מהודעת הפתיחה, לא ממדריך של בריכה אחרת. קיימים שרדים אזוריים לאותו שירות, ולכן שם מארח שהועתק ממדריך ישן עדיין יכול להתחבר ועדיין יכול לזכות חשבון שלא התכוונת להשתמש בו מעולם. העתק את ארבעת הערכים כלשונם לתצורת הכורה, כי מחרוזת חשבון שהוקלדה מחדש מאבדת מפריד.
הזרימה שאתה מנתב היא זו שמדריך מפתחי Bitcoin מכנה סשן Stratum: חיבור TCP דו-כיווני מתמשך שבו הבריכה מחלקת עבודה והכורה מחזיר חלקים. זו אינה אותה זרימה כמו חיבורי peer של צומת מלא או סנכרון שרשרת של ארנק, וקיפול כולם למחלקת תעבורה אחת הוא המקום שבו רוב הבלבול מתחיל. רק הראשון שייך למדיניות הזו.
היכן שהבריכה מציעה TLS, שמור על אימות השרת שהתיעוד שלה דורש. מנהרה מצפינה את הקפיצה מהמכונה שלך לשרת ה-VPN ומסתיימת שם; היא אינה ערובה למי שעונה בצד השני. שמור על שתי הבדיקות, אחת בכל קצה, אם אתה רוצה שהסשן ישרוד יציאה שנפרצה.
הצמד את המנהרה לתהליך, לא למשק הבית
שתי נקודות הצמדה עובדות: הרץ את לקוח ה-VPN בתוך מרחב השמות של הרשת שהכורה משתמש בו, או תן למרחב השמות הזה שער שמעביר את התעבורה שלו למנהרה. שני הסידורים שמים את הסשן על המסלול לפני שהבריכה רואה אותו. הכשל הרגיל הוא לקוח במארח, כורה במכולה עם גשר משלו ומסלול מארח שהמכולה אינה מתייעצת אתו לעולם. חלון הלקוח נראה בריא בשעה שהבריכה רושמת את כתובת הבית שלך.
בדוק את התעבורה של המנהרה עצמה לפני שאתה מגביל משהו. הלקוח חייב להגיע לשרת שלו דרך השכבה התחתונה, ולכן מדיניות שלוכדת כל מנה לוכדת גם את המנות שהיו בונות את המנהרה. אז המנהרה לא יכולה להתחיל וגם שום דבר אחר לא יוצא. בחר בתכונת המנהרה המפוצלת של הלקוח מה נכנס למנהרה; עריכת מסלולי ברירת מחדל ביד היא הדרך שבה השכבה התחתונה נעלמת.
כשהמדיניות במקומה, קרא את טבלת השקעים במרחב השמות שהכורה שייך לו. הזרימה לפורט של הבריכה אמורה לשבת על ממשק המנהרה, ושתי פקודות עונות על השאלה הזו. הפורט שלמטה הוא דוגמה; החלף אותו בזה שהבריכה הנפיקה.
sudo nsenter -t "$(pidof cgminer)" -n ss -tnp state established 'dport = :3333'
sudo nsenter -t "$(pidof cgminer)" -n ip route get 203.0.113.10קרא מסלול ופותר מתוך ההקשר של הכורה עצמו
ניתוב ופתרון שמות הם לכל מרחב שמות, ולכן בדיקה שרצה במעטפת רגילה מתארת את המכונה הלא נכונה בכל פעם שהכורה במכולה. היכנס קודם למרחב השמות ואז שאל איזה ממשק יישא מנה לכתובת הבריכה ואיזה פותר יענה לשם המארח שלה. התשובות של המארח אינן מועברות, והפער ביניהן הוא מקור נפוץ להטלת אשמה במקום הלא נכון.
נקוב בשם הממשק שאתה מקבל: מנהרה משמעה שהסשן במסלול המיועד, בעוד שהקישור הפיזי משמעו שכלל התאים מוקדם מכפי שציפית. אורך הקידומת מכריע ראשון, אחר כך המדד, אחר כך כללי המדיניות, ולכן טבלה עם כמה ערכי ברירת מחדל אינה מכפילה מנות, היא רק מפסידה.
פותרים נכשלים בנפרד ממסלולים. מנהרה שמשכתבת את /etc/resolv.conf עלולה להשאיר את מרחב השמות מצביע על פותר שנגיש רק מתוך המנהרה, וזה נכשל לפני שמתרחשת לחיצת יד TCP כלשהי. פתור את שם המארח של הבריכה בתוך מרחב השמות והשווה לכתובת שפורסמה. אם החיפוש פג תוקף או מחזיר משהו אחר, תקן את הפתרון לפני שאתה נוגע במסלולים.
החזק בנפרד את לקוח הבריכה ואת מאזין הצומת
פורט 8333 הוא פורט ה-peer של Bitcoin Core, שבו צומת מלא מאזין לחיבורים נכנסים; כורה בריכה אינו זקוק לו פתוח לעולם, ופתיחתו אינה מתקנת תקלה יוצאת. מאזינים נכנסים וסשנים יוצאים הם תפקידים מנוגדים עם הנחות אמון מנוגדות. שום דבר בתצורת הכורה אינו קושר את הפורט הזה, ולכן פורט סגור אינו יכול להסביר שום שגיאה שהוא מדווח. עצה שנכתבה לנגישות של צומת עשויה אפוא להשאיר שירות ציבורי פועל במארח שאמור היה רק לשלוח חלקים.
אם מכונה אחת באמת עושה את שניהם, התייחס לכל תפקיד כשירות בפני עצמו עם החלטת גישה משלו. המאזין של הצומת שייך מאחורי המדיניות שאתה מחיל על שירותים ציבוריים, והסשן של הכורה שייך למדיניות היציאה שבוחרת את המנהרה. רשום איזה תפקיד המארח ממלא והסר את הכללים של התפקיד השני כשזה משתנה, כי כלל היתר שנותר שורד את הסיבה שלו.
הוכח שהבריכה קיבלה את העבודה
מאוורר עסוק וקצב גיבוב עולה מראים שהכורה מחשב, לא שמשהו הגיע לבריכה. ההוכחה נמצאת במוני השליחה של הלקוח או בלוח הבקרה של הבריכה: חלקים שהתקבלו, חלקים שנדחו והסיבה שמצורפת לכל דחייה. המספרים האלה מפרידים בין שלושה כשלים שנראים זהים מבחוץ: אין סשן, סשן בלי זיכוי וסשן שמתחבר מחדש שוב ושוב. קרא אותם לפני שאתה משנה תצורה כלשהי.
צפה בניסיון חיבור אחד עם רישום מפורט ורשום את השלב האחרון שהצליח. השלב שבו הרצף נעצר שימושי מכל הודעה בודדת סביבו:
| Last stage reached | What it rules out | Probe to run next |
|---|---|---|
| Name lookup completed | Resolver and namespace reachability | ip route get for the returned address |
| TCP connect completed | Route and egress filtering | ss -tnp on the tunnel interface |
| Subscription returned a job | Endpoint or protocol mismatch | Accepted against rejected counts |
אחר כך תן ללקוח לרוץ בחלון קצוב וספור את שתי התוצאות מהרישום שלו. grep אחד לכל מונה מספיק, והשוואה ביניהם על אותו חלון מפרידה בריכה איטית ממסלול שבור. התאם את המסלול למקום שבו הלקוח שלך כותב, כי שתי הספירות אינן תלויות במיקום:
grep -c Accepted /var/log/miner.log
grep -c Rejected /var/log/miner.logאם כלל אוסר חיבור ישיר לבריכה בכל פעם שהמנהרה נופלת, הבא אותו כחסימה מפורשת בנקודת הקצה של הבריכה. לקוח שמנסה שוב בשקט דרך הקישור הפיזי ימשיך לכרות וימשיך להפר את הכלל הזה, ותצוגת המצב שלו לא תזכיר זאת. בדוק את הכלל בהפלת המנהרה בכוונה ובאימות שפורט הבריכה אינו נגיש כלל.