הקמת גשר Tor עם obfs4 על שרת VPS: מדריך מעשי

מהו גשר Tor ומדוע הוא קיים

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

כתובת שאינה רשומה היא רק חצי מהפתרון. טכנולוגיית Deep packet inspection (DPI), המסווגת תעבורה לפי התוכן שלה ולא לפי הכתובת, מזהה חיבור Tor לפי המבנה של ה-handshake של ה-TLS (transport layer security). גורם מצנזר ללא רשימה עדיין יכול לזהות ש"זה נראה כמו Tor" ולנתק את החיבור. רכיב מסוג pluggable transport מסיר את האות הזה. הוא עוטף את זרם ה-Tor במשהו אחר בצד הלקוח, והגשר שלך מסיר את העטיפה.

obfs4 הוא ה-transport שרוב הגשרים מריצים. הוא הופך את הזרם לבתים ללא header וללא handshake קבוע, כך של-DPI אין תבנית להתאים אליה. הוא גם מאמת את הלקוח. הערך cert= בתוך שורת הגשר הוא מפתח שהלקוח חייב להוכיח שהוא מחזיק בו לפני שהגשר מגיב בכלל, מה שמסכל active probing: גורם מצנזר שמתחבר לכתובת שלך כדי לבדוק אם היא מדברת Tor לא מקבל תשובה ולא לומד דבר.

באיזה Pluggable Transport כדאי להשתמש?

• obfs4 דורש שרת VPS אחד, שני פורטים מסוג TCP, ואינו דורש שם מתחם. זו האפשרות השימושית הקלה ביותר להפעלה, והיא נושא המדריך הזה.
• WebTunnel מסתיר את החיבור בתוך תעבורת HTTPS רגילה לאתר אינטרנט אמיתי. פרויקט Tor מגדיר את הדרישות עבורו ככתובת IPv4 סטטית, שם מתחם שבשליטתך, שרת אינטרנט פעיל כגון NGINX או Apache, תעודת TLS תקפה, ולפחות 1 GB של RAM (מומלץ 4 GB). הוא מתאים לרשתות שבהן תעבורה שנראית אקראית היא חשודה כשלעצמה, שכן מדינה שמתירה רק גלישה באינטרנט עדיין מאפשרת HTTPS.
• Snowflake הוא סוג אחר של תרומה. מתנדבים מפעילים proxies מסוג WebRTC בעלי אורך חיים קצר, כך שנקודות הכניסה משתנות ללא הרף ולא קיימת כתובת יציבה שצנזור יכול לחסום. אינך מפעיל bridge עבורו. אתה מפעיל proxy, והוא אינו זקוק לכתובת קבועה.

התחל עם obfs4. תוכל להוסיף bridge מסוג WebTunnel מאוחר יותר, בכתובת שנייה: הפעלת שניהם על אותה כתובת IP משמעותה שחסימת כתובת אחת תנטרל את שניהם.

מה העלות של הפעלת bridge?

[
  {
    "label": "Bridge, minimum",
    "min_upstream_mbit": 1
  },
  {
    "label": "Guard or middle relay, minimum",
    "min_upstream_mbit": 10
  },
  {
    "label": "Guard or middle relay, recommended",
    "min_upstream_mbit": 16
  }
]

נכון לאוגוסט 2026, פרויקט Tor מבקש עבור bridge רוחב פס של לפחות 1 Mbit/s ב-upstream וב-downstream. עבור guard או middle relay, הדרישה היא 10 Mbit/s, כאשר 16 Mbit/s היא המהירות המומלצת. אלו דרישות מפורסמות, לא מדידות בפועל. bridge חדש לרוב נשאר הרחק מתחת למינימום שלו במשך שבועות. אותו דף דרישות מבקש עבור relay לפחות 100 GByte של תעבורה יוצאת בחודש, כמות שחבילות ה-VPS הקטנות ביותר כבר מכסות, לכן כדאי לקרוא על העלות האמיתית של VPS קטן לחודש לפני שבוחרים בשרת גדול יותר.

