אחסון אתרים או VPS: האם התוכנית שלך יכולה להריץ שרת VPN?
אחסון משותף, אפליקציה מנוהלת ושרת בניהול עצמי מעניקים שליטה שונה ברשת. השווה ארבע יכולות לפני שאתה קונה או מעביר משהו.
אתר שעובד הוא הוכחה שספק יכול להגיש HTTP, לא שאתה שולט במכונה. בין תוכנית משותפת, אפליקציה מנוהלת ושרת בניהול עצמי יש פער גדול במה שהחשבון רשאי לעשות לרשת. החלט באיזה צד של הפער עיצוב ה-VPN שלך זקוק לפני שאתה משלם לעוד שנה. ארבע יכולות מפרידות בין השניים, ואף אחת מהן לא מופיעה במחירון.
מה כל תוכנית באמת נותנת
ההשוואה השימושית היא לא מחיר או גודל דיסק אלא סמכות. שאל מה החשבון יכול להפעיל, לאילו תכונות ליבה הוא מגיע, אילו יציאות מקבלות תעבורה נכנסת והאם תעבורה מאושרת יכולה לצאת שוב למקום אחר.
רוב מוצרי האחסון נופלים לשלוש צורות, ורק האחרונה היא שרת לשימוש כללי:
| Capability | Website plan | Self-managed server |
|---|---|---|
| Long-running custom process | Usually not permitted | Yours to run under a service manager |
| Virtual network interface | Almost never available | Present when the kernel module and privilege allow it |
| Arbitrary inbound port | Restricted to the web stack | Provider filtering still applies |
| Forwarding for clients | Not offered | Possible once routing and policy are configured |
חשבון מעטפת הוא המקור הרגיל לבלבול. העברת קבצים או גישה למשימות מתוזמנות יכולה להיראות כמו ניהול בעוד התהליך מוגבל לספרייה ולקבוצה קטנה של פעולות מותרות.
ארבע יכולות שמכריעות את התשובה
קח אותן לפי הסדר, כי כישלון בצעד הראשון הופך את השאר לבלתי רלוונטי.
ראשית, התוכנה חייבת לרוץ כתהליך ארוך טווח ששורד תחזוקה. שנית, המימוש חייב להיות מסוגל ליצור את הממשק הווירטואלי שלו; בלינוקס זה בדרך כלל אומר לפתוח את /dev/net/tun בהרשאה הניהולית הרלוונטית, כפי ש תיעוד הליבה של TUN/TAP מתאר, אם כי לא כל עיצוב VPN משתמש בהתקן הזה. שלישית, הלקוחות חייבים להגיע למאזין בכתובת הציבורית, בתעבורה וביציאה שאתה מתכוון אליהן, ופרוקסי הפוך לאתרים שמקבל HTTPS לא אומר דבר על פרוטוקול לא קשור באותו מספר. רביעית, תעבורה מאושרת חייבת להיות מסוגלת להמשיך הלאה, עם מסלולים, העברה וכל תרגום שבאמת נתמך.
תנאי השירות עומדים לצד אותם ארבעה ואינם טכניים כלל. מכסות תעבורה בלתי מוגבלת מתארות בדרך כלל בקשות רשת, לא מנהרה שנושאת הורדות של אחרים. קרא את סעיף השימוש המקובל לפני שאתה מתכנן סביבו, ושמור על גישה לשחזור ליום שבו השירות לא יעלה.
היכן חשבון אתר נעצר
תוכנית אתר מריצה בדרך כלל את הקוד שלך בסביבת הרצה מנוהלת עם נקודת כניסה קבועה. גם כשיש קובץ בינארי של מנהרה, ייתכן שלתהליך אין הרשאה לפתוח צומת התקן, לקשור יציאה מיוחסת או לשנות את טבלת הניתוב. המגבלות האלה הן המוצר, לא מחדל.
לכן תוסף שמבטיח VPN מתגלה בדרך כלל כפרוקסי למקום אחר. אם החשבון הנוכחי מציע רק בקרות אתר, הצעד הישר הוא שרת נפרד, לא חיפוש אחר המודול שפותח את הסמכות החסרה.
כשמארח אחד חייב להריץ את שניהם
שיתוף אפשרי ולפעמים הגיוני, אבל התייחס אליו כהחלטת אבטחה ולא כנוחות. אפליקציית רשת עם טופס העלאה עומדת לצד אישורי מנהרה ושקע בקרה, ופרצה באחת מגיעה לשנייה. חשבונות נפרדים, יחידות שירות נפרדות ומערכות קבצים נפרדות מפחיתים את החשיפה הזו בלי לקנות מכונה שנייה.
תחרות על משאבים חשובה באותה מידה. גיבוי דרך המנהרה ותהליך רשת עמוס מתחרים על אותו קישור עולה ואותו דיסק, והכשל נראה כמו אתר איטי ולא כמו מנהרה רוויה. החלט איזה עומס מנצח לפני התקרית, והגבל את המנהרה כדי שהאתר ימשיך לענות.
אף אחד משני הסידורים אינו מבודד רק מפני ששני השירותים פועלים. היכולת לאחסן אותם יחד היא תחילת התכנון, ועבודת הבידוד היא מה שהופך אותו להגנה.
הכרע את זה במארח ניסיוני עם ארבע פקודות
לפני ההעברה, שכור את המופע הקטן ביותר של המוצר המיועד לשעה ובדוק את ארבע היכולות ישירות. ניחוש מתוך טבלת תכונות מבזבז פחות כסף משנה עם התוכנית הלא נכונה, אבל הרבה יותר זמן.
הרץ את אלה במארח הניסיוני וקרא את הכשלים כתשובות, לא כמכשולים:
ls -l /dev/net/tun
sudo ip tuntap add dev tun9 mode tun && sudo ip link del tun9
sysctl net.ipv4.ip_forward
ss -lunp | headשתי השורות הראשונות אומרות אם התקן מנהרה יכול בכלל להתקיים. השלישית מדווחת אם המארח רשאי להעביר מנות הלאה, והרביעית מראה מה כבר מאזין כדי שתנגשות יציאות תיתפס מוקדם. ספק שנכשל בשורה השנייה עשוי בכל זאת לתמוך במימוש במרחב המשתמש, לכן כשאתה פונה לתמיכה שלהם נקב בשם המנגנון שאתה צריך, לא בקטגוריית המוצר.