הגדרת Tailscale Subnet Router על גבי שרת VPS

מה עושה נתב רשת משנה (subnet router) של Tailscale

נתב רשת משנה של Tailscale הוא מכונה המפרסמת טווח שלם של כתובות IP פרטיות אל ה-tailnet שלכם, כך שכל התקן ב-tailnet יכול להגיע לכתובות בטווח זה גם אם לא מותקן עליהן Tailscale. ה-tailnet שלכם הוא רשת ה-Tailscale הפרטית שלכם: קבוצת ההתקנים המחוברים לחשבון או לארגון אחד. צומת יציאה (exit node) הוא התכונה שאנשים נוטים לבלבל בינו לבין נתב רשת משנה, אך הוא מבצע את הפעולה ההפוכה. הוא מנתב את כל התעבורה של התקן מסוים דרך ה-VPS, כך שה-VPS הופך לנתיב של אותו התקן אל האינטרנט הציבורי.

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

מתי נדרש נתב רשת משנה (subnet router) בשרת VPS

המקרה הנפוץ הוא רשת פרטית שהספק כבר הקצה עבורכם. לשרת ה-VPS שלכם יש כתובת ציבורית וממשק נוסף במקטע פרטי, בעוד ששרתים אחרים באותו מקטע אינם מחזיקים בכתובת ציבורית כלל: מסד נתונים ב-10.0.0.20, או יעד לגיבוי ב-10.0.0.30. התקינו את Tailscale על שרת VPS אחד, הגדירו פרסום (advertise) של 10.0.0.0/24, והמחשב הנייד שלכם יגיע לכתובות פרטיות אלו ישירות. שום דבר אחר במקטע אינו משתנה, ומסד הנתונים נותר ללא כתובת ציבורית. אם הדבר היחיד שאתם צריכים מאותו מקטע הוא יישום אינטרנט בודד בפורט מסוים, פרסום של כל הטווח הוא מעבר לנדרש, ו-Tailscale serve מאפשר להגדיר HTTPS על אותו פורט בודד במקום זאת. אותו היגיון תקף עבור daemon שמאזין במכוון ל-localhost בלבד, כגון dsh שרץ ללא ממשק גרפי תחת systemd, כאשר כתובת ב-tailnet על אותו VPS מחליפה את מנהרת ה-SSH שהייתם מחזיקים פתוחה אחרת כדי להגיע לממשק שלו.

המקרה השני הוא רשת שנמצאת בצד המרוחק של ה-VPS. רשת מקומית (LAN) ביתית או משרדית מאחורי נתב משלה, או ארון שרתים עם התקנים שלא יכולים להריץ את Tailscale כלל, כגון מתג מנוהל (managed switch) או התקן NAS ישן עם קושחה נעולה. מכונת Linux אחת באותה רשת הופכת לנתב רשת המשנה עבור כל השאר. בבית, מכונה זו היא לרוב מכונה וירטואלית (VM) קטנה על hypervisor שאתם כבר מריצים, ו-חישוב העלויות של מארח Proxmox בבית לעומת VPS שכור הוא העניין שיש להכריע לפני שמחליטים באיזה צד של המנהרה השירותים שלכם צריכים להתארח.

שני המקרים חולקים דרישה אחת. נתב רשת המשנה חייב להיות מסוגל להגיע לטווח שהוא מפרסם, תוך שימוש בטבלת הניתוב וב-firewall שלו. Tailscale אינה בונה את החיבור הזה. היא מעבירה את התעבורה לנתב ומעבירה אותה ל-kernel לצורך העברה (forwarding).

התקנת Tailscale ובדיקת הניתוב המקומי תחילה

curl -fsSL https://tailscale.com/install.sh | sh

הסקריפט מזהה את ההפצה, מוסיף את מאגר החבילות של Tailscale, מתקין את הפקודה tailscale ואת ה-daemon‏ tailscaled, ולאחר מכן מפעיל את השירות. יש לאמת זאת באמצעות systemctl is-active tailscaled, שאמור להציג active.

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

