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

מה עושה נתב subnet של Tailscale

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

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

מתי VPS זקוק לנתב רשת משנה (subnet router)

המקרה הנפוץ הוא רשת פרטית שהספק כבר הקצה עבורכם. לשרת ה-VPS שלכם יש כתובת ציבורית וממשק נוסף במקטע פרטי, בעוד שלשרתים האחרים באותו מקטע אין כתובת ציבורית כלל: מסד נתונים ב-10.0.0.20, או יעד לגיבוי ב-10.0.0.30. התקינו את Tailscale על שרת VPS אחד, הגדירו פרסום של 10.0.0.0/24, והמחשב הנייד שלכם יוכל להגיע לכתובות פרטיות אלו ישירות. שום דבר אחר במקטע הרשת אינו משתנה, ומסד הנתונים נותר ללא כתובת ציבורית.

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

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

התקנת 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, ולכן שלב זה אינו אופציונלי.

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 עובד באופן מיידי אך מתאפס לאחר אתחול, כך שנתב ה-subnet עשוי לעבוד שבועות ואז להפסיק לפעול בבוקר שאחרי שדרוג ליבה (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 עם דגל (flag) יחיד מאפסת את הדגלים שלא צוינו שוב, וממשק ה-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=.

אישור הנתיב ב-admin console

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

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

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

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

{
  "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 באותו קובץ policy. כדאי להגדיר זאת אם אתם בונים מחדש את ה-VPS באמצעות סקריפט, כיוון ש-node שנבנה מחדש נחשב ל-node חדש והנתיבים שלו יתחילו שוב במצב לא מאושר.

Why Linux clients ignore the route without --accept-routes

The route is now advertised and approved. Your phone and your Mac can reach 10.0.0.20. Your Linux laptop cannot, and nothing in the admin console suggests a problem.

Accepting a subnet route means writing entries into the client's routing table. On Android, iOS, macOS, tvOS and Windows, the Tailscale client does that for you. On Linux it does not, because a Linux machine is often a server or a router whose routing table someone configured on purpose, and silently inserting a /24 learned from the network could break traffic that machine already handles. So on Linux you opt in, on each client:

sudo tailscale set --accept-routes

Then check where the route landed:

ip route show table 52
ip route get 10.0.0.20

Tailscale on Linux does not put accepted routes in the main routing table. It puts them in routing table 52 and installs policy rules, visible with ip rule show in the priority range 5210 to 5270, that send unmatched packets to that table. So ip route show on its own will never list 10.0.0.0/24, and a reader who checks only that command concludes that --accept-routes did nothing. ip route show table 52 is the command that shows the truth, and it should list the advertised range on tailscale0.

One exception is worth knowing. If this Linux node is itself a second subnet router for its own local network, --accept-routes makes it send traffic for its own directly connected subnet through the other router instead of out its own interface. On a standby router in a high availability pair, leave --accept-routes off and advertise only.

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

אסור לשני נתבי 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 גורמת לשניים להתחרות על אותם יעדים, והמנצח תלוי בפלטפורמה. ב-Linux, התקינו חוק לפני החוק של Tailscale עצמה כדי שכתובות מקומיות ישתמשו בטבלה הראשית:

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

חוק זה אינו נשמר לאחר אתחול והוא נמחק ב־reboot הבא. הפתרון האמיתי הוא בחירת טווח פרטי שלא תיתקלו בו בחוץ. 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 החדש במסוף הניהול.

קיים מלכוד דומה בשרת ה־DNS עצמו. אם הגדרתם שרת DNS גלובלי במסוף הניהול בכתובת פרטית כמו 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 המוגדר כברירת מחדל ולעולם לא יגיעו ליעדן, מה שיגרום לחיבורים להיתקע לאחר החבילה הראשונה. הוסיפו את ה-static route ב-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 יכולה לשאת. התקורה של ה-tunnel הופכת את החבילות המועברות לגדולות מדי עבור חלק מהקישורים בדרך, וביצוע 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 הוא שירות מאוחסן. המפתחות שלכם נשארים על המכונות שלכם, אך החשבון וקובץ המדיניות נמצאים שם. הרצת 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 מתקין נתיבים מאושרים ב-routing table 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 וניתוב הם שלבים נפרדים. שם יכול להיתרגם לכתובת ששום נתיב מאושר אינו מכסה, ואז החבילה יוצאת דרך ה-gateway המוגדר כברירת מחדל בלקוח. הריצו את ip route get <address> בלקוח. אם התשובה אינה כוללת את dev tailscale0, פרסמו טווח שמכסה את אותה כתובת ואשרו את ה-prefix החדש ב-admin console.