הקמת ממסר Tor על גבי שרת VPS לינוקס

מה עושה ממסר Tor על גבי VPS

ממסר Tor הוא daemon של Tor הפועל על מכונה בעלת כתובת IP ציבורית ומעביר תעבורה מוצפנת עבור משתמשים אחרים. רשויות הספריות (directory authorities) מפרסמות את הממסר, ולקוחות Tor בונים דרכו מעגלים. ממסר מסוג guard או middle מעביר תעבורה אך ורק לממסר אחר, ולכן הוא לעולם אינו פותח חיבור לאתר אינטרנט בשם אדם זר. עובדה יחידה זו היא הסיבה לכך שהוא אינו מושך הודעות על שימוש לרעה (abuse mail), וזו הסיבה לכך שמדובר בתרומה שמתאימה לשרת VPS רגיל. ממסר מעביר תעבורה של אחרים ואינו מפרסם דבר משלו; לכן, אם ברצונכם להציב אתר משלכם ברשת במקום להעביר עבורה חבילות מידע, הרצת שירות onion בתקן v3 מאחורי nginx היא משימה שונה עבור אותו daemon של tor. הרצת ממסר גם אינה תורמת לפרטיות הגלישה שלכם, שהיא בעיה נפרדת בעלת מגבלות נמוכות יותר ממה שרוב האנשים מצפים: מה שאירוח עצמי של SearXNG באמת מסתיר מהווה מדד הוגן למידת ההשפעה של העברת שירות ל-VPS הפרטי שלכם.

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

בחירת תפקיד: Guard, middle, bridge או exit לפני ההתקנה

תהליך daemon יחיד מריץ את כל ארבעת התפקידים. התצורה שלכם, בשילוב עם ה-directory authorities, קובעת איזה תפקיד תמלאו.

• Middle relay. מקבל תעבורה מ-guard ומעביר אותה ל-relay אחר. הוא לעולם אינו יוצר קשר ישיר עם אתר היעד. כל relay חדש מתחיל כאן.
• Guard relay. אותה תצורה, עם דגל (flag) נוסף. ה-directory authorities מעניקים את הדגל Guard ל-relays שהיו מהירים ויציבים מספיק לאורך זמן. אתם לא בוחרים בתפקיד הזה; אתם מרוויחים אותו, והתצורה להלן היא מה שמקנה אותו.
• Bridge. זהו relay שנשמר בכוונה מחוץ ל-directory הציבורי ומופץ באופן פרטי למשתמשים במקומות שבהם Tor חסום. זוהי המחויבות הקטנה ביותר מבין הארבע: רוחב פס נמוך, ללא רישום ציבורי, והצעד הראשון הנכון אם התוכנית שלכם מצומצמת. הוא דורש גם proxy מסוג obfs4 שרץ לצד ה-daemon וקבוצת שורות שונה ב-torrc, אשר הגדרת obfs4 bridge על VPS זול מפרט, כולל האופן שבו המשתמשים מקבלים את שורת ה-bridge בסיום.
• Exit relay. התחנה האחרונה, שפותחת את החיבור לאתר היעד. כל בקשה של משתמש יוצאת מכתובת ה-IP שלכם, לכן דוחות על שימוש לרעה ופניות מהמשטרה יגיעו לבעלי הכתובת הזו.

תפקיד ה-exit אינו מתאים ל-VPS לשימוש כללי. הריצו exit רק אצל ספק שהסכים מראש לקבל דואר כזה, עם כתובת IP ייעודית ואיש קשר מפורסם לדיווח על שימוש לרעה. רוב תנאי השימוש של ספקי אירוח סטנדרטיים אוסרים זאת, והתוצאה הרגילה של התעלמות מכך היא השעיית השרת ואובדן כתובת ה-IP. אם זה בכל זאת התפקיד שאתם מעוניינים בו, מה באמת כרוך בהרצת exit relay מכסה מציאת מארח ידידותי ל-exit, כתיבת מדיניות ה-exit ו-reverse DNS, ומענה לדואר כשהוא מגיע. guard או middle relay מעבירים את אותה תעבורת משתמשים ללא החשיפה הזו.

כל מה שמופיע להלן בונה guard/middle relay. ExitRelay 0 היא השורה ששומרת עליו ככזה.

מה ה-VPS צריך לפני שמתחילים

