מה חייב VPS לאפשר לפני שהוא יכול לארח את ה-VPN שלך

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

אשרו את הממשק שהפרוטוקול צריך

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

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

sudo ip tuntap add dev tun9 mode tun
sudo ip tuntap del dev tun9 mode tun
sudo ip link add wgtest type wireguard && sudo ip link del wgtest

סירוב בזוג הראשון פירושו ש-TUN אינו זמין ושמצב ברירת המחדל של OpenVPN אינו יכול להתחיל; סירוב בשורה האחרונה פירושו שממשק הגרעין של WireGuard חסר. תיעוד הגרעין על TUN/TAP מתאר את ההתקן שהבדיקה הראשונה מתרגלת. אף אחד משני הכשלים אינו מתוקן על ידי התקנה מחדש של חבילת ה-VPN.

זכרו שלנתיב הנכנס יש שני בעלים

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

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

תכננו את נתיב החזרה, לא רק את היציאה

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

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

sysctl -n net.ipv4.ip_forward
sudo nft list ruleset | head -n 40
ip -4 route show default

הכריעו בשאלת IPv6 במפורש

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

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

הוכיחו את זה מלקוח חיצוני

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

sudo wg show wg0 latest-handshakes
ip -4 route get 203.0.113.44
sudo journalctl -u wg-quick@wg0 -n 15 --no-pager

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