ip route show
ping -c3 10.0.0.20

הפקודה ip route show חייבת להציג את טווח הכתובות הפרטי בממשק רשת פעיל, בדומה ל-10.0.0.0/24 dev enp7s0 proto kernel scope link src 10.0.0.5. אם ה-ping נכשל כאן, בנתב עצמו, שום דגל (flag) של Tailscale לא יפתור זאת. הבעיה נעוצה בתצורת הרשת של ה-VPS או ב-firewall במארח היעד. יש לתקן זאת תחילה, שכן כל בדיקה בהמשך תלויה בכך.

הפעלת IP forwarding והבטחת הישרדות ההגדרה לאחר אתחול

מכונת Linux משליכה כל חבילת מידע (packet) שאינה ממוענת אליה, אלא אם כן מופעל בה forwarding. העברת חבילות של מכונות אחרות היא התפקיד המלא של נתב רשת משנה (subnet router), לכן שלב זה אינו אופציונלי.

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

בדקו זאת באמצעות sysctl net.ipv4.ip_forward, שאמור להדפיס net.ipv4.ip_forward = 1.

אנשים רבים מבצעים רק חצי מהשלב הזה. הפקודה sudo sysctl -w net.ipv4.ip_forward=1 עובדת באופן מיידי אך מתאפסת באתחול הבא, כך שנתב הרשת עשוי לעבוד במשך שבועות ואז להפסיק לפעול בבוקר שאחרי אתחול עקב שדרוג ליבה (kernel). החלק המבלבל הוא ששום דבר לא נראה שבור. tailscale status עדיין מציג את הצומת כפעיל, מסוף הניהול עדיין מציג את הנתיב כמאושר, והלקוחות עדיין מחזיקים בנתיב המותקן. חבילות מגיעות ל-VPS והליבה משליכה אותן מבלי לתעד דבר. כתיבת הערכים לתוך /etc/sysctl.d/99-tailscale.conf היא מה שמחזיר אותם לפעולה לאחר אתחול.

אם תפרסמו נתיבים כאשר ה-forwarding עדיין כבוי, tailscale up יזהיר אתכם באותו רגע, עם שורה הדומה ל-Warning: IPv4 forwarding is disabled. Subnet routes and exit nodes may not work correctly.. קראו את הפלט של פקודה זו במקום לדלג עליו.

פרסום נתיבים

sudo tailscale up --advertise-routes=10.0.0.0/24

בשרת VPS שכבר מחובר ל-tailnet שלכם, שנו את ההגדרה במקום זאת באופן הבא:

sudo tailscale set --advertise-routes=10.0.0.0/24

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

ניתן להזין כמה טווחים ברשימה מופרדת בפסיקים ללא רווחים: --advertise-routes=10.0.0.0/24,192.168.50.0/24. כל ערך חייב להיות כתובת רשת בסימון CIDR (ניתוב בין-תחומי ללא מחלקות, התבנית 10.0.0.0/24). כתיבת כתובת המארח שלכם בטעות, 10.0.0.5/24, תידחה כיוון שהביטים שאחרי הקידומת אינם אפסים, והשגיאה תציין את הקידומת שאליה כנראה התכוונתם. כדי להפסיק את הפרסום, הגדירו רשימה ריקה באמצעות sudo tailscale set --advertise-routes=.

אישור הנתיב בלוח הבקרה של הניהול

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

יש לאשר את הנתיב בדף ה-Machines בלוח הבקרה של הניהול. ה-VPS יופיע עם תגית subnet. פתחו את השורה שלו, אתרו את מקטע ה-subnets, ערכו את הגדרות הנתיב, סמנו את הנתיב ושמרו.

האישור מתבצע ברמת ה-prefix. אם תפרסמו את 10.0.0.0/24 היום ואת 192.168.50.0/24 בחודש הבא, ה-prefix החדש יגיע במצב לא מאושר בעוד הישן ימשיך לעבוד כרגיל. נתיב מאושר ונתיב שטרם אושר נראים זהים לחלוטין מנקודת המבט של ה-VPS, לכן בדקו את לוח הבקרה לפני שתתחילו בתהליכי ניפוי שגיאות אחרים.

