איך להריץ ממסר Tor על שרת VPS: מדריך הגדרה מלא

מה עושה ממסר Tor על שרת VPS

ממסר Tor הוא daemon של Tor הפועל על מכונה בעלת כתובת IP ציבורית ומעביר תעבורה מוצפנת עבור משתמשים אחרים. רשויות הספריות (directory authorities) מפרסמות את הממסר, ולקוחות Tor בונים דרכו מעגלים. ממסר מסוג guard או middle מעביר תעבורה אך ורק לממסר אחר, ולכן הוא לעולם אינו פותח חיבור לאתר אינטרנט בשם אדם זר. עובדה יחידה זו היא הסיבה לכך שהוא אינו מושך הודעות על שימוש לרעה (abuse mail), וזו הסיבה שמדובר בתרומה שמתאימה לשרת 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 חסום. זוהי ההתחייבות הקטנה ביותר מבין הארבע: רוחב פס נמוך, ללא רישום ציבורי, והצעד הראשון הנכון אם התוכנית שלכם מצומצמת.
• Exit relay. התחנה האחרונה, שפותחת את החיבור לאתר היעד. כל בקשה שמשתמש מבצע יוצאת מכתובת ה-IP שלכם, לכן דיווחי שימוש לרעה ופניות מהמשטרה יגיעו לבעלי הכתובת הזו.

תפקיד ה-exit הוא היחיד שאינו מתאים ל-VPS לשימוש כללי. הריצו exit רק אצל ספק שהסכים מראש לקבל דואר כזה, עם כתובת IP ייעודית ואיש קשר מפורסם לדיווח על שימוש לרעה. רוב תנאי השימוש של ספקי אירוח סטנדרטיים אוסרים זאת, והתוצאה הרגילה של התעלמות מכך היא השעיית השרת ואובדן כתובת ה-IP. לעומת זאת, 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 יזוהה ללא התערבותכם, אך ביצוע restart יזרז את התהליך.

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

sudo cat /var/lib/tor/fingerprint

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

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

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

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

סביב היום השמיני הממסר הופך לזכאי לדגל Guard. קבלת הדגל גורמת לירידה בתעבורה, דבר שמפתיע רבים: לקוחות מדלגים על שומרי סף (guards) בעת בחירת צומת אמצעי, מתוך הנחה ששומר סף כבר עמוס, ולכן הממסר מאבד תעבורת אמצע לפני שהוא צובר תעבורת שומר סף. התעבורה מתמלאת מחדש רק ככל שלקוחות מחליפים את קבוצות שומרי הסף שלהם, תהליך שלוקח שבועות. בערך ביום ה-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 באותו shell session תגרום לשגיאת הרשאות בקובץ ה-cookie, גם אם התצורה נכונה. nyx מציג רוחב פס בזמן אמת, זמן פעילות (uptime), את זרם הלוגים ואת רשימת החיבורים. בשבועות הראשונים, הנתון שיש לעקוב אחריו הוא גרף רוחב הפס, כדי לוודא שהוא נשאר מתחת ל-RelayBandwidthRate שלכם.

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

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

הדרך הוותיקה לעשות זאת היא באמצעות MyFamily בכל קובץ torrc של ה-relay, תוך פירוט ה-fingerprints של כל ה-relays האחרים:

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 Project יודיעו מתי ניתן יהיה להסיר אותה.

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

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

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

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

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

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 reputation, כיוון שהכתובת מפורסמת ברבים כממסר. ממסרי 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) קיימות כדי שלקוחות יימנעו מבניית מעגל דרך שני ממסרים בבעלות אותו מפעיל, מה שחסר משמעות בממסר בודד. הגדר זאת ברגע שתוסיף ממסר שני: רשום את ה-fingerprint של כל ממסר בשורת ה-MyFamily של כל ממסר, או השתמש ב-family key שהוצג ב-Tor 0.4.9, שמפיץ FamilyId אחד במקום רשימה שגדלה ללא הרף.