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 אם העמית נגיש. הוספת מכונה אחת לרשת של עשרה מחייבת עריכה של עשרה קובצי תצורה, כיוון שכל צד זקוק למפתח של הצד השני. זו הסיבה שכמעט כל הגדרת WireGuard בניהול עצמי היא במבנה של hub and spoke: שרת אחד עם כתובת IP ציבורית, ולקוחות שמתקשרים רק אליו.

ה-control plane מבטל את הצורך בעריכה ידנית. כל צומת נרשם פעם אחת, מקבל כתובת מטווח ה-100.64.0.0/10 CGNAT (כלומר, Carrier Grade NAT), ומקבל את המפתחות הציבוריים של הצמתים אליהם הוא מורשה לגשת. המנהרה נשארת חיבור WireGuard ישיר בין שני עמיתים, והתעבורה שלכם לעולם לא עוברת דרך שרת התיאום. מה שהשרת נושא הוא מטא-דאטה: מי קיים, מהו המפתח שלו, ומי רשאי לדבר עם מי.

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

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

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

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

העלות של ה-control plane עבורך

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

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

העלות השלישית היא חיובים. נכון לאוקטובר 2026, תוכנית ה-Personal היא בחינם עם מספר בלתי מוגבל של מכשירי משתמש עבור עד 6 משתמשים, תוכנית ה-Standard עולה 8$ למשתמש בחודש, ותוכנית ה-Premium עולה 18$ למשתמש בחודש. משק בית נשאר בחינם. צוות של עשרה אנשים לא. השאלה אם תעבור את הגבול הזה נוגעת בעיקר למספר המשתמשים ולא למספר המכשירים, למעט חריג אחד: שרתים ומכשירים מתויגים אחרים (tagged devices) נהנים מהקצאה משלהם. כל תוכנית כוללת 50 משאבים מתויגים, ונכון לאוקטובר 2026, דף התמחור מציין עלות של 1$ לחודש עבור כל משאב נוסף מעבר לכך. כדאי לקרוא מה תוכנית החינם מכסה בפועל לפני שאתה מזמין את המשתמש השביעי או מתייג את השרת ה-51.

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

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

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

ההתקנה קצרה:

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

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

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

צומת יציאה (exit node) מעביר את תעבורת האינטרנט הרגילה של הלקוח – כלומר כל מה שאינו מיועד למכשיר אחר ב-tailnet או לנתיב משנה מאושר – דרך מכונה אחת. זהו אופן הפעולה של מנהרה מלאה (full tunnel) שאנשים מתכוונים אליו בדרך כלל כשהם אומרים "VPN". ב-Linux נדרשות אותן הגדרות IP forwarding שהוצגו לעיל לפני שתפרסמו אותו:

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 אחר. במקרה כזה ה־relay הוא שרת יחיד באזור יחיד, ולא מערך שרתים עולמי. עמיתים הנמצאים בצד המרוחק של כדור הארץ מרגישים את ההבדל הזה. אם אינכם מעוניינים להרכיב את הרכיב הזה בעצמכם, אירוח עצמי של NetBird הוא אפשרות נוספת להשאיר את מישור הבקרה אצלכם, משום שה־quickstart שלו מעלה יחד את שירותי הניהול, ה־signal וה־relay ב־VPS אחד. עם זאת, NetBird אינו שרת Tailscale חלופי שאפשר להחליף בו ישירות את Tailscale כפי שאפשר לעשות עם Headscale: הוא מגיע עם clients משלו ועם מודל מדיניות משלו. לכן קראו כיצד NetBird ו־Tailscale נבדלים בכללי גישה וב־relay לפני שתבחרו בו במקום Headscale.

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

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

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

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

ניתן לשנות את דעתכם בעלות נמוכה. מכיוון ששכבת ה-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 של הנתיב שמתנהגת באותו אופן עם או בלי מישור בקרה.