שטח הפנים לניצול לרעה (abuse) הוא קטן, וזהו החלק שאנשים טועים לגביו. bridge הוא הדילוג ה-ראשון. תעבורה שיוצאת מהשרת שלך עוברת ל-relay אחר של Tor, לעולם לא לאתר אינטרנט שמשתמש בחר. כתובת ה-IP שלך לעולם לא תופיע ב-log של אתר אינטרנט ככתובת המקור של הבקשה, לכן הודעות תלונה שמפעילי exit relay מקבלים לא יגיעו לכאן. בכל מקרה, בדקו את מדיניות השימוש המקובל (AUP) של ספק השרתים שלכם, כיוון שחלק מהספקים מתייחסים לכל שירות Tor כאל מקרה מיוחד. bridge ו-onion service הם תמונות מראה בהקשר זה: bridge שימושי רק משום שכתובתו נגישה ובסופו של דבר מופצת, בעוד ש-v3 onion service על אותו סוג של VPS שימושי רק כל עוד ה-IP הציבורי שלכם נשאר מוסתר.

דבר אחד שאסור לעשות: להפוך relay ציבורי קיים ל-bridge באותה כתובת. העצה של פרויקט Tor למקרה כזה היא לשנות את "כתובת ה-IP, השם וה-fingerprint", כיוון שהכתובת הישנה כבר נמצאת ב-consensus שגופים מצנזרים מורידים. bridge שהיה relay ציבורי בשבוע שעבר הוא bridge שכבר נמצא ברשימת חסימות.

זמינות (uptime) חשובה יותר ממהירות. דרישות ה-relay מציינות כי "אם ה-relay שלכם לא פעיל יותר מ-2 שעות ביום, התועלת שלו מוגבלת", ובמקרה של bridge המצב גרוע אף יותר, כיוון שלכל לקוח יש כתובת אחת ללא חלופה. אתחול מנתק את כל המשתמשים המחוברים אליו. הגדירו בדיקת פורט TCP ב-Uptime Kuma מול פורט ה-obfs4 כדי שתדעו ביום שבו הוא מפסיק להגיב.

התקנת Tor ממאגר הבית של Tor Project

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

sudo apt update
sudo apt install -y apt-transport-https gnupg wget lsb-release
wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

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

sudo tee /etc/apt/sources.list.d/tor.sources >/dev/null <<EOF
Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: $(lsb_release -cs)
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 obfs4proxy

אם apt update מדווח שלמאגר אין קובץ Release עבור שם הקוד שלכם, סימן ש-Tor Project אינו תומך בגרסה זו. מחקו את /etc/apt/sources.list.d/tor.sources, הריצו שוב את sudo apt update, והתקינו את חבילת ה-tor שמסופקת על ידי ההפצה שלכם. כל השלבים להלן זהים.

החבילה obfs4proxy מגיעה ישירות מ-Debian ומ-Ubuntu (גרסה 0.0.14 ב-Debian 13, נכון לאוגוסט 2026). ודאו היכן הותקן הקובץ הבינארי, שכן הנתיב שלו נדרש בקובץ התצורה:

command -v obfs4proxy || command -v lyrebird

הפרויקט שינה את שמו ל-lyrebird, לכן ייתכן שחבילה חדשה יותר תתקין את /usr/bin/lyrebird במקום. השתמשו בנתיב שמוחזר מהפקודה.

הגדרת ה-bridge בקובץ /etc/tor/torrc

BridgeRelay 1
ORPort 8443
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ServerTransportListenAddr obfs4 0.0.0.0:9443
ExtORPort auto
ContactInfo you@example.com
Nickname PickANickname
BridgeDistribution any

לכל אחת מהשורות הללו עלול להתווסף כשל, לכן יש לטפל בהן אחת אחת.

