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

מהו Tor bridge ומדוע הוא קיים

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

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

obfs4 הוא ה-transport הנפוץ ביותר בקרב bridges. הוא הופך את זרם הנתונים לרצף בתים ללא header וללא handshake קבוע, כך של-DPI אין תבנית לזיהוי. הוא גם מבצע אימות ללקוח. הערך cert= בתוך שורת ה-bridge הוא מפתח שהלקוח חייב להוכיח שהוא מחזיק בו לפני שה-bridge יגיב בכלל. הדבר מונע 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. תוכל להוסיף גשר 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 קטן לפני שתבחרו בשרת גדול יותר.

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

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

זמינות (uptime) חשובה יותר ממהירות. דרישות ה-relay מציינות כי "אם ה-relay שלכם אינו פועל יותר מ-2 שעות ביום, התועלת שלו מוגבלת". מצבו של bridge גרוע עוד יותר מ-relay, כיוון שלכל לקוח יש כתובת אחת ללא חלופה. הפעלה מחדש מנתקת את כל המשתמשים המחוברים אליו. הגדירו בדיקת פורט 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 authority במקום ל-consensus הציבורי. שורה בודדת זו היא שהופכת את ה-relay ללא רשום.

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

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

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

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

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

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

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

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

הפורט העדיף ביותר עבור obfs4 הוא 443. תעבורה יוצאת בפורט 443 פתוחה כמעט בכל רשת מוגבלת, וחיבור ארוך טווח אליו נראה כסשן גלישה רגיל. קישור (binding) לפורט הנמוך מ-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 ייכשל בקישור לפורט 443 כל עוד הגדרה זו פעילה.

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

פתיחת הפורטים בשני ה-firewalls

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

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

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

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

הפצות Debian ו-Ubuntu מספקות שתי יחידות. 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'

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

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

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 key שה-bridge שלכם מציג, ולכן הלקוח ידחה את החיבור שזה עתה פתח.

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

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

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

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

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

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

אין שורת בדיקה עצמית בלוג. ה-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, חפש את ה-hashed fingerprint שלך ב-Relay Search, וודא ש-BridgeDistribution אינו מוגדר כ-none.

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

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

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

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