הגדרת VPS כ-Tailscale exit node: מדריך מלא

מה עושה Exit node של Tailscale

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

ברגע שהשירות פעיל, המחשב הנייד שלכם מצפין כל חבילת מידע (packet) ושולח אותה ל-VPS. ה-VPS מבצע source NAT (תרגום כתובות רשת) ושולח את החבילה הלאה עם כתובת ה-IP הציבורית שלו. אתרי אינטרנט רואים את ה-VPS. רשת ה-Wi-Fi בבית הקפה רואה רק זרם UDP מוצפן אחד לכיוון ה-VPS, ולא שום דבר מעבר לכך.

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

השלבים להלן מניחים ש-Tailscale כבר מותקן ורץ על המחשב הנייד שלכם, וששתי המכונות מחוברות לאותו tailnet. ה-tailnet הוא רשת ה-Tailscale הפרטית שלכם, וכל מכשיר בתוכה מקבל כתובת יציבה בתוך 100.64.0.0/10.

התקנת Tailscale על ה-VPS שלכם

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

סקריפט ההתקנה בוחר את מאגר החבילות המתאים להפצה שלכם ומתקין את ה-daemon של tailscaled. לאחר מכן, tailscale up מציג כתובת URL לאימות. פתחו אותה בדפדפן והתחברו עם אותו חשבון שבו אתם משתמשים במחשב הנייד שלכם, כיוון ש-VPS המחובר ל-tailnet אחר לא יוכל לשרת את המחשב הנייד שלכם כלל.

tailscale status
tailscale ip -4

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

Tailscale זקוק להתקן TUN כדי לבנות את המנהרה. ב-VPS מבוסס KVM ההתקן קיים. בתוכניות המבוססות על וירטואליזציה של מכולות (containers) המשתפות את ה-kernel של המארח, /dev/net/tun חסר לעיתים, ו-tailscaled לא יכול ליצור את ממשק ה-tailscale0. הריצו את ls -l /dev/net/tun לפני שתמשיכו הלאה.

הפעלת IP forwarding, אחרת ה-VPS ישליך כל חבילת מידע

מכונת Linux משליכה כל חבילת מידע שאינה ממוענת אליה, כיוון ש-net.ipv4.ip_forward מוגדר כברירת מחדל ל-0. צומת היציאה (exit node) יקבל את התעבורה שלך, יפענח אותה, ואז ישליך אותה. כתוב את ההגדרה לקובץ כדי שהיא תישמר לאחר אתחול (reboot).

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

tee -a מבצע הוספה (append), לכן הרצת שורות אלו פעם שנייה תכתוב את שתי ההגדרות פעמיים. התוצאה עדיין תעבוד, אך cat /etc/sysctl.d/99-tailscale.conf ייראה מוזר. אשר את הערך החי במקום להסתמך על הקובץ:

sysctl net.ipv4.ip_forward

הוא חייב להדפיס net.ipv4.ip_forward = 1. אם תדלג על כך ותשתמש ב-tailscale up --advertise-exit-node, הלקוח יציג לך:

Warning: IP forwarding is disabled, subnet routing/exit nodes will not work.

tailscale set --advertise-exit-node אינו מריץ את הבדיקה הזו, לכן שתיקה מצד set אינה הוכחה לכך שה-forwarding פעיל. קרא את ערך ה-sysctl בעצמך.

אין צורך לכתוב חוק masquerade באופן ידני. tailscaled מתקין שרשראות firewall משלו, ששמן ts-input, ts-forward ו-ts-postrouting, וחוק ה-NAT עבור תעבורת צומת היציאה נמצא ב-ts-postrouting. צפה בהם באמצעות sudo iptables-save | grep ts-, או sudo nft list ruleset במכונה המשתמשת ב-nftables.

הגדרת ה-VPS כצומת יציאה (exit node)

sudo tailscale set --advertise-exit-node

tailscale set משנה העדפה אחת בלבד ומותיר את האחרות ללא שינוי. tailscale up --advertise-exit-node מפרסם גם את הצומת, אך יש לכך תופעת לוואי: up מתייחס לדגלים בשורת הפקודה שלו כאל סט מלא של הגדרות שאינן ברירת מחדל, ולכן הרצה מאוחרת יותר של sudo tailscale up ללא דגלים תסרב לפעול ותציג את השגיאה הבאה:

changing settings via 'tailscale up' requires mentioning all
non-default flags. To proceed, either re-run your command with --reset or
use the command below to explicitly mention the current value of
all non-default settings:

השתמשו ב-set לביצוע שינויים שוטפים, וכך לעולם לא תיתקלו בהודעה זו.

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

אישור צומת יציאה (exit node) של Tailscale במסוף הניהול

זהו השלב שאינו דורש הרצת פקודה. פתחו את דף המכונות במסוף הניהול, אתרו את ה-VPS, פתחו את תפריט שלוש הנקודות בקצה השורה שלו, בחרו ב-Edit route settings, והפעילו את האפשרות Use as exit node.

כל עוד המתג אינו פעיל, מישור הבקרה (control plane) מחזיק בהצעה ואינו מעביר אותה לאף אחד. הפקודה tailscale exit-node list במחשב הנייד שלכם לא תציג דבר, והתעבורה שלכם תמשיך במסלולה הרגיל. לא תופיע הודעת שגיאה באף אחד מהמכשירים; צומת היציאה פשוט לא יופיע.

ניתן לאשר צמתי יציאה באופן אוטומטי באמצעות רשומה בקובץ המדיניות של ה-tailnet:

"autoApprovers": {
  "exitNode": ["tag:exit"],
}

מכשיר שעולה עם --advertise-tags=tag:exit יאושר באופן עצמאי, בתנאי ש-tag:exit מוגדר תחת tagOwners באותו קובץ מדיניות. תיוג (tagging) משנה את הבעלות: מכשיר מתויג שייך ל-tailnet ולא לחשבון המשתמש שלכם, וכללי הגישה החלים עליו משתנים בהתאם. עבור VPS בודד, השימוש במתג פשוט יותר.

בחירת צומת יציאה (exit node) במחשב הנייד

בלקוח Linux:

tailscale exit-node list
sudo tailscale set --exit-node=vps.your-tailnet.ts.net

הפקודה exit-node list מציגה את צמתי היציאה המאושרים ב-tailnet שלכם יחד עם הכתובות שלהם. רשימה ריקה מעידה על כך ששלב האישור לא בוצע. ב-macOS, Windows, iOS ו-Android, אותה בחירה זמינה כפריט תפריט תחת Exit Node באפליקציית Tailscale.

בצעו אימות מהלקוח, לעולם לא מהשרת:

curl -4 https://ifconfig.me

הריצו פקודה זו פעם אחת לפני בחירת צומת היציאה ופעם אחת לאחר מכן. הכתובת חייבת להשתנות מהכתובת המקומית שלכם לכתובת ה-IP הציבורית של ה-VPS. כדי להפסיק להשתמש בצומת היציאה:

sudo tailscale set --exit-node=

דגל (flag) נוסף הוא בעל חשיבות ביום הראשון. כאשר צומת יציאה נבחר, הלקוח שולח את כל התעבורה לתוך המנהרה, כולל חבילות הממוענות ל-192.168.1.50, ולכן המדפסת והאחסון ברשת שלכם יפסיקו להגיב. כדי לשמור על הרשת המקומית בניתוב המקומי:

sudo tailscale set --exit-node=<name> --exit-node-allow-lan-access=true

מדוע הגדרות ה-DNS משתנות ברגע שצומת היציאה פעיל

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

תוצאה אחת משפיעה על מי שמריץ פותר פנימי: שרת שמות ב-tailnet שאתם מסתמכים עליו מפסיק להיות בשימוש בזמן שצומת היציאה פעיל. הפעילו את Use with exit node עבור שרת שמות זה בדף ה-DNS במסוף הניהול כדי להחזיר את פעילותו.

שמות MagicDNS ממשיכים לעבוד, כיוון שלקוח Tailscale עונה עליהם מקומית ב-100.100.100.100 לפני שכל דבר מגיע לצומת היציאה. בדקו זאת באמצעות dig @100.100.100.100 your-vps.your-tailnet.ts.net, או בלקוח המשתמש ב-systemd-resolved באמצעות resolvectl status, שם ממשק ה-Tailscale מציג את 100.100.100.100 כשרת ה-DNS שלו.

אם תשביתו את ניהול ה-DNS של Tailscale באמצעות --accept-dns=false, הלקוח ישמור על הפותר שקיבל מהרשת המקומית. התעבורה תעבור במנהרה (tunnel) אך השאילתות לא, וזהו אותו דליפת DNS שמתרחשת במנהרות WireGuard שנבנו ידנית. השאירו את --accept-dns כפי שהוא אלא אם יש לכם סיבה ספציפית לשנות זאת.

IPv6 דרך צומת יציאה (exit node)