BridgeRelay 1 מורה ל-tor לשלוח את ה-descriptor שלו לרשות ה-bridge במקום לקונסנזוס הציבורי. שורה בודדת זו היא שהופכת את ה-relay ללא רשום.

ORPort הוא פורט ה-Tor האמיתי. עליו להיות נגיש מהאינטרנט, כיוון ש-tor בודק אותו ומסרב לפרסם descriptor עד שהבדיקה עוברת בהצלחה.

ServerTransportPlugin נותן ל-tor את הפקודה להרצה. tor מפעיל את obfs4proxy כתהליך בן ומתקשר איתו דרך pipe, לכן ל-obfs4proxy אין יחידת שירות משלו והוא לעולם לא יופיע ב-systemctl status.

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

ExtORPort auto פותח את ה-ORPort המורחב, ערוץ loopback ש-obfs4proxy משתמש בו כדי להעביר חיבורים שהושלמו חזרה ל-tor יחד עם כתובת הלקוח. מדריך ההתקנה של Tor Project כולל אותו בכל bridge, כיוון שבלעדיו ה-transport לא יכול לדווח על כתובת זו ל-tor.

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

BridgeDistribution בוחר איזה מפיץ ייתן את הכתובת שלכם למשתמשים. הערכים המקובלים הם https, email, telegram, settings, none ו-any. השתמשו ב-any עבור bridge ראשון ותנו למערכת להחליט. השתמשו ב-none עבור bridge פרטי שאתם מחלקים בעצמכם, מה ששומר על הכתובת מחוץ להפצה ציבורית לחלוטין.

מדוע בחירת הפורט חשובה

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

הפורט העדיף ביותר עבור obfs4 הוא 443. תעבורה יוצאת בפורט 443 פתוחה כמעט בכל רשת מוגבלת, וחיבור ארוך טווח אליו נראה כסשן גלישה רגיל. האזנה בפורט הנמוך מ-1024 דורשת צעד נוסף, כיוון ש-obfs4proxy אינו רץ כ-root:

sudo setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy
sudo systemctl edit tor@.service tor@default.service

הוסיפו את שתי השורות הבאות בכל עורך שנפתח:

[Service]
NoNewPrivileges=no

היכולת (capability) כשלעצמה אינה מספיקה. ההגדרה NoNewPrivileges ב-systemd מונעת מתהליך להשיג הרשאות שלא היו להורה שלו, ו-file capability הוא בדיוק זה; לכן, obfs4proxy נכשל בביצוע bind לפורט 443 כל עוד הגדרה זו פעילה.

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

פתיחת הפורטים בשתי חומות האש

sudo ufw allow 8443/tcp
sudo ufw allow 9443/tcp
sudo ufw status

יש לפתוח את שני הפורטים. רוב ספקי הענן מפעילים חומת אש נוספת בלוח הבקרה שלהם, ש־ufw אינו מודע לקיומה. חוק שקיים בשרת אך לא בלוח הבקרה יוצר גשר שאינו נגיש לעולם ושאינו מפרסם descriptor. אם אחד מהנושאים הללו חדש עבורך, חוקי ufw הנדרשים לשרת VPS חדש ו-מהו פורט מאזין בפועל בלינוקס מסבירים זאת. בזמן שאתה שם, אבטח את SSH באמצעות מפתחות והגדרות sshd מוקשחות. גשר שאינו רשום בשרת שמאפשר התחברות בסיסמא ל-SSH הוא עדיין שרת שמאפשר התחברות בסיסמא ל-SSH.

הפעלת השירות וקריאת הלוג

sudo systemctl enable --now tor.service
sudo systemctl restart tor.service
sudo journalctl -e -u tor@default

במערכות Debian ו-Ubuntu קיימות שתי יחידות (units). הקובץ tor.service הוא מעטפת (wrapper) קטנה, בעוד tor@default.service הוא התהליך שמבצע את העבודה בפועל. זו הסיבה ש-journalctl -u tor נראה כמעט ריק, בעוד הלוג שאתם מחפשים נמצא תחת tor@default.