ניתן לדלג על השלב הידני באמצעות בלוק autoApprovers בקובץ המדיניות של ה-tailnet:

{
  "autoApprovers": {
    "routes": {
      "10.0.0.0/24": ["tag:subnet-router"]
    }
  }
}

לאחר מכן, העלו את ה-node עם התגית הזו, sudo tailscale up --advertise-routes=10.0.0.0/24 --advertise-tags=tag:subnet-router, והנתיב יאושר ברגע שיפורסם. על התגית להיות מוגדרת תחילה במקטע tagOwners באותו קובץ מדיניות. כדאי להגדיר זאת אם אתם בונים את ה-VPS מחדש באמצעות סקריפט, שכן node שנבנה מחדש נחשב ל-node חדש והנתיבים שלו יתחילו שוב במצב לא מאושר.

מדוע לקוחות Linux מתעלמים מהנתיב ללא --accept-routes

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

קבלת נתיב subnet משמעותה כתיבת רשומות לטבלת הניתוב של הלקוח. ב-Android, ב-iOS, ב-macOS, ב-tvOS וב-Windows, לקוח ה-Tailscale מבצע זאת עבורך. ב-Linux הוא אינו עושה זאת, כיוון שמכונת Linux היא לעיתים קרובות שרת או נתב שטבלת הניתוב שלו הוגדרה במכוון על ידי מישהו, והכנסה שקטה של /24 שנלמד מהרשת עלולה לשבש תעבורה שהמכונה כבר מטפלת בה. לכן ב-Linux עליך לבחור להצטרף, בכל לקוח:

sudo tailscale set --accept-routes

לאחר מכן בדוק היכן הנתיב נקלט:

ip route show table 52
ip route get 10.0.0.20

Tailscale ב-Linux אינו מציב נתיבים מאושרים בטבלת הניתוב הראשית. הוא מציב אותם בטבלת ניתוב 52 ומתקין חוקי מדיניות, שניתן לראות באמצעות ip rule show בטווח העדיפויות 5210 עד 5270, השולחים חבילות שלא נמצא להן התאמה לאותה טבלה. לכן ip route show כשלעצמו לעולם לא יציג את 10.0.0.0/24, וקורא שבודק רק את הפקודה הזו יסיק ש---accept-routes לא ביצע דבר. ip route show table 52 היא הפקודה שמציגה את האמת, ועליה להציג את הטווח המפורסם ב-tailscale0.

יוצא דופן אחד שראוי להכיר. אם צומת Linux זה משמש בעצמו כנתב subnet שני עבור הרשת המקומית שלו, --accept-routes גורם לו לשלוח תעבורה עבור ה-subnet המחובר ישירות אליו דרך הנתב האחר במקום דרך הממשק שלו. בנתב במצב המתנה (standby) בזוג בעל זמינות גבוהה (high availability), השאר את --accept-routes כבוי ובצע פרסום בלבד.

מצב כשל: שני נתבים המפרסמים טווחי כתובות חופפים

אסור ששני נתבי subnet יפרסמו טווחי כתובות זהים. טווחים חופפים עם אורכי prefix שונים מותרים, ו-Tailscale בוחרת את ההתאמה הספציפית ביותר. כאשר נתב A מפרסם את 10.0.0.0/24 ונתב B מפרסם את 10.0.0.0/16, תעבורה המיועדת ל-10.0.0.20 תנותב ל-A.

מה שמפתיע משתמשים הוא ההתנהגות כאשר A עובר למצב לא מקוון. Tailscale אינה מבצעת failover לנתיב הפחות ספציפי. תעבורה ל-10.0.0.20 תיעצר, בעוד שתעבורה ל-10.1.0.20 תמשיך לעבוד דרך B. התסמין נראה כאילו חצי מהרשת הפרטית אינו זמין, והסיבה היא צומת לא מקוון שמחזיק ב-prefix הספציפי יותר. אם ברצונכם להגדיר failover, הגדירו גם לנתב הרחב יותר לפרסם את ה-prefixes הצרים, כך ששניהם יכסו את אותן כתובות.

