ZeroTier אל רשת מקומית: כללי ניתוב של UFW, לא אישור פורט

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

שלוש משימות, שלושה בעלים

המסלול המנוהל שייך לתצורת הרשת של ZeroTier. הוא אומר לחברים שקידומת מסוימת נגישה דרך כתובת חבר מסוימת.

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

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

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

כוונו את המסלול המנוהל אל החבר

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

החברים חייבים לקבל מסלולים מנוהלים כדי שהתכנון יעבוד, והרשתות המקומיות שלהם אינן רשאיות כבר להשתמש בקידומת שאתם מכריזים עליה. מחשב נייד מרוחק שנמצא בבית על 192.168.60.0/24 גם הוא לא יכול לנתב 192.168.60.0/24 דרך שכבת העל.

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

כתבו את הקידומת ואת כתובת החבר באותה הערה שבה כללי חומת האש, כי התקלה הנפוצה ביותר היא מסלול שמצביע על החבר הלא נכון.

הפעילו מעבר בליבה

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

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

sysctl net.ipv4.ip_forward
sudo ufw route allow in on zt3f2a1c9d out on eth0 proto tcp to 192.168.60.20 port 443
sudo ufw status verbose

שם הממשק הוא התקן שכבת העל בפועל במארח הזה, שאפשר לקרוא עם ip link; הוא אינו מחרוזת קבועה בכל ההתקנות. אם המארח מעביר כברירת מחדל ו-UFW אינו בדרך, כלל הניתוב ייתקע והגדרות הליבה הן מה שחשוב.

בחרו איך התשובות חוזרות

עם שימור מקור, שירות הרשת המקומית רואה את כתובת שכבת העל האמיתית ומשיב לה. זה מחייב מסלול במארח הרשת המקומית או בנתב שלה שמצביע על קידומת שכבת העל אל השער שלכם, וזהו שינוי מחוץ לתיבת ה-Linux.

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

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

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

בדקו מחבר אמיתי

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

חבר אשר מדווח ONLINE, או פינג מוצלח לכתובת שכבת העל של השער, אינו מאמת את המסלול, את כלל ההעברה או את נתיב החזרה:

zerotier-cli listnetworks
ip -4 route get 192.168.60.20
sudo ufw status numbered

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