שתי שורות מעידות על פעולה תקינה:

Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Registered server transport 'obfs4' at '0.0.0.0:9443'

השורה הראשונה מציינת שבדיקת הנגישות עברה בהצלחה ושהמתאר (descriptor) נשלח לרשות הגישור (bridge authority). אם שורה זו לא מופיעה, ייתכן שרכיב כלשהו בין האינטרנט לשרת שלכם חוסם את התעבורה ל-ORPort. השורה השנייה חייבת להציג את הפורט שהגדרתם. אם מופיע פורט אחר, סימן ש-tor לא החיל את ServerTransportListenAddr; הסיבה הנפוצה לכך היא חוסר התאמה בשם ה-transport: עליו להיות זהה ל-obfs4 בשתי ההנחיות.

וודאו ששני המאזינים (listeners) קיימים:

sudo ss -lntp | grep -E 'tor|obfs4|lyrebird'

איפה נמצאת שורת ה-bridge שלי?

התוכנה obfs4proxy כותבת תבנית לתוך ספריית הנתונים של tor:

sudo cat /var/lib/tor/pt_state/obfs4_bridgeline.txt

ספרייה זו שייכת למשתמש tor וההרשאות שלה הן 700, לכן ללא sudo תקבלו Permission denied. הקובץ מכיל שורה במבנה הבא:

Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=<CERTIFICATE> iat-mode=0

החליפו את <IP ADDRESS> בכתובת הציבורית של השרת שלכם, את <PORT> בפורט של obfs4 (ולא ב-ORPort), ואת <FINGERPRINT> ב-identity fingerprint ש-tor כתב לתוך ספריית הנתונים שלו:

sudo cat /var/lib/tor/fingerprint
sudo cat /var/lib/tor/hashed-fingerprint

הקובץ הראשון מכיל את הכינוי שלכם ואת ה-identity fingerprint שצריך להופיע בשורת ה-bridge. הקובץ השני מכיל את ה-hashed fingerprint, וזה הערך שיש להדביק ב-Relay Search כדי לבדוק אם ה-bridge שלכם פעיל וכמה לקוחות בערך מגיעים אליו. שני הערכים אינם ניתנים להחלפה. שורת bridge שמכילה את הערך המקודד (hashed) לא תואמת למפתח ה-identity שה-bridge שלכם מציג, ולכן הלקוח ידחה את החיבור שהוא פתח.

כיצד גשר (bridge) מגיע בפועל למשתמשים?

אין צורך להעביר את שורת ה-bridge לאף אחד באופן ידני. ברגע שה-descriptor מגיע ל-bridge authority, מערכת ההפצה (rdsys, היורשת של BridgeDB) מקצה את ה-bridge שלך למפיץ אחד, ומשתמשים פונים לאותו מפיץ כדי לקבל גשרים. נכון לאוגוסט 2026, אלו הם ערוצי ההפצה:

• טופס האינטרנט בכתובת bridges.torproject.org/options, המספק שורות bridge לאחר פתרון captcha.
• שליחת דוא"ל לכתובת bridges@torproject.org מכתובת Gmail או Riseup, המשיבה עם שורות bridge. ההגבלה על ספקי הדוא"ל קיימת כיוון שחשבונות חינמיים ללא הגבלה היו מאפשרים לצנזור למפות את כל הגשרים.
• הבוט ב-Telegram בשם @GetBridgesBot. יש לשלוח /start, ולאחר מכן /obfs4 או /webtunnel.
• Tor Browser עצמו, תחת Settings ולאחר מכן Connection, שם האפשרות "Request bridges" מושכת אותם דרך ערוץ ה-moat.

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

הגדרה של BridgeDistribution none מבטלת את ההשתתפות בכל ערוצי ההפצה הללו. במקרה כזה, שורת ה-bridge נשארת אצלך כדי שתעביר אותה לאנשים הזקוקים לה, דרך ערוץ תקשורת שהצנזור אינו מנטר.