פרויקט Tor מפרסם דרישות סף מחייבות עבור ממסרים (relays). נכון לאוגוסט 2026, הדרישות הן: כתובת IPv4 ציבורית אחת עבור הממסר, רוחב פס של לפחות 10 Mbit/s בכל כיוון (כאשר 16 Mbit/s מומלצים), לפחות 100 GB של תעבורה יוצאת בחודש, ו-512 MB של RAM עבור מהירות נמוכה מ-40 Mbit/s או 1 GB עבור מהירות גבוהה מכך. אין כלל קשיח לגבי זמן פעילות (uptime), אך ממסר שרץ פחות משעתיים ביום אינו מועיל לרשת.

הנתון של 10 Mbit/s מתייחס לקו התקשורת, לא להגדרות התוכנה. עליך לוודא שהפורט מסוגל להגיע למהירות זו. כמות רוחב הפס שתקצה לממסר היא החלטה נפרדת, שיש לקבל בהתחשב במכסת התעבורה החודשית שלך. קרא את תנאי התוכנית שלך לפני שתשנה את קובץ ה-config. אם אתה עדיין בוחר שרת, כמה VPS באמת עולה בחודש מסביר כיצד נמכרות מכסות תעבורה, ו-מדידת תפוקת הרשת האמיתית של VPS מראה כיצד לבדוק מה הקו באמת מסוגל לעשות באמצעות iperf3 במקום להסתמך על דף המכירות.

בצע הקשחה (hardening) למכונה תחילה. ממסר הוא שירות ציבורי בכתובת ציבורית, והכתובת נסרקת בתוך דקות מרגע פרסומה. הגבלת SSH למפתחות בלבד והקשחת תצורת sshd לוקחת עשר דקות ויש לבצע אותה לפני שהממסר עולה לאוויר, לא אחרי.

התקנת Tor ממאגר ה-Tor Project

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

sudo apt update
sudo apt install -y apt-transport-https gnupg wget

הוסיפו את מפתח החתימה ולאחר מכן את המאגר. שם הקוד (codename) נקרא אוטומטית מהמערכת, כך שאותו בלוק פקודות יעבוד גם ב-Ubuntu 24.04 (noble) וגם ב-Debian 13 (trixie).

wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc \
  | gpg --dearmor \
  | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

CODENAME=$(. /etc/os-release && echo "$VERSION_CODENAME")
echo "$CODENAME"

sudo tee /etc/apt/sources.list.d/tor.sources >/dev/null <<EOF
Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: $CODENAME
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg
EOF

sudo apt update
sudo apt install -y tor deb.torproject.org-keyring
tor --version

tor --version מדפיס את הגרסה שהתקנתם זה עתה. אם apt update הציג שגיאת NO_PUBKEY, סימן שהמפתח המפוענח אינו נמצא בנתיב המצוין בשורת ה-Signed-By:, ולכן ל-apt אין מפתח לאימות קובץ ה-release. חבילת ה-deb.torproject.org-keyring חשובה להמשך: היא מספקת את מפתח החתימה כחבילה רגילה, כך ש-apt ימשיך לעבוד גם כאשר המפתח יוחלף.

הפעילו שדרוגים אוטומטיים, ולאחר מכן הגדירו להם להכיר במקור החדש.

sudo apt install -y unattended-upgrades apt-listchanges

ב-Ubuntu, הוסיפו את מקור ה-Tor לבלוק ה-Allowed-Origins בתוך /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}-security";
        "TorProject:${distro_codename}";
};

ב-Debian, אותו קובץ משתמש ב-Origins-Pattern, שם השורה שיש להוסיף היא "origin=TorProject";. בדקו את התוצאה באמצעות sudo unattended-upgrade --debug --dry-run, פקודה המדפיסה את המקורות שבהם המערכת תטפל מבלי לבצע שינויים.

ה-torrc הקובע

החבילה מתקינה קובץ /etc/tor/torrc ארוך ומלא בהערות. רק מספר שורות בודדות הן בעלות חשיבות עבור ממסר (relay). הוסיפו אותן בסוף הקובץ.

Nickname mynicerelay
ContactInfo relay-ops[at]example.com
ORPort 9001
ExitRelay 0
SocksPort 0

