VPN אל תוך Tor, Tor אל תוך VPN: למה השרשרת נשברת
כשמניחים VPN, Tor ופרוקסי זה על גבי זה, הסדר קובע מה ייפתר ומה יישא. מצאו את הגבול השבור הראשון לפני שמשנים את שלושתם.
הערמה של VPN, Tor ופרוקסי של יישום מרגישה כמו הכפלה של הפרטיות, ולמעשה היא מכפילה את מספר המקומות שבהם חיבור יכול למות. התוצאה הרגילה היא דפדפן שמסתובב בזמן שכל שלושת הכלים מדווחים שהם בריאים. שינוי כל שלוש ההגדרות בבת אחת מוחק אז את הרמז היחיד שהיה לכם לגבי מי מהם משקר.
שרטטו תחילה את המסלול המבוקש לפי הסדר, ותנו שם לתוכנית שפותחת כל חיבור ולאיזה שם נפתר בכל שלב.
שכבות אינן מצטברות, הן משפיעות זו על זו
VPN לפני Tor פירושו ש חיבור הכניסה של לקוח Tor עובר בתוך המנהרה. VPN שנישא דרך Tor פירושו שנקודת הקצה של לקוח ה-VPN עצמו חייבת להיות נגישה דרך Tor, וזו דרישה שונה לגמרי. הפרוקסי של הדפדפן מוסיף קפיצה נוספת שמערכת ההפעלה לא יודעת עליה דבר. שלושה סידורים, שלוש רשימות תלות נפרדות.
כל סידור משנה מה ניתן לפתור, מה ניתן לשאת, ומי רואה את החבילה הראשונה. רק אחד מהם יכול להיות התצורה שהתכוונתם אליה.
הוסיפו לתרשים גם את המסלול הישיר. מסלול גיבוי, חריגה של מנהרה מפוצלת או עקיפת פרוקסי יכולים לגרום לעמוד להיטען תוך דילוג שקט על השרשרת שרציתם לבדוק, והצלחה כזו מטעה יותר מהכשל.
הסדר קובע מה ניתן לשאת
Tor נושא זרמי TCP דרך ממשק ה-SOCKS שלו, ולקוח שמבקש מהפרוקסי לפתור את שם המארח משאיר את החיפוש בתוך המעגל. UDP אינו עובר כך בתצורות רגילות, ולכן לא ניתן לקנן מנהרת WireGuard בתוך Tor בלי ממסר TCP נוסף באמצע.
OpenVPN ניתן לכפות על TCP, כך שהסידור הזה לפחות ניתן לתיאור. הוא גם איטי יותר ושברירי יותר, ואופן הכשל כשנשבר נראה כמו פורט חסום. צפו לבלות יותר זמן בהבחנה בין השניים מאשר בתיקון מי מהם.
הפתרון הוא החצי השני. עם --socks5-hostname הפרוקסי פותר את היעד, בעוד --socks5 הפשוט שואל תחילה את הפותר המקומי ומדליף את השם אל מחוץ למעגל. בדיוק הדגל האחד הזה קובע אם חיפוש השם שייך לשרשרת או לספק האינטרנט שלכם.
| Order | What must resolve the endpoint | What usually breaks |
|---|---|---|
| VPN, then Tor | The tunnel's resolver | Entry guards blocked by the VPN provider's filters |
| Tor, then VPN | The SOCKS proxy, remotely | UDP transports, which Tor does not carry |
| App proxy on top | The application itself | Proxy bypass rules and cached connections |
איתור הגבול השבור הראשון
בדקו את השלבים לפי סדר מעבר החבילות, בבקשות בלתי מזיקות, ועצרו בראשון שנכשל. רשמו איזו פקודה רצה ראשונה, כי הסדר הוא חלק מהראיות. שתי פקודות מפרידות בין מעגל מת ליציאה מתה:
curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip curl -4 -s https://api.ipify.org; echo
הראשונה מדווחת אם בקשה בכלל מושלמת דרך פרוקסי SOCKS, והשנייה מציגה את הכתובת שהרשת מציגה כרגע. אם הראשונה נכשלת והשנייה מצליחה, הבעיה אצל לקוח Tor או לפניו. אם שתיהן מצליחות והדפדפן עדיין נכשל, היישום משתמש במסלול אחר מזה של המעטפת.
גם עמוד IP ציבורי מתאר רק את היציאה הנראית האחרונה. הוא לא יכול לומר כמה קפיצות קדמו לה, לכן חברו אותו לפלט המצב הנתמך של כל כלי במקום להתייחס למספר בודד כתרשים.
מתי להפסיק להוסיף שכבות
אם אינכם יכולים לומר במשפט אחד מה שכבה תורמת, הסירו אותה. שרשרת שמטרתה אינה ברורה היא שרשרת שאיש לא יכול לנפות בה תקלות בשלוש לפנות בוקר, והרווח בפרטיות מקפיצה לא מוסברת בדרך כלל קטן מהזמינות שאתם מאבדים.
אם שכבה אכן ראויה למקומה, בדקו אותה לבדה תחילה, אחר כך הוסיפו את הבאה ואשרו שוב את המסלול עם אותן שתי פקודות. שחזרו את השרשרת המלאה לפני שימוש רגיל, והשאירו את אימות TLS והאימות מופעלים; אזהרת תעודה שמתקבלת כדי שעמוד ייטען היא עקיפת ניתוב, לא תיקון. רשמו את הסדר שקבעתם בזמן שהוא טרי.
רשמו את הסדר הזה, כולל הפותר שעונה בכל שלב. שרשרת עובדת שאתם יכולים לתאר שורדת את העדכון הבא, בעוד שרשרת עובדת שהרכבתם בניסוי וטעייה נעלמת איתו. הוסיפו את התאריך ואת הגרסאות, כדי שכשל מאוחר יותר יושווה למצב ידוע כטוב במקום להתווכח עליו מהזיכרון. עשר שורות בקובץ טקסט חוסכות ערב של ניחושים.