כאשר משהו אינו עובד

אין שורת בדיקה עצמית בלוג. ה-ORPort אינו נגיש. בצעו בדיקה ממכונה אחרת באמצעות nc -vz your.ip 8443. השהיה (hang) מעידה על כך שחבילות נחסמות, לכן בדקו את ufw ואת לוח הבקרה של ספק השרת. סירוב (refusal) מעיד על כך ש-tor אינו מאזין, לכן בדקו את ss -lntp וקראו את הלוג לאיתור שגיאת תצורה.

ה-transport הרשום מציג פורט שלא בחרתם. tor התעלם מ-ServerTransportListenAddr. שם ה-transport חייב להתאים בדיוק לשם המופיע ב-ServerTransportPlugin, ושניהם חייבים להיות obfs4.

obfs4proxy אינו מצליח לבצע bind לפורט 443. אשרו את היכולת (capability) באמצעות getcap /usr/bin/obfs4proxy, ולאחר מכן ודאו שה-override הגיע ליחידה באמצעות systemctl show tor@default -p NoNewPrivileges. אם הפלט הוא NoNewPrivileges=yes, ה-drop-in הוחל על יחידה שאינה רצה.

אין תוכן בתוך /var/lib/tor/pt_state/. tor לא הפעיל את ה-transport, מה שאומר שהנתיב ב-ServerTransportPlugin שגוי. השוו אותו לפלט של command -v obfs4proxy.

לקוחות הפסיקו להתחבר לאחר שינוי. כל שינוי בכתובת או בפורט ה-obfs4 מבטל את כל שורות ה-bridge שכבר הופצו. בדקו האם גם ה-IP הציבורי של השרת השתנה, דבר שקורה לעיתים בבנייה מחדש (rebuild) אצל ספקים מסוימים.

tor אינו עולה כלל. הריצו את sudo -u debian-tor tor --verify-config -f /etc/tor/torrc. הפקודה מנתחת את הקובץ, מדפיסה את השורה שגורמת להתנגדות, ואינה משפיעה על השירות שרץ כרגע.

FAQ

האם ספק ה-VPS שלי יתלונן על גשר Tor?

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

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

המינימום המפורסם הוא 1 Mbit/s להעלאה ולהורדה, לעומת 10 Mbit/s עבור guard או middle relay. השימוש בפועל מתחיל קרוב לאפס, כיוון שהגשר שלך מעביר תעבורה רק עבור המשתמשים שהמפיץ שולח אליו. אם ברצונך להגדיר תקרה קשיחה, הגדר את RelayBandwidthRate ו-RelayBandwidthBurst בקובץ torrc.

מדוע אף אחד לא התחבר לגשר החדש שלי?

לוקח לגשר כשלוש שעות להופיע ב-Relay Search, וההנחיה של Tor Project היא שביסוס קבוצת משתמשים עקבית לוקח כמה ימים או שבועות. בדוק שה-descriptor פורסם, כלומר שורת ה-self-testing ב-journalctl -u tor@default, חפש את ה-fingerprint המקודד שלך ב-Relay Search, וודא ש-BridgeDistribution אינו מוגדר כ-none.

האם עליי להריץ obfs4 או WebTunnel?

הרץ obfs4 אם זהו הגשר הראשון שלך: VPS אחד, שני פורטים, ללא דומיין וללא תעודה. הרץ WebTunnel במקומות שבהם תעבורה שנראית אקראית נחסמת בעצמה, כיוון שזה דורש דומיין שבשליטתך, שרת אינטרנט אמיתי, תעודת TLS תקפה, ולפחות 1 GB של RAM. אם אתה מריץ את שניהם, שים אותם על כתובות שונות, כיוון שחסימת IP אחד תסיר שני גשרים בבת אחת.

מה קורה אם אשנה את פורט ה-obfs4 מאוחר יותר?

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