חפיפה אחרת מתרחשת קרוב יותר ללקוח. שהייה ברשת מלון ב-192.168.1.0/24 בזמן שנתב ה-subnet שלכם מפרסם את 192.168.1.0/24 גורמת לשניים להתחרות על אותם יעדים, והצד שינצח תלוי בפלטפורמה. בלינוקס, התקינו חוק שקודם לחוק של Tailscale כדי שכתובות מקומיות ישתמשו בטבלה הראשית:

sudo ip rule add to 192.168.1.0/24 priority 2500 lookup main

חוק זה אינו נשמר לאחר אתחול המערכת. הפתרון האמיתי הוא בחירת טווח פרטי שלא תיתקלו בו ברשתות ציבוריות. 192.168.0.0/24 ו-192.168.1.0/24 הם ברירות המחדל ברוב הנתבים הביתיים, לכן בחרו כתובת מתוך 10.0.0.0/8 שהגדרתם במכוון. אותה התנגשות משבשת גם VPN מסוג WireGuard שהגדרתם ידנית, מאותה סיבה: הנתיב המקומי הספציפי יותר מנצח, ולכן התעבורה לעולם אינה נכנסת למנהרה.

מצב כשל: DNS מתרגם לכתובת שאין לה נתיב (route)

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

נניח ש-db.internal.example.com מתרגם ל-10.0.5.20 דרך שרת ה-DNS הפרטי שלכם, ופרסמתם את 10.0.0.0/24. תהליך ה-lookup מצליח, כיוון שתרגום DNS (domain name system) וניתוב IP הם שלבים נפרדים, ואף אחד מהם לא בודק את השני. לאחר מכן, החבילה שנשלחת ל-10.0.5.20 לא מוצאת נתיב תואם ב-tailnet, לכן היא יוצאת דרך ה-default gateway של הלקוח ונעלמת.

שתי פקודות מפרידות בין שני החלקים:

nslookup db.internal.example.com
ip route get 10.0.5.20

אם ה-lookup מחזיר כתובת אך ip route get לא משיב עם dev tailscale0, השם תקין אך הנתיב חסר. פרסמו טווח שמכסה את הכתובת, בין אם 10.0.0.0/16 או prefix מפורש שני, ולאחר מכן אשרו את ה-prefix החדש ב-console.

קיים מלכוד דומה בשרת ה-DNS עצמו. אם הגדרתם שרת DNS גלובלי ב-admin console בכתובת פרטית כמו 10.0.0.53, כתובת זו חייבת להימצא בתוך נתיב מאושר, אחרת המכשירים שלכם לא יוכלו להגיע ל-resolver כלל. הפעילו את האפשרות שדורסת שרתי DNS מקומיים בזמן שאתם מצביעים על resolver שאף אחד לא יכול להגיע אליו, וכל מכשיר ב-tailnet יאבד את יכולת תרגום השמות באופן מיידי, כולל אלו שעבדו רגע לפני כן. פרסמו ואשרו את הנתיב ל-resolver תחילה, ורק לאחר מכן שנו את הגדרת ה-DNS. אם DNS בתוך מנהרה (tunnel) הוא החלק שאתם ממשיכים להיאבק בו, הדרך שבה DNS נשבר מעל מנהרת WireGuard מכסה את אותו מנגנון ללא שכבת התיאום שמעליו.

Source NAT וקישורים מסוג site to site

כברירת מחדל, הנתב של ה־subnet משכתב את כתובת המקור של כל חבילת מידע (packet) מועברת לכתובת הפרטית שלו. זהו SNAT (תרגום כתובות רשת מקור), והוא קיים כדי שמענה לבקשות יעבוד ללא צורך בשינוי הגדרות ברשת הפרטית: מסד הנתונים ב-10.0.0.20 משיב ל-VPS, שאליו הוא כבר יודע איך להגיע. המחיר הוא שמסד הנתונים רואה כל חיבור ב-tailnet כאילו הגיע מה-VPS, ולכן חוקי firewall מבוססי מקור ויומני גישה אינם מספקים מידע מועיל.

