Tor מוכן לפני ה-VPN: סידור נכון של שער ההפעלה
תהליך tor פועל אינו נשא. שערו את ה-VPN על אות מוכנות מתועד של הלקוח, ואז על העמית שלו עצמו, והחזיקו את חלופות הנפילה בנפרד.
מעקב אחר תהליך tor ואז הפעלת ה-VPN היא הדרך הנפוצה ביותר לבנות את הערימה הזו לא נכון. התהליך הרקעי מופיע הרבה לפני שהוא יכול לשאת זרם לקוח, והמתנה קבועה היא ניחוש עטוף כתלות. השער חייב להיות המצב שהרכיב הבא באמת צריך. עברו על ארבעת השלבים שלמטה לפי הסדר, והתייחסו לכל אחד כתנאי נפרד ולא כהשהיה לכוונון.
שלב 1: בחרו את התעבורה שבאמת יש לכם
התחילו בפרוטוקול, כי שאר העיצוב תלוי בו. ממשק ה-SOCKS של Tor אינו מיישם UDP ASSOCIATE, ולכן כל מה שמועבר דרכו חייב להיות זרם TCP. פרופיל OpenVPN שמשתמש ב-UDP לא יעבוד בנתיב הזה, לא משנה איך נכתב המפקח. החליפו את הפרופיל ל-TCP ואשרו שהעמית המרוחק מקבל אותו לפני שאתם נוגעים בלוגיקת ההפעלה.
לאחר מכן אשרו שהלקוח שלכם בכלל מגיע לפרוקסי SOCKS. OpenVPN 2.6 מתעד אפשרות socks-proxy עבור פרופילי TCP, ולקוחות שונים חושפים תמיכת פרוקסי שונה. משגר שמתעלם בשקט מאפשרות הפרוקסי יתחבר ישירות וייראה כאילו הוא עובד, וזה גרוע מכישלון.
כתבו את התעבורה שנבחרה במדריך ההפעלה, כי כל בדיקה מאוחרת תלויה בה.
שלב 2: קראו את שלב ה-bootstrap, לא את רשימת התהליכים
פרוטוקול הבקרה של Tor עונה ל-GETINFO status/bootstrap-phase במצב ה-bootstrap העדכני, כולל אחוז התקדמות ותג סיכום. התשובה הזו שימושית בדיוק מפני שבקר יכול להתחבר אחרי שהתהליך הרקעי כבר סיים את ה-bootstrap. מפקח שמאזין רק לאירועים יפספס את המקרה שבו Tor כבר היה מוכן לפני שהמפקח התחיל.
אמתו את חיבור הבקרה כראוי. פורט בקרה הוא ממשק ניהולי, וכל מי שיכול לדבר איתו יכול להגדיר מחדש את התהליך הרקעי. החזיקו אותו ב-localhost, החזיקו אימות קוקי או סיסמה פעיל, ואל תסירו אף אחד מהם כדי לפשט סקריפט הפעלה.
קראו את השלב פעם אחת בהפעלה, ואז הירשמו לאירועי התקדמות לתצוגה החיה.
printf 'AUTHENTICATE\r\nGETINFO status/bootstrap-phase\r\nQUIT\r\n' | nc 127.0.0.1 9051
ss -ltn | grep -E '9050|9051'
tor --verify-config -f /etc/tor/torrcתשובה עם התקדמות 100 והתג done פירושה שהתהליך הרקעי סיים את ההפעלה שלו. זה עדיין לא אומר שקיים מעגל שמיש ליעד שלכם.
שלב 3: המתינו לאירוע מעגל של הלקוח
פרוטוקול האירועים של Tor מגדיר את CIRCUIT_ESTABLISHED, שמדווח שלקוח יש מעגל שהוא יכול להשתמש בו. זהו אות המוכנות שהשער של הנשא רוצה, כי הוא קרוב יותר ליכולת שאתם צריכים מאשר אחוז. הירשמו לאירוע ותעדו את המעבר, כך שהיומן יראה מתי הנשא נעשה שמיש ולא מתי התהליך הופיע.
התייחסו לאירוע כאל רשות לנסות, לא כאל הבטחה לגבי יעד מסוים. מדיניות יציאה עדיין יכולה לסרב לעמית המרוחק, והלחיצה של ה-VPN עצמו עדיין יכולה להיכשל מסיבות שאין להן שום קשר ל-Tor.
החזיקו את שני התנאים בנפרד בקוד. ערך בוליאני אחד בשם ready ימזג אותם ויהפוך את התקרית הבאה לבלתי קריאה.
שלב 4: שערו את ה-VPN על הלחיצה שלו עצמו
ל-VPN יש תנאי מוכנות משלו, והוא היחיד שמוכיח שהמנהרה עלתה. המתינו שהלקוח ידווח על מצב מחובר עם כתובת שהוקצתה, ואז בדקו שדרישת הפרוקסי נשארה בתוקף. לולאת ניסיון חוזר שמפילה את אפשרות socks-proxy אחרי כישלון אחד תתחבר ישירות ותביס בשקט את כל העיצוב.
החליטו מה קורה כשהעמית אינו נגיש לפני שאתם צריכים לדעת. ניסיון חוזר מוגבל עם כישלון גלוי קל יותר לתפעול מלולאה אינסופית, והוא נותן למערכת הניטור משהו להתריע עליו. אותה החלטה חלה על הנשא: אם Tor מופעל מחדש, יש לפרק את ה-VPN ולשער אותו מחדש ולא להשאיר אותו פועל על מעגל מת.
לבסוף, החזיקו את המדיניות של היישום עצמו במקום כשהפועל ה-VPN למטה. מפקח שממתין נכון לא עושה דבר כדי למנוע מתהליך לא קשור לשלוח תעבורה ישירות.
בדקו את ארבעת המעברים שעליכם לשרוד
ארבעה מקרים מכסים את העיצוב: הפעלה קרה שבה Tor עולה ראשון, מפקח שמתחבר ל-Tor שכבר מוכן, עמית VPN לא זמין, ואובדן הנשא כשהמנהרה למעלה. לכל אחד מעבר צפוי אחר, וכל אחד מייצר שורת יומן אחרת אם השער נכתב כראוי.
הריצו אותם בכוונה, אחד בכל פעם, וקראו את שינויי המצב ולא את רשימת התהליכים.
journalctl -u tor@default -n 30 --no-pager
systemctl status [email protected]
curl -sS --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ipכשהנשא נופל, ה-VPN צריך לרדת אחריו בתוך מרווח ניסיון חוזר אחד במקום להישאר עם מנהרה מיושנת. כש-Tor חוזר, השער צריך להיפתח מחדש רק אחרי אירוע המעגל, לא אחרי תחילת התהליך. תעדו איזה תנאי היה חסר בכל כישלון, והאדם הבא בתורנות לא יצטרך לשחזר את הסדר מחותמות זמן.