הערך Nickname מורכב מ-1 עד 19 תווים, אותיות וספרות בלבד. הוא אינו ייחודי ברשת ואינו מהווה את הזהות שלכם; ה-fingerprint הוא הזהות האמיתית. זהו השם שבאמצעותו תמצאו את הממסר שלכם בתיבת חיפוש, לכן בחרו שם שתוכלו לאיית בטלפון.

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

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

הערך SocksPort 0 מכבה את ה-SOCKS proxy המקומי, שבו ממסר אינו משתמש, ומסיר socket האזנה אחד מהמכונה. הערך ExitRelay 0 מתעד את הכוונה בקובץ: ממסר זה לעולם לא יתחבר ליעד בשם משתמש, וכל מי שיקרא את התצורה בעתיד לא יצטרך לנחש זאת מתוך הגדרות ברירת המחדל.

אם ל-VPS יש כתובת IPv6, הוסיפו שורת ORPort שנייה. Tor אינו יכול לבצע bind לכל כתובת IPv6 באופן אוטומטי כפי שהוא עושה ב-IPv4, לכן יש לכתוב את הכתובת בתוך סוגריים מרובעים.

ORPort 9001
ORPort [2001:db8::1]:9001

בשרת VPS עם 1 GB זיכרון, הוסיפו את MaxMemInQueues 512 MB. Tor קובע את מגבלת התור שלו לפי הזיכרון שהוא מזהה במכונה, שבשרת וירטואלי קטן הוא יותר ממה שתרצו שהוא יצרוך. הגדרת המגבלה בעצמכם גורמת ל-tor להשליך תאים (cells) בתור תחת עומס – מצב שהממסר שורד – במקום להמשיך לצרוך זיכרון עד שה-kernel יהרוג את התהליך.

פתיחת ה-ORPort ב-firewall

עבור תעבורה נכנסת, ה-ORPort חייב להיות נגיש מכל מקום באינטרנט. עבור תעבורה יוצאת, השאירו את ה-relay ללא הגבלות: הוא פותח חיבורים לאלפי relays אחרים בפורטים רבים ושונים, ורשימת היתרים (allowlist) יוצאת תגרום לו להפסיק לתפקד בשקט.

sudo ufw allow 9001/tcp comment 'tor ORPort'
sudo ufw status verbose

לאחר מכן, בדקו את ה-firewall של ספק התשתית עצמו. לוחות בקרה רבים מריצים מסנן חבילות (packet filter) לפני המכונה הווירטואלית, וחוק שהוספתם באמצעות ufw לא ישפיע שם; כתוצאה מכך, הפורט ייראה פתוח בתוך השרת אך סגור מבחוץ. אם ufw חדש לכם, חוקי ufw שצריכים להיות בכל VPS מסביר את מדיניות ברירת המחדל ואת סדר התאמת החוקים.

התאמת רוחב הפס לתוכנית התעריפים שלכם

המדריך מתאר את RelayBandwidthRate כדלי אסימונים (token bucket) נפרד המגביל "את ממוצע רוחב הפס הנכנס לתעבורה מועברת בצומת זה למספר הבתים לשנייה שצוין, ואת ממוצע רוחב הפס היוצא לאותו ערך". קראו זאת פעמיים. המגבלה חלה על כל כיוון בנפרד. ממסר (relay) המוגדר ל-1 Mbit/s יכול להעביר 1 Mbit/s פנימה ו-1 Mbit/s החוצה בו-זמנית, וספק המודד את שני הכיוונים יחייב אתכם על הסכום.

[
  {
    "label": "1 Mbit/s",
    "torrc_rate": "125 KBytes",
    "gb_per_day": 21.6,
    "gb_per_month": "648"
  },
  {
    "label": "2 Mbit/s",
    "torrc_rate": "250 KBytes",
    "gb_per_day": 43.2,
    "gb_per_month": "1,296"
  },
  {
    "label": "5 Mbit/s",
    "torrc_rate": "625 KBytes",
    "gb_per_day": 108,
    "gb_per_month": "3,240"
  },
  {
    "label": "10 Mbit/s",
    "torrc_rate": "1250 KBytes",
    "gb_per_day": 216,
    "gb_per_month": "6,480"
  },
  {
    "label": "20 Mbit/s",
    "torrc_rate": "2500 KBytes",
    "gb_per_day": 432,
    "gb_per_month": "12,960"
  }
]

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