צומת יציאה מפרסם נתיבי ברירת מחדל עבור 0.0.0.0/0 וגם עבור ::/0. אם לשרת ה-VPS אין נתיב IPv6 תקין לאינטרנט, חבילות IPv6 יגיעו דרך המנהרה (tunnel) וייעצרו שם. בצעו בדיקה ב-VPS לפני שתסתמכו עליו:

ip -6 addr show
curl -6 https://ifconfig.me

בקשה שנכשלה מעידה על כך של-VPS אין קישוריות IPv6 במעלה הזרם (upstream). אתרים התומכים ב-Dual stack בדרך כלל ייטענו בכל זאת, כיוון שהלקוח מוותר על IPv6 ומנסה שוב דרך IPv4, אם כי ניסיון חוזר זה מוסיף השהיה בחיבור הראשוני לכל אתר. יעדים התומכים ב-IPv6 בלבד יישארו בלתי נגישים.

החלק השני הוא ניתוב (forwarding). הגדרת net.ipv4.ip_forward = 1 כאשר net.ipv6.conf.all.forwarding נשאר על 0 תספק לכם נתיב IPv4 תקין ו"חור שחור" עבור IPv6, מה שהמשתמש יחווה כ"אתרים מסוימים איטיים" במקום כשגיאה שניתן לחפש עבורה פתרון. שני השורות הללו צריכות להופיע בקובץ ה-sysctl.

האם ה-VPS צריך לפרסם גם נתיבי subnet?

צומת יציאה (exit node) מעביר את כל תעבורת האינטרנט. נתיב subnet מעביר טווח כתובות פרטי אחד שנמצא מאחורי המכונה שמפרסמת אותו. אלו תכונות נפרדות עם אישורים נפרדים, ומכונה אחת יכולה לבצע את שתיהן.

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

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

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

האצת צומת יציאה באמצעות UDP GRO forwarding

גרסה 1.54 ומעלה של Tailscale, על גבי ליבת Linux 6.2 ומעלה, יכולה להשתמש ב-receive offload המעלה את קצב העברת הנתונים עבור תעבורה מנותבת. GRO (או Generic Receive Offload) מאחד חבילות נכנסות לפני שהליבה מעבדת אותן אחת אחת. נכון לאוגוסט 2026, זהו עדיין שלב ידני בצומת היציאה.

sudo apt install -y ethtool
NETDEV=$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")
sudo ethtool -K $NETDEV rx-udp-gro-forwarding on rx-gro-list off

ip -o route get 8.8.8.8 מדווח על הממשק שמגיע בפועל לאינטרנט, כך שלא תצטרכו לנחש בין eth0, ens3 לבין enp1s0. אשרו זאת באמצעות ethtool -k $NETDEV | grep udp-gro-forwarding, שאמור כעת להציג on.

ההגדרה הולכת לאיבוד לאחר אתחול. במערכת המריצה את networkd-dispatcher, ניתן להפוך זאת לאוטומטי:

printf '#!/bin/sh\n\nethtool -K %s rx-udp-gro-forwarding on rx-gro-list off \n' "$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")" | sudo tee /etc/networkd-dispatcher/routable.d/50-tailscale
sudo chmod 755 /etc/networkd-dispatcher/routable.d/50-tailscale

בדקו תחילה ש-/etc/networkd-dispatcher/routable.d/ קיים. אם הוא אינו קיים, המכונה אינה מריצה את networkd-dispatcher, ויחידת systemd קטנה המריצה את השורה ethtool בזמן העלייה תבצע את אותה עבודה.

מה המשמעות של מדיניות השימוש המקובל של הספק שלך עבור תעבורה יוצאת

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

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

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

מדוע תעבורה עדיין יוצאת דרך החיבור המקומי שלך

צומת היציאה (exit node) מפורסם אך לא מאושר. הפקודה tailscale exit-node list בלקוח לא מציגה דבר, ואף אחד מהמחשבים לא מתעד שגיאה. עברו לדף ה-Machines והפעילו את האפשרות Use as exit node.

הלקוח לא בחר בו. אישור הצומת הופך אותו לזמין ב-tailnet. הבחירה היא פעולה נפרדת בכל מכשיר. הריצו שוב את sudo tailscale set --exit-node=<name>, ולאחר מכן בדקו שוב את curl -4 https://ifconfig.me.

העברת חבילות (forwarding) כבויה. התסמין ספציפי: tailscale ping <vps> מצליח, המנהרה פעילה בבירור, וכל כתובת חיצונית נתקלת ב-timeout. הפקודה sysctl net.ipv4.ip_forward מחזירה 0. תקנו את קובץ ה-sysctl, ולאחר מכן הריצו את sudo sysctl -p /etc/sysctl.d/99-tailscale.conf.

