שרת VPN ביתי מול שרת ענן: איזה מהם מגיע ל‑NAS שלך?
המנהרה עולה, אבל ה‑NAS הביתי נשאר בלתי נגיש. בחרו את מיקום הקצה לפי המשאב שאליו חייבים להגיע, ואז בדקו את המסלול.
המנהרה עולה, הלקוח מציג נקודה ירוקה, ו‑ssh 192.168.1.20 עדיין תלוי עד לפקיעת הזמן. נתקלתי בדיוק בזה אחרי ששכרתי מופע ענן קטן והתקנתי עליו WireGuard: לחיצת יד תקינה, DNS תקין, וה‑NAS על שולחני בלתי נגיש כאילו היה על הירח. לא היה שום פגם במנהרה. הקצה חנה ברשת שאין לה מסלול אל הבית שלי. מיקום הקצה קובע אילו רשתות שכנות, לכן בחרו אותו לפי המשאב שאליו צריכים להגיע קודם והשוו אחסון שני.
מנהרה מגיעה רק לרשתות שהקצה יכול לנתב
VPN נותן ללקוח שלכם כתובת בתוך תחום הניתוב של הקצה עצמו. כשהלקוח שולח מנה אל 192.168.1.20, הקצה חייב לדעת לאן היא הולכת. הטבלה של מופע ענן מכירה את תתי־הרשת של VPC של הספק; על ה‑LAN שלכם היא מעולם לא שמעה. מחובר ונגיש הם שני עובדות שונות, ורוב הבלבול בין בית לענן נובע מלקחת את הראשון כהוכחה לשני.
פקודה אחת מכריעה. בקצה, ip route get 192.168.1.20 או מציין ממשק LAN או מצביע על מסלול ברירת המחדל. במחשב ביתי התשובה היא צד ה‑LAN. במופע ענן המנה יוצאת אל האינטרנט ומתה. הפעלת net.ipv4.ip_forward=1 והוספת כלל MASQUERADE לא משנה זאת, כי אין לאן להעביר עד שמשהו בצד הבית מסיים קישור אל הענן.
למקרה הביתי יש חצי שני: מסלול החזרה. מנות שיוצאות מה‑LAN דרך תיבת המנהרה עוברות NAT, או שה‑LAN צריך מסלול סטטי חזרה אל תת־הרשת של המנהרה. כשפועל רק כיוון אחד, בדקו sysctl net.ipv4.conf.all.rp_filter. סינון מסלול הפוך קפדני מפיל תשובות שמגיעות בממשק שונה מזה שהמסלול חוזה, והתסמין נראה בדיוק כמו כלל חומת אש.
קראו את התסמין לפני שנוגעים בתצורה
המנהרה לא נוצרת: מפתחות, כתובת קצה או פורט UDP חסום. מנהרה למעלה אבל מארחי LAN מתים: מיקום וניתוב. מנהרה למעלה אבל גלישה מתה: העברה, NAT או DNS. אלה שלוש שכבות ושלוש בדיקות שונות, ולכתוב מחדש תצורה שכבר הייתה נכונה מבזבז ערב.
| Symptom | First suspect | Check |
|---|---|---|
| Handshake fails, no transfer | Keys, endpoint port, UDP blocked | wg show, then the port from outside |
| Peer pings, LAN host times out | No route to the LAN | ip route get on the endpoint |
| Tunnel up, name resolution fails | DNS options in the peer config | Resolve a name from the client |
| Large transfers reset the connection | MTU | Lower the tunnel MTU and retry |
נגישות נכנסת מהבית ראויה לבדיקה נפרדת, כי היא קובעת אם אחסון בבית אפשרי בכלל. השוו את כתובת ה‑WAN שהנתב מדווח עליה לכתובת שמארח חיצוני רואה. אם היא נופלת ב‑100.64.0.0/10, או שהשתיים לא מסכימות, אתם מאחורי NAT של ספק ואין העברת פורט שתעבוד אי פעם. האפשרויות האמיתיות הן ממסר, קישור ענן שמחייג החוצה מהבית, או העברת הקצה.
מה אחסון בבית נותן ומה הוא עולה
הבית הוא המיקום היחיד שנמצא בתוך ה‑LAN כברירת מחדל, וזו כל הסיבה לשים שם שרת. התקנים שעונים רק בסגמנט המקומי, כמו מדפסות ועמודי ניהול NAS שדוחים תת־רשתות לא מקומיות, עובדים בלי ניתוב נוסף. אתם גם מפעילים בעצמכם את המכונה, הנתב והקישור.
העלויות פיזיות. העלאה ביתית היא התקרה לכל הלקוחות בבת אחת, כך ששיחת וידאו וגיבוי מתחרים על אותו צינור. חשמל, שחיקת דיסק, עדכונים, כתובת דינמית שזקוקה ל‑DDNS, נתב שחייב להעביר UDP פנימה, ואולי NAT כפול — הכול נופל עליכם. מה שאנשים מדלגים עליו הוא שחזור: אם התיבה מתה כשאתם בחוץ, הדרך היחידה שלכם הביתה מתה איתה. החזיקו התקן שני עם אותם מפתחות, או לפחות תוכנית לגישה פיזית.
אם רוצים גישה ל‑LAN בלי התיבה בבית, בנו קישור במקום להעמיד פנים. קצה הענן הופך לנתב: מנהרה מהצד הביתי עם AllowedIPs = 192.168.1.0/24 על ה‑peer בענן, ועוד העברה ו‑NAT על תיבת הענן. מדריך ההעברה של strongSwan עובר על חצי החזרה של התצורה הזו, ושם רוב הניסיונות האלה נכשלים. ה‑peer הביתי צריך כעת להיות למעלה כדי שמשהו יעבוד, כך שהחלפתם תלות אחת באחרת וכדאי לרשום זאת.
למה קצה ענן באמת מיועד
קצה ענן משנה את היציאה הציבורית שלכם. התעבורה יוצאת מטווח הכתובות של הספק, ואתרים רואים את הכתובת הזו במקום זו הביתית. זה הערך, ולכן VPN בענן לא נותן לכם את ה‑NAS: העברתם את היציאה, לא את ה‑LAN.
אתם עדיין מפעילים את מערכת האורח, את שירות ה‑VPN ואת פרטי הגישה שלו בזמן שהספק מפעיל את ההיפרוויזור ואת הרשת הפיזית, והחלוקה הזו חשובה כשמשהו נשבר בשעה 2 לפנות בוקר. קצה ציבורי נסרק ברציפות, לכן השאירו את פורט הניהול סגור, אפשרו רק את פורט ה‑VPN ועדכנו לפי לוח זמנים. קבוצות אבטחה וחומות אש של הספק חייבות לאפשר את הפורט הזה, ועננים מסוימים מפילים תעבורה מועברת אלא אם תכווננו בדיקת מקור ויעד במופע.
מופע קטן מכסה קומץ לקוחות, אבל הצפנה היא עבודת CPU, ומופע burstable שנגמרו לו הקרדיטים מתנהג באופן לא אחיד תחת עומס מתמשך. הסתכלו על המסלול שבאמת משתמשים בו, לא על דף המפרט.
החלטה שאפשר לרשום
המשימה קובעת את המיקום, לא התווית על התיבה. אם צריך התקן ב‑LAN הביתי, התשובה הנכונה הזולה ביותר היא קצה בבית; תיבת ענן עובדת רק אחרי שבניתם את הקישור חזרה. אם צריך יציאה ציבורית אחרת, הענן הוא התשובה ושאלת ה‑LAN כלל לא עולה. לרצות את שניהם זה לגיטימי, אבל זה אומר שני קצוות, שתי ערכות מפתחות ושני מסלולים מתועדים.
| What you need | Endpoint location | What else must exist |
|---|---|---|
| Reach a NAS or printer on the home LAN | A box on that LAN | Port forward or relay, DDNS, recovery plan |
| Browse from an exit unrelated to home | Cloud instance | Firewall and egress rules, patching |
| Both, reliably | Two endpoints, or cloud plus a link home | Separate keys, routes, documented failure modes |
אמתו מהלקוח לפי הסדר: לחיצת יד, כתובת peer, מארח LAN, ואז IP היציאה. curl -s https://ifconfig.me מראה מה האינטרנט רואה, ו‑ip route get 192.168.1.20 מראה מה הקצה חושב. כשבדיקת היציאה עוברת ובדיקת ה‑NAS תלויה, כבר יש לכם תשובה על המיקום; כוונון AllowedIPs בלקוח לא ייצור מסלול. שורה מפוצלת כמו 10.8.0.0/24, 192.168.1.0/24 שומרת תעבורת LAN בתוך המנהרה רק כשהמסלול הזה באמת קיים.