ב-1 Mbit/s לכל כיוון, ממסר מעביר כ-21.6 GB ביום, כך שחודש של 30 ימים עולה בערך 648 GB של תעבורה מדודה. זה נכנס בתוך מכסה של 1 TB עם מקום פנוי לעדכונים ולגיבויים. עלייה ל-2 Mbit/s הופכת את עלות החודש ל-1,296 GB, מה שכבר חורג מתוכנית של 1 TB. השורה האחרונה, 20 Mbit/s, דורשת 12,960 GB בחודש ושייכת לפורט ללא הגבלת נפח (unmetered). אם הספק שלכם מחייב רק על תעבורה יוצאת, חלקו כל נתון בשניים. בררו מהי מדיניות הספק לפני הגדרת הקצב, כיוון שהתשובות שונות פי שניים.

כעת להגדרות. תחילה הגבלת הקצב (rate limit), לאחר מכן המכסה (quota).

RelayBandwidthRate 125 KBytes
RelayBandwidthBurst 250 KBytes
AccountingMax 400 GBytes
AccountingRule sum
AccountingStart month 1 00:00

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

AccountingRule היא השורה שרוב המפעילים מפספסים. ברירת המחדל היא max, המודדת את הגדול מבין שני הכיוונים מול המכסה. עם ברירת המחדל, AccountingMax 400 GBytes מאפשר 400 GB פנימה ו-400 GB החוצה, שהם 800 GB במד המחשב את שניהם. AccountingRule sum מחשב קריאה פלוס כתיבה מול מכסה אחת, וזה מה שמדידת נפח תעבורה בפועל בודקת.

כתבו גם את AccountingStart, לעולם אל תכתבו את AccountingMax לבדו. המכסה היא המספר, ושורת ההתחלה היא התקופה שבה היא מתאפסת. מכסה ללא תקופה תשאיר את הממסר במצב תרדמת ללא דרך להתעורר.

תרדמת היא כלי גס. כאשר המכסה נגמרת, tor מתעד זאת בלוגים ומפסיק לקבל עבודה:

Bandwidth soft limit reached; commencing hibernation. No new connections will be accepted

הממסר גם לא מתעורר בדיוק בתחילת התקופה הבאה. Tor עוקב אחר המהירות שבה נוצלה המכסה הקודמת ובוחר נקודה אקראית בתוך המרווח החדש, כדי שאלפי ממסרים לא יחזרו לרשת באותה שנייה בדיוק. ממסר שנעלם בשבוע האחרון של כל חודש ממשיך לאבד את היציבות שלפיה רשויות הספריות (directory authorities) מודדות אותו. הגדירו את RelayBandwidthRate כך שהתקרה לעולם לא תושג, ושמרו על AccountingMax כרשת ביטחון המגנה על החשבונית.

הפעלת ה-relay ואימות זמינותו

sudo systemctl restart tor@default
sudo systemctl status tor@default
sudo journalctl -u tor@default -n 50

בתוך דקות ספורות, הלוג אמור להכיל את השורה הבאה:

Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.

משמעות משפט זה היא ש-relays אחרים התחברו ל-ORPort שלכם ובנו דרכו מעגל (circuit). עד ששורה זו מופיעה, ה-relay שלכם אינו מופיע ב-directory ואינו מעביר תעבורה כלל. כשל ייראה כך:

Your server has not managed to confirm reachability for its ORPort(s) at 203.0.113.10:9001. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.

עבדו לפי הסדר הבא. בדקו האם ה-ORPort פתוח ב-ufw. בדקו האם הוא פתוח גם ב-firewall הרשתי החיצוני של ספק התשתית. ודאו שהכתובת בהודעה היא הכתובת שאליה האינטרנט באמת מנתב אליכם, ולא כתובת פרטית מתוך הגדרת NAT. בדקו את הפורט ממכונה אחרת באמצעות nc -vz 203.0.113.10 9001. Tor חוזר על הבדיקה העצמית באופן אוטומטי, כך שתיקון ה-firewall יזוהה ללא התערבותכם, או שתפעילו מחדש את השירות כדי לראות תוצאות מיידיות.

הזהות הקבועה של ה-relay שלכם היא ה-fingerprint שלו:

sudo cat /var/lib/tor/fingerprint

כשלוש שעות לאחר פרסום ה-descriptor, ה-relay יופיע ב-Relay Search. חפשו לפי ה-nickname או הדביקו את ה-fingerprint. דף זה מציג את האופן שבו הרשת תופסת את ה-relay שלכם: אילו flags הוא מחזיק, איזה משקל מעניקות לו ה-authorities, ואיזו גרסה הוא מפרסם.

