WireGuard מול Tailscale ו-Headscale: מה מתאים לכם?

WireGuard מול Tailscale: התשובה הקצרה

הבחירה בין WireGuard לבין Tailscale אינה בחירה בין שני פרוטוקולים שונים, כיוון ש־Tailscale הוא WireGuard. ‏Tailscale מריץ את אותה הצפנה ואת אותה מנהרה (tunnel), ומוסיף עליהן מישור בקרה (control plane): שרת תיאום שמחליף מפתחות ציבוריים, מחלק כתובות, מבצע NAT traversal (מעבר דרך NAT), ואוכף מדיניות גישה. הבחירה שלכם היא כמה מתוך מערך התיאום הזה אתם מעוניינים לנהל בעצמכם.

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

מה ה־control plane באמת מעניק לכם

ל־WireGuard בסיסי אין מנגנון גילוי. כל peer הוא גוש טקסט שאתם כותבים ידנית: מפתח ציבורי, שורת AllowedIPs, ו־Endpoint אם ה־peer הזה נגיש. הוספת מכונה אחת לרשת של עשרה מחייבת עריכה של עשרה קובצי תצורה, כיוון שכל צד זקוק למפתח של הצד השני. זו הסיבה שכמעט כל התקנת WireGuard בניהול עצמי היא במבנה של hub and spoke: שרת אחד עם IP ציבורי, ולקוחות שמדברים אך ורק איתו.

ה־control plane חוסך את העריכה הזו. כל node נרשם פעם אחת, מקבל כתובת מטווח ה־100.64.0.0/10 CGNAT (כלומר carrier grade NAT), ומקבל את המפתחות הציבוריים של ה־nodes שאליהם מותר לו להגיע. המנהרה נשארת חיבור WireGuard ישיר בין שני peers, והתעבורה שלכם לעולם לא עוברת דרך שרת התיאום. מה שהשרת נושא הוא מטא-דאטה: מי קיים, מה המפתח שלו, ומי רשאי לדבר עם מי.

שלושה דברים קונקרטיים נובעים מכך.

NAT traversal. לשני מחשבים ניידים מאחורי שני נתבים ביתיים אין IP ציבורי ביניהם. Tailscale משתמשת ב־STUN (כלומר session traversal utilities for NAT) כדי לגלות את הכתובת והפורט החיצוניים של כל צד, ואז שני הצדדים שולחים חבילות באותו רגע כך שכל נתב רואה זרם יוצא תחילה ומקבל את התגובה. כאשר זה נכשל, התעבורה עוברת ל־DERP relay, שהוא ממסר מוצפן המופעל על ידי Tailscale. הנתונים שלכם נשארים מוצפנים מקצה לקצה דרך הממסר, כיוון שהממסר לעולם לא מחזיק במפתחות. הריצו tailscale status וכל שורת peer תציג direct או relay. הריצו tailscale netcheck כדי לראות איזה ממסר הוא הקרוב ביותר והאם הרשת שלכם מאפשרת UDP בכלל.

סבב מפתחות עם תוקף. מפתחות WireGuard לעולם לא פגים. מפתח שהנפקתם לפני שלוש שנים יעבוד לנצח אלא אם תמחקו את בלוק ה־peer ידנית. Tailscale לעומת זאת מגדירה תוקף למפתחות של nodes, ונכון ליולי 2026 תקופת התוקף המוגדרת כברירת מחדל ב־tailnet חדש היא 180 ימים. מכונה שלא עברה אימות מחדש תפסיק להתחבר. ניתן לבטל את התוקף עבור כל התקן בנפרד, למשל עבור שרת או subnet router שאין איש בסביבתו כדי לבצע login.

מדיניות במקום ניתוב. ב־WireGuard בסיסי, AllowedIPs הוא טבלת הניתוב ורשימת בקרת הגישה בו-זמנית, לכן "alice רשאית להגיע למסד הנתונים" חייב להיות מוגדר כטווח IP. Tailscale מחזיקה קובץ מדיניות נפרד שבו חוקים מציינים משתמשים, קבוצות ותגיות. חוק יכול לקבוע ש־tag:laptop רשאי להגיע ל־tag:db בפורט 5432 ולא לשום דבר אחר, והחוק הזה נשמר גם אם המכונה מקבלת כתובת חדשה.

העלות של מישור הבקרה (control plane)

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

קיימת עלות שנייה שקל לפספס. Tailscale הוא daemon שרץ על כל מכונה, ולכן זו תוכנה שאתם נדרשים כעת לעדכן בכל מכונה. WireGuard בסיסי על Ubuntu 24.04 הוא מודול kernel שמגיע עם ההפצה ומתעדכן יחד עם ה-kernel.