חומת אש חוסמת את החבילות המועברות. tailscaled מוסיף שרשרת ts-forward משלו, ובשרת VPS נקי זה מספיק. שרת שכבר מריץ ufw או Docker עלול להגיע למצב שבו מדיניות ה-FORWARD היא DROP, עם חוקים שקודמים לאלו של Tailscale. אל תנחשו: הריצו את sudo iptables -L FORWARD -n -v בזמן שהלקוח מנסה לטעון דף, ועקבו אילו מונים משתנים. בשרת עם ufw, הפתרון הרגיל הוא DEFAULT_FORWARD_POLICY="ACCEPT" בתוך /etc/default/ufw, ולאחריו sudo ufw reload. בדקו גם את חומת האש של ספקית הרשת בלוח הבקרה, שכן מדובר בבקרה נפרדת מכל מה שרץ על השרת עצמו.

זה עובד, אבל איטי. הריצו את tailscale netcheck בשני המחשבים. אם מדווח ש-UDP חסום, שני המכשירים אינם יכולים ליצור נתיב ישיר ועוברים לשימוש ב-DERP relay, מה שמוסיף השהיה (latency) לכל חיבור. פתיחת תעבורת UDP נכנסת בפורט 41641 ל-VPS בחומת האש של הספקית בדרך כלל משחזרת את הנתיב הישיר.

מתי כדאי לעזוב את שרת התיאום של Tailscale

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

FAQ

מדוע התעבורה שלי עדיין משתמשת בחיבור המקומי לאחר בחירת ה-exit node?

קיימות שתי סיבות נפוצות לכך. ה-exit node פורסם אך לא אושר: פתחו את דף ה-Machines במסוף הניהול, מצאו את ה-VPS, בחרו ב-Edit route settings, והפעילו את האפשרות Use as exit node. האישור מתבצע באמצעות מתג במסוף הניהול, ושום פקודה בשרת אינה מבצעת זאת. הסיבה השנייה נראית אחרת: העברת IP כבויה, לכן המנהרה עולה, tailscale ping ל-VPS עובד, אך כל כתובת חיצונית נכשלת ב-timeout. בדקו זאת באמצעות sysctl net.ipv4.ip_forward, שחייב להציג את הערך 1.

האם עלי לאשר את ה-exit node ידנית בכל פעם?

המתג הוא פעולה חד-פעמית עבור כל מכונה. אם אתם בונים מחדש את ה-VPS לעיתים קרובות, הוסיפו בלוק autoApprovers לקובץ מדיניות ה-tailnet שלכם המכיל את "exitNode": ["tag:exit"], הגדירו את tag:exit תחת tagOwners, והעלו את הצומת באמצעות --advertise-tags=tag:exit. התקן מתויג (tagged) שייך ל-tailnet ולא לחשבון המשתמש שלכם, לכן גם חוקי הגישה החלים עליו משתנים.

באיזה שרת DNS משתמש המחשב הנייד שלי כאשר ה-exit node פעיל?

ב-exit node עצמו. התקן המשתמש ב-exit node שולח את כל שאילתות ה-DNS אליו, וזה עוקף את שרתי ה-DNS הגלובליים והמפוצלים שהוגדרו עבור ה-tailnet. הדבר מונע מהרשת המקומית לראות את השמות שאתם מחפשים. כדי לשמור על שרת שמות של ה-tailnet פעיל, הפעילו את האפשרות Use with exit node עבורו בדף ה-DNS במסוף הניהול. שמות MagicDNS עדיין יתורגמו, מכיוון שלקוח ה-Tailscale משיב עליהם מקומית ב-100.100.100.100.

האם VPS אחד יכול לשמש כ-exit node וכ-subnet router בו-זמנית?

כן. sudo tailscale set --advertise-exit-node ו-sudo tailscale set --advertise-routes=10.0.0.0/24 הם עצמאיים, וכל אחד מקבל מתג אישור משלו תחת Edit route settings. שניהם דורשים הפעלה של העברת IP ב-VPS. הימנעו מפרסום טווח כתובות התואם לרשת הביתית של המחשב הנייד שלכם, מכיוון שהנתיב המפורסם ספציפי יותר מנתיב ברירת המחדל, והתקנים מקומיים שלכם יהפכו לבלתי נגישים.

האם ה-exit node מסתיר את התעבורה שלי מספק ה-VPS שלי?

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