מדוע ממסר Tor חדש כמעט אינו מעביר תעבורה?

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

בשלושת הימים הראשונים הממסר אינו מדוד. הוא מדווח על תוצאות הבדיקה העצמית שלו, אך רשויות הספריות (directory authorities) מגבילות את המשקל המפורסם ל-20 KB בכל מקרה, ולכן לקוחות כמעט לעולם אינם בוחרים בו. החל מהיום השלישי ועד היום השמיני בערך, רשויות רוחב הפס מודדות אותו בפועל והמשקל שלו עולה, אך הוא משמש רק כצומת אמצעי (middle hop), שכן אף לקוח אינו מוכן להפוך ממסר חדש לחלוטין לצומת הראשון שלו.

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

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

ניטור ה-relay באמצעות nyx

nyx הוא צג הטרמינל עבור relay פעיל. הוא מתקשר עם ה-control port של tor, לכן יש להפעיל אותו תחילה ב-torrc:

ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1

ControlPort מאזין ל-127.0.0.1 בלבד, ואימות מבוסס cookie מחייב תוכנה לקרוא קובץ סודי לפני שהיא יכולה להנפיק פקודות. Tor כותב את ה-cookie ל-/run/tor/control.authcookie כמשתמש debian-tor, במצב 600, כך שאף תהליך אחר לא יכול לקרוא אותו. CookieAuthFileGroupReadable 1 פותח את הגישה לקובץ עבור הקבוצה, מה שמאפשר לחשבון המשתמש שלכם להריץ את nyx ללא sudo.

sudo apt install -y nyx
sudo adduser "$USER" debian-tor
sudo systemctl restart tor@default

התנתקו מהמערכת והתחברו מחדש, ולאחר מכן הריצו את nyx. הקבוצה החדשה חייבת להיקלט בעת ההתחברות, לכן הרצת nyx באותו session של ה-shell תגרום לשגיאת הרשאות בקובץ ה-cookie, גם אם התצורה נכונה. nyx מציג נתונים בזמן אמת על רוחב פס, זמן פעילות (uptime), זרם הלוגים ורשימת החיבורים. בשבועות הראשונים, הנתון שיש לעקוב אחריו הוא גרף רוחב הפס, כדי לוודא שהוא נשאר מתחת ל-RelayBandwidthRate שלכם.

הרצת יותר מ־relay אחד: MyFamily ומפתחות משפחה

אם ברשותך relay יחיד, דלג על סעיף זה. מפעיל המריץ שני relays או יותר חייב להצהיר עליהם זה מול זה, כדי שלקוחות לא יבנו מעגל (circuit) שנכנס ויוצא דרך המכונות שלך; מצב כזה יאפשר למפעיל בודד לראות את שני הקצוות של המעגל.

השיטה הוותיקה היא שימוש ב־MyFamily בכל קובץ torrc של ה־relay, תוך פירוט ה־fingerprints של כל היתר:

MyFamily AAAAAAAAAA,BBBBBBBB

כל relay מפרט את כל האחרים, לכן הוספת relay רביעי מחייבת עריכה של ארבעה קבצים. גרסת Tor 0.4.9 החליפה זאת במפתח משפחה (family key). יש ליצור מפתח אחד ולשתף אותו:

tor --keygen-family myfamily

פעולה זו כותבת את myfamily.secret_family_key ומדפיסה שורת FamilyId. העתק את קובץ המפתח לכל relay, לתוך תת־הספרייה keys שבתוך ה־DataDirectory (בנתיב /var/lib/tor/keys ב־Debian וב־Ubuntu), תוך שמירה על הסיומת .secret_family_key. הוסף את שורת ה־FamilyId המודפסת לכל קובץ torrc ובצע טעינה מחדש באמצעות sudo systemctl reload tor@default. השאר את רשימת ה־MyFamily במקומה לעת עתה. לקוחות שעדיין אינם תומכים בתעודות משפחה ימשיכו לקרוא את הרשימה הישנה, ופרויקט Tor יודיע מתי ניתן יהיה להסיר אותה.

מה משתבש לאחר שהשירות פועל

הגרסה מתיישנת. עדכונים אוטומטיים מחליפים את החבילה, אך התהליך הפעיל ממשיך להשתמש בקובץ ה-binary שבו הוא התחיל עד לביצוע אתחול. השוו את tor --version בשרת לגרסה המוצגת בדף ה-Relay Search של ה-relay. אם הן שונות, הרשת עדיין רואה את הגרסה הישנה, לכן יש לבצע restart לשירות.

השעון מאבד סנכרון. מסמכי ה-consensus והתעודות מוגבלים בזמן, לכן מכונה שהשעון שלה אינו מדויק תדחה את ה-consensus ותפסיק לפרסם נתונים. timedatectl אמור להציג את שעון המערכת כמסונכרן. אם לא, הפעילו את systemd-timesyncd או התקינו את chrony.

כתובת ה-IP משתנה. ה-descriptor נושא את הכתובת, ולקוחות לא יכולים להגיע לכתובת שהשתנתה. לאחר כל מעבר ספק או שינוי כתובת, בצעו restart ל-tor ועקבו אחר שורת ה-self-test שוב.

ה-relay איטי מהמתוכנן. ההצפנה של Tor יעילה על מעבדים מודרניים, וה-Tor Project מעריך מעבד עם תמיכה ב-AES-NI בכ-400 עד 450 Mbit/s לכל כיוון. הרבה לפני הגעה לתקרה זו, אתם תוגבלו על ידי מהירות הפורט ומכסת התעבורה, וזו הסיבה שסעיף ה-accounting לעיל חשוב יותר מהחומרה.

FAQ

כמה רוחב פס צורך ממסר Tor?

כמה שתקצה לו, ולא יותר. RelayBandwidthRate מגביל את התעבורה המועברת בכל כיוון בנפרד, כך שממסר שמוגדר ל-1 Mbit/s יכול להעביר 1 Mbit/s פנימה ו-1 Mbit/s החוצה בו-זמנית. זה מסתכם בכ-21.6 GB ביום, או 648 GB בחודש של 30 יום, בחישוב שני הכיוונים. ניתן להוסיף את AccountingMax עם AccountingRule sum כמכסה חודשית קשיחה מתחת לקצב זה.

האם הרצת ממסר Tor תגרור תלונות על שימוש לרעה?

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

מדוע ממסר ה-Tor החדש שלי לא מקבל תעבורה?

ממסרים חדשים מוגבלים בתכנון עד שהם נמדדים. בשלושת הימים הראשונים, רשויות הספריות (directory authorities) מגבילות את המשקל המפורסם ל-20 KB, ולכן לקוחות כמעט לעולם לא בוחרים בממסר זה. רשויות רוחב הפס מודדות אותו החל מהיום השלישי בערך, הוא הופך לזכאי ל-Guard flag סביב היום השמיני, והתעבורה יורדת שוב בנקודה זו כיוון שלקוחות נמנעים מ-guards בעת בחירת צמתי ביניים. עומס מלא מגיע סביב יום 68. ודא שהלוג מציג "Self-testing indicates your ORPort is reachable from the outside", ולאחר מכן הניחו לו.

האם ניתן להריץ ממסר Tor על VPS עם מכסת תעבורה של 1 TB?

כן, בקצב של כ-1 Mbit/s בכל כיוון, שזה RelayBandwidthRate 125 KBytes. זה מסתכם בכ-648 GB בחודש אם הספק שלך מודד את שני הכיוונים, מה שמשאיר מרווח לעדכונים ולגיבויים. הוסף את AccountingMax 400 GBytes עם AccountingRule sum ו-AccountingStart month 1 00:00 כדי שהממסר יעבור למצב שינה במקום לחרוג מהתוכנית. אם הספק מחייב רק על תעבורה יוצאת, ניתן להכפיל את הקצב.

האם עלי להגדיר MyFamily אם אני מריץ רק ממסר אחד?

לא. הצהרות משפחה (family declarations) קיימות כדי שלקוחות יימנעו מבניית מעגל דרך שני ממסרים בבעלות אותו מפעיל, דבר שאין לו משמעות עם ממסר אחד. הגדר זאת ברגע שתוסיף ממסר שני: רשום את ה-fingerprint של כל ממסר בשורת ה-MyFamily של כל ממסר, או השתמש במפתח ה-family שהוצג ב-Tor 0.4.9, שמפיץ FamilyId אחד במקום רשימה שגדלה ללא הרף.