העלות השלישית היא חיובים. נכון ליולי 2026, התוכנית האישית (Personal) היא בחינם עם מספר בלתי מוגבל של מכשירים עבור עד 6 משתמשים, תוכנית Standard עולה 8$ למשתמש לחודש, ותוכנית Premium עולה 18$ למשתמש לחודש. משק בית נשאר בחינם. צוות של עשרה אנשים לא. השאלה האם אתם חוצים את הגבול הזה תלויה במספר המשתמשים ולא במספר המכשירים, וכדאי לקרוא מה התוכנית החינמית באמת כוללת לפני שאתם מזמינים את המשתמש השביעי.

מתי WireGuard בתצורה פשוטה הוא הפתרון הנכון

בחרו ב-WireGuard בתצורה פשוטה כאשר הטופולוגיה היא באמת hub and spoke. שרת VPS אחד עם כתובת IP ציבורית, שלושה או ארבעה התקנים שמתחברים אליו, וללא דרישה שההתקנים הללו יתקשרו זה עם זה. התצורה נכנסת למסך אחד, אין daemon לעדכן, אין חשבון שעלול ללכת לאיבוד, ושום שירות חיצוני לא חוצץ ביניכם לבין השרת שלכם.

זהו גם הפתרון הנכון כאשר ברצונכם להבין את השכבה שעליה הכל בנוי. אירוח עצמי של WireGuard VPN על גבי VPS סוקר יצירת מפתחות, wg0.conf, העברת IP, NAT וכשלי לחיצת יד (handshake), וכל אחד מהמנגנונים הללו עדיין פועל מתחת ל-tailnet. אם אתם עדיין שוקלים את האפשרות הישנה יותר, WireGuard לעומת OpenVPN מכסה את ארבעת המקרים שבהם ל-OpenVPN עדיין יש יתרון.

ההתקנה קצרה:

sudo apt update && sudo apt install -y wireguard
sudo modprobe wireguard && echo ok

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

מתי Tailscale הוא הפתרון הנכון

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

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

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

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

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

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
sudo tailscale set --advertise-routes=192.0.2.0/24

הנתיב נשאר לא פעיל עד שתאשרו אותו ב-admin console, וזה מכוון: צומת אינו יכול להזריק נתיב לרשת שלכם על דעת עצמו. לקוחות Linux זקוקים גם ל-sudo tailscale set --accept-routes, כיוון ש-Linux אינו מקבל נתיבים מפורסמים כברירת מחדל; לכן, נתיב שנראה מאושר בצד השרת עדיין לא יבצע דבר במחשב Linux נייד עד שתגדירו זאת. אם זהו המבנה הרצוי לכם, הרצת נתב תת-רשת על גבי VPS מפרט את שלב האישור והגדרות הניתוב בסדר שמונע מצב של נתיב שעובד רק בחלקו.

צומת יציאה (exit node) מעביר את כל התעבורה של הלקוח דרך מכונה אחת, וזהו התנהגות ה-tunnel המלאה שאנשים מתכוונים אליה בדרך כלל כשהם אומרים "VPN":

sudo tailscale set --advertise-exit-node

ה-flag הזה הוא החלק הקל, ו-הפיכת VPS לצומת יציאה מכסה את מה שבא לאחר מכן: אישור הנתיב ב-admin console, ולאחר מכן תיקון התנהגות ה-DNS וה-IPv6 שעלולים לגרום לתעבורה לצאת בדרך הלא נכונה. אם מה שאתם רוצים להגיע אליו הוא שירות אינטרנט בודד ולא רשת שלמה, serve ו-funnel מציבים HTTPS לפני פורט מקומי יחיד במקום זאת, בין אם עבור ה-tailnet בלבד או פתוח לאינטרנט הציבורי.

מתי Headscale הוא הפתרון הנכון

Headscale הוא מימוש קוד פתוח של שרת התיאום (coordination server), והוא רץ על שרת VPS שבבעלותכם. לקוחות Tailscale הרשמיים מצביעים עליו במקום על השירות המנוהל:

sudo tailscale up --login-server https://headscale.example.com

שום דבר בנתיב הנתונים לא משתנה. זה עדיין WireGuard, ועדיין מדובר בחיבור ישיר בין עמיתים (peers) היכן שהרשת מאפשרת זאת. מה שמשתנה הוא שרשימת הצמתים, המפתחות והמדיניות נשמרים בקובץ SQLite על דיסק שבבעלותכם. אף גורם חיצוני לא יכול לראות את מבנה הרשת שלכם, להשבית את החשבון שלכם או לחייב אתכם לפי משתמש.

המחיר הוא עבודה ממשית. אתם מריצים כעת שירות HTTPS ציבורי, מה שאומר שנדרש שם DNS, תעודה, ו־reverse proxy שמעביר נכון שדרוגי WebSocket. אתם אחראים לזמן הפעילות שלו, ושרת תיאום שאינו זמין משמעו שצמתים חדשים לא יכולים להירשם וצמתים קיימים לא יכולים להתעדכן בשינויים. Headscale נמצא מתחת לגרסה 1.0 והגרסאות המשניות שלו כללו שינויים ששוברים תאימות, לכן קראו את ה-changelog לפני כל שדרוג. הרצת Headscale כשרת שליטה עצמאי של Tailscale מכסה את ההתקנה, config.yaml, מפתחות preauth והפורטים שיש לפתוח.

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

