תנועה חד-כיוונית לאחר השבתת SNAT של תת-הרשת ב-Tailscale

כבו את NAT המקור בנתב תת-רשת של Tailscale והמנהרה ממשיכה לעבוד בעוד החיבורים דרכה נעצרים. הבקשות מגיעות ליעד עם כתובת ה-overlay של הלקוח המרוחק, וזה בדיוק הרעיון של השינוי, והתגובות זקוקות כעת למסלול שה-LAN מעולם לא היה צריך להכיר. בלי המסלול הזה החבילות נוחתות, התגובות יוצאות דרך שער ברירת המחדל, והתקלה נראית כמו בעיית חומת אש שאין שום כלל שמסביר אותה. המנהרה בריאה; רגל החזרה חסרה.

מה SNAT הסתיר

כאשר SNAT מופעל, הנתב כותב מחדש את כתובת המקור לכתובת ה-LAN שלו לפני העברה לתת-הרשת, כך שהיעד משיב למארח שהוא כבר יודע איך להגיע אליו ושאין צורך להגדיר דבר נוסף. השבתתו משמרת את המקור המקורי, והיעד רואה אז כתובת בטווח ה-overlay ולא שכן על החוט שלו. הכתובת הזו אמיתית וניתנת לניתוב ברחבי ה-tailnet, והיא אינה נגישה מה-LAN דרך שער ברירת המחדל. המתג המתועד הוא --snat-subnet-routes=false, שמוחל על נתב תת-הרשת של Linux עצמו.

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

היכן יכול מסלול החזרה לשכון

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

ip route add 100.64.0.0/10 via 192.168.1.10
ip route get 100.64.0.5

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

לקרוא את התקלה כתנועה חד-כיוונית

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

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

sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5

האם הכתובת האמיתית שווה מסלול

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

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

חומת אש, רישום יומן והתפקיד הכפול

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

sudo nft list ruleset | grep -n '100\.64'
sudo iptables-save | grep -n '100\.64'

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