מנעו מלקוחות VPN להגיע זה אל זה בתוך המנהרה

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

מסלול לשירות המשותף אינו הרשאה בין עמיתים

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

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

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

גלו מי באמת מעביר את חבילת העמית

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

WireGuard שייך לקבוצה הראשונה: אין בו מתג בין עמיתים, ולכן חבילה מ-10.8.0.4 ל-10.8.0.5 מגיעה ב-wg0, פוגעת בקרס ההעברה ומנותבת שוב מחוץ ל-wg0 כש-AllowedIPs מכסה את שתי הכתובות. OpenVPN הוא הקבוצה השנייה ברגע ש-client-to-client מוגדר בקונפיגורציית השרת, משום שהנחיה זו מוסרת את החבילה בין הפעלות במרחב המשתמש. בדקו את הקונפיגורציה הטעונה אחר ההנחיה הזו לפני שתכתבו משהו. כלל גרעין שלעולם אינו רואה תעבורה אינו ניתן להבחנה מכלל שעובד, וכך פריסה מסתיימת בלי שום בידוד.

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

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

תנו לכל כתובת זהות שאפשר לבטל לבדה

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

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

שימו את החסימה במקום שבו החבילה חוצה את המנהרה

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

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

nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.2.0/24 accept
nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.0.0/24 drop

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

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

הוכיחו את החסימה מלקוח, לא מהשרת

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

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

ping -c 3 -W 2 10.8.0.5
nc -z -w 2 10.8.0.5 22
nft list chain inet filter forward
iptables -vnL FORWARD
ping -6 -c 3 -W 2 fd00:8::5

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