כיצד להחליט במעבר אחד

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

בדקו אם למכונות יש כתובות ציבוריות קבועות. אם רוב המכונות נמצאות מאחורי NAT שאינו בשליטתכם, אתם זקוקים ל-control plane, כיוון שביצוע hole punching הוא החלק המורכב ואין טעם לנסות לבנות אותו מחדש.

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

ניתן לשנות את ההחלטה בעלות נמוכה. מכיוון ששכבת ה-data plane משתמשת באותו פרוטוקול בכל השלושה, המעבר מ-WireGuard בסיסי ל-mesh מנוהל הוא התקנה של לקוח בלבד ולא תכנון מחדש, ומעבר מ-Tailscale ל-Headscale הוא רישום מחדש של כל צומת מול שרת התחברות שונה.

מה אף אחד משלושתם לא מספק לכם

אף אחד מהם אינו firewall. מנהרה (tunnel) מחליטה אילו חבילות מידע יועברו, אך לא אילו שירותים יאזינו. שרת שניתן להגיע אליו דרך המנהרה עדיין נגיש מהאינטרנט בכל פורט שהשארתם פתוח, לכן הקפידו ש־חוקי ה-firewall של UFW ב-VPS ימשיכו לבצע את עבודתם. קובץ המדיניות של Tailscale מצמצם את הגישה של צמתים אחרים, אך הוא אינו משפיע על הממשק הציבורי.

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

FAQ

האם Tailscale הוא רק WireGuard עם תוספות?

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

האם התעבורה שלי עוברת דרך השרתים של Tailscale?

בדרך כלל לא. עמיתים מתחברים ישירות זה לזה ברגע ששרת התיאום ביצע ביניהם היכרות, ו-tailscale status מציג direct בשורות העמיתים הללו. כאשר לא ניתן ליצור נתיב ישיר, התעבורה חוזרת לממסר DERP והשורה מציגה relay. גם אז, הממסר נושא חבילות מוצפנות ואינו מחזיק במפתחות ה-WireGuard הפרטיים שלך, לכן הוא אינו יכול לקרוא את התוכן. הרץ את tailscale netcheck כדי לראות אם הרשת שלך חוסמת את ה-UDP הנדרש לחיבורים ישירים.

האם אני יכול להשתמש ב-Headscale עם האפליקציות הרשמיות של Tailscale?

כן. Headscale מדבר באותו פרוטוקול בקרה, לכן הלקוחות הרשמיים מצטרפים באמצעות sudo tailscale up --login-server https://headscale.example.com. ניתן להפנות אפליקציות שולחן עבודה ונייד לשרת התחברות מותאם אישית, אם כי ההגדרה נמצאת במקום שונה בכל פלטפורמה, והאפליקציות לנייד הן אלו שסביר ביותר שידרשו גרסה ספציפית. בדוק טלפון אחד לפני שאתה מעביר רשת שלמה.

האם אני עדיין צריך לפתוח פורטים עבור Tailscale או Headscale?

לקוח Tailscale אינו זקוק לפורט נכנס, מכיוון שהוא מחייג החוצה לשרת התיאום ושומר על החיבור פתוח. שרת Headscale בניהול עצמי זקוק לפורטים נכנסים: 443 עבור פרוטוקול הבקרה, 80 אם אתה משתמש באתגר תעודת HTTP-01, ו-3478/udp רק כאשר אתה מפעיל את הממסר המוטמע. WireGuard בסיסי זקוק לפורט האזנה UDP שלו, בדרך כלל 51820, פתוח בשרת ובכל firewall רשת נפרד שמפעיל ספק השירות שלך.

מי מבין השלושה הוא המהיר ביותר?

קצב העברת הנתונים זהה, מכיוון שכל השלושה מעבירים חבילות באמצעות WireGuard. ההבדל בא לידי ביטוי בהקמת החיבור ובאיכות הנתיב. WireGuard בסיסי עם Endpoint תקין מתחבר ישירות בכל פעם. Tailscale ו-Headscale מתחברים ישירות ברוב המקרים וחוזרים לממסר כאשר הרשת חוסמת hole punching, ונתיב שעובר דרך ממסר מוסיף השהיה (latency). מדוד את הנתיב שלך עם tailscale ping <node>, שמדווח אם המסלול ישיר או מועבר דרך ממסר, או עם iperf3 דרך המנהרה. אם המספר שמתקבל נמוך משמעותית מקצב הקו שלך בנתיב ישיר, הבחירה בין השלושה אינה הגורם לבעיה, ו-הסיבה הרגילה היא אי-התאמה ב-MTU של הנתיב שמתנהגת באותו אופן עם או בלי מישור בקרה.