ניתן לכבות זאת ב-Linux כאשר רוצים לשמר את כתובת ה-tailnet האמיתית של הלקוח:

sudo tailscale set --snat-subnet-routes=false

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

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

sudo tailscale up --advertise-routes=10.0.0.0/24 --snat-subnet-routes=false --accept-routes

יש להריץ את הפקודה התואמת בנתב השני עם הטווח שלו. שני הטווחים חייבים להיות שונים. אם העברות נתונים גדולות נתקעות בעוד ש-ssh ו-ping תקינים, הסיבה היא MSS (גודל מקטע מרבי), נתח המידע הגדול ביותר שחבילת TCP יכולה לשאת. ה-overhead של המנהרה הופך את החבילות המועברות לגדולות מדי עבור חלק מהקישורים בדרך, וביצוע clamping פותר זאת:

sudo iptables -t mangle -A FORWARD -o tailscale0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

יש לשמור את החוק באמצעות iptables-persistent, אחרת הוא יימחק באתחול הבא.

תחזוקה שוטפת להבטחת פעילות תקינה

מפתחות צומת (node keys) פגים בתוקף לאחר 180 ימים כברירת מחדל, נכון לאוגוסט 2026. כאשר המפתח בנתב רשת משנה (subnet router) פג, הצומת מתנתק וכל טווח הכתובות המפורסם הופך לבלתי נגיש, ללא כל שינוי תצורה שיסביר זאת. בטלו את פקיעת המפתח עבור מכונה זו בדף ה-Machines במסוף הניהול, ותעדו שביצעתם זאת.

Tailscale מעדיפה חיבור ישיר בין עמיתים (peers) ועוברת לשרתי הממסר (relay servers) שלה כאשר אינה מצליחה ליצור חיבור כזה. הממסרים עובדים, אך הם מוסיפים השהיה (latency). שרת VPS עם כתובת ציבורית הוא המקרה הפשוט: אפשרו תעבורת UDP 41641 נכנסת ורוב העמיתים יתחברו ישירות. אם ufw מנהל את ה-firewall, המדריך חוקי ufw ש-VPS באמת צריך מפרט את התחביר הנדרש.

חוקי גישה (access rules) הם החלק השני. ב-tailnet ברירת מחדל, כל מכשיר שלכם יכול להגיע לכל מכשיר אחר, כך שנתיב מאושר פשוט עובד. ברגע שכותבים מדיניות ACL, צד היעד של החוק חייב לציין את טווח הכתובות הפרטי, כיוון ש-10.0.0.20 אינה כתובת tailnet והיא אינה מכוסה על ידי חוקים שנכתבו עבור כתובות IP או תגיות של tailnet.

לבסוף, החליטו אם אתם מעוניינים בשרת תיאום (coordination server) שאינכם מנהלים בעצמכם. מישור הבקרה (control plane) של Tailscale הוא שירות מנוהל. המפתחות שלכם נשארים על המכונות שלכם, אך החשבון וקובץ המדיניות מאוחסנים שם. מה שמישהו יכול לעשות בפועל עם מישור בקרה שנפרץ או התחברות מזוהה שנגנבה הוא החלק שכדאי להסדיר לפני שמעניקים לו נתיב לרשת הפרטית שלכם, והדף מודל האמון של Tailscale משרטט היכן עובר הגבול הזה. עלות היא לעיתים רחוקות הסיבה שגורמת לאנשים לעזוב, שכן התוכנית החינמית מכסה עד שישה משתמשים עם מספר בלתי מוגבל של מכשירים אישיים, אם כי נתב רשת משנה שאתם מפעילים תחת תגית נספר אחרת מאשר כזה שמחובר תחת המשתמש שלכם. מעבר לנקודה זו, החיוב עוקב אחר אנשים ולא אחר מכונות, לכן כדאי לבדוק מה משק בית או צוות של חמישה אנשים משלמים בפועל לאחר סיום התוכנית החינמית לפני שמוסיפים את החשבון שמעביר אתכם למסלול בתשלום. הרצת Headscale, שרת הבקרה העצמי של Tailscale שומרת את השליטה על ה-VPS שלכם, במחיר של תחזוקה שוטפת. התשובה האחרת לאותו חשש היא לנטוש גם את הלקוחות של Tailscale, ושימוש ב-שרת ה-VPN בניהול עצמי NetBird מציב את שכבת התיאום ואת לקוחות ה-mesh שלה על מכונה אחת שבשליטתכם. אם אתם עדיין מתלבטים בין מודל זה לבין תצורה ידנית, ההשוואה בין WireGuard ל-Tailscale מסבירה מה שכבת התיאום מעניקה לכם ומה העלות שלה.

FAQ

מה ההבדל בין subnet router לבין exit node?

subnet router מפרסם טווח כתובות פרטיות, כך שהתקנים בתוך ה-tailnet יכולים להגיע למכונות שאינן מריצות את Tailscale. לעומת זאת, exit node מפרסם את עצמו כנתיב לכל האינטרנט, כך שהתקן שולח את כל התעבורה שלו דרך הכתובת הציבורית של אותו צומת. שרת VPS אחד יכול לשמש כשניהם. מדובר בדגלים נפרדים, --advertise-routes ו---advertise-exit-node, וכל אחד מהם דורש אישור נפרד ב-admin console.

מדוע לקוח ה-Linux שלי מתעלם מנתיב ה-subnet שפורסם?

לקוחות Linux אינם מקבלים נתיבי subnet אלא אם כן הגדרת להם לעשות זאת. הריצו את sudo tailscale set --accept-routes בלקוח. לאחר מכן בדקו באמצעות ip route show table 52, ולא באמצעות ip route show. Tailscale מתקין נתיבים מאושרים בטבלת ניתוב 52 ומגיע אליהם דרך חוקי מדיניות, לכן הטבלה הראשית לעולם לא תציג אותם ונתיב תקין עשוי להיראות כאילו הוא חסר.

ה-subnet שלי הפסיק לעבוד לאחר אתחול. מה השתבש?

סביר להניח שמדובר ב-IP forwarding. ערך שנקבע באמצעות sysctl -w אינו נשמר לאחר אתחול, לכן יש לכתוב אותו ל-/etc/sysctl.d/99-tailscale.conf ולאשר באמצעות sysctl net.ipv4.ip_forward. אם ה-forwarding פעיל והטווח עדיין אינו נגיש, בדקו את הצומת ב-admin console. מפתחות צומת פגים לאחר 180 ימים כברירת מחדל, ו-subnet router שפג תוקפו נראה כמו תקלת רשת ולא כמו בעיית חשבון.

האם שני subnet routers יכולים לפרסם את אותו הטווח?

לא טווחים זהים. טווחים חופפים עם אורכי prefix שונים הם תקינים, והטווח הספציפי ביותר הוא זה שקובע. נדרשת זהירות ב-failover: כאשר הנתב שמחזיק ב-prefix הספציפי יותר יורד מהרשת, Tailscale אינו עובר אוטומטית לנתיב הרחב יותר, ולכן התעבורה נעצרת. עבור זוג standby אמיתי, הגדירו את שני הנתבים לפרסם את אותם ה-prefixes הספציפיים.

שם המארח (hostname) מתרגם לכתובת אך החיבור נכשל ב-timeout. מדוע?

תרגום DNS וניתוב הם שלבים נפרדים. שם יכול להתרגם לכתובת ששום נתיב מאושר אינו מכסה, ואז החבילה יוצאת דרך ה-default gateway של הלקוח. הריצו את ip route get <address> בלקוח. אם התשובה אינה כוללת את dev tailscale0, פרסמו טווח שמכסה את אותה כתובת ואשרו את ה-prefix החדש ב-admin console.