האם HTTP מעל ZeroTier מוצפן? בדקו היכן נגמרת שכבת הכיסוי

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

בדיקה 1: מצאו את הכתובת שהדפדפן מחייג אליה

השוו את ה-URL למה שלמכונה באמת יש. ip -brief addr show מציג את ממשק zt ואת כתובת הכיסוי שהקצה בקר הרשת; אם ה-URL משתמש בכתובת הזו, השקע של הדפדפן נכנס לשכבת הכיסוי.

כשהשם נפתר במקום לכתובת LAN, ייתכן ששכבת הכיסוי כלל לא מעורבת, יהיה אשר יהיה מה שמציין מחוון המצב של הלקוח. ip route get 10.147.20.5 מדפיס את הממשק ואת כתובת המקור שהקרנל היה בוחר, כך שממשק zt שם אומר שהחבילה נכנסת לשכבת הכיסוי, ושם כרטיס הרשת הפיזי שלכם אומר שהיא לא. שמות מוסיפים שכבה נוספת: רשומה שמצביעה על כתובת כיסוי מתנהגת אחרת מרשומה שמצביעה על כתובת LAN, וסיומת חיפוש או רשומה בקובץ hosts יכולות להחליט בשקט איזו תקבלו.

בדיקה 2: ודאו ששני הקצוות הם עמיתים, לא ממסר שמפענח

ZeroTier מצפין בין עמיתים, והיכן שאין נתיב ישיר החבילות מועברות דרך שורש שמעביר אותן עדיין מוצפנות. zerotier-cli peers מסמן את הנתיב של כל עמית כ-DIRECT או RELAY עם נתון השהיה. נתיב מועבר עולה סבבי הלוך ושוב, לא סודיות.

מה שכן משנה את התשובה הוא חבר שאינו קצה אמיתי. כשהצד השני הוא חבר ZeroTier שמנתב או מגשר אל LAN פיזי, שכבת הכיסוי נגמרת באותו חבר והקפיצה הבאה היא Ethernet רגיל.

בדיקה 3: ראו היכן הבקשה נעשית קריאה

במארח שאתם מאמינים שמגיש את הדף, לכדו את ממשק הכיסוי בזמן רענון: sudo tcpdump -i ztxxxxxxx -A -c 5 'tcp port 80'. שורת בקשה קריאה בפלט הזה מוכיחה שהתעבורה הגיעה מפוענחת לאותו מארח, וזה הגבול שאתם מחפשים.

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

לכידת loopback חשובה גם כשפרוקסי הפוך עומד מלפנים, כי פרוקסי שמקבל HTTPS ומעביר HTTP מזיז את הגבול לקצה האחורי שלו.

בדיקה 4: חשבו כל קפיצה מאחורי נתב או גשר

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

עקבו אחריו במקום להניח אותו. traceroute מהלקוח לכתובת השירות בתוספת טבלת הניתוב בחבר השער מראים אם הקפיצה האחרונה היא zt או eth.

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

בדיקה 5: החליטו מה היישום עדיין חייב לעשות

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

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

"ה-VPN מחובר" אינו הערכה של דבר מזה. הגרסה הכנה נוקבת בשני הקצוות, בנתיב שביניהם ובקפיצה הראשונה שאינה מכוסה.

שמרו את פלט הלכידה ואת רשימת העמיתים לצד תיעוד השירות, כדי שכל מי שמשנה נתיב או מוסיף גשר יראה איזו הנחה הוא עומד לשבור.