איך לנעול את היציאה של לינוקס כדי ששום דבר לא ידלוף כשהחיבור ל-VPN נופל

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

יציאה מקומית היא וו אחר מהעברה

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

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

כתבו את רשימת החריגים מנקודת הקצה החוצה

התחילו בנקודת הקצה של המנהרה: כתובת יעד אחת או קבוצה קטנה ומאושרת, פרוטוקול התעבורה ופורט היעד, למשל udp dport 1194 ip daddr 203.0.113.7 accept. אם הלקוח מפענח שם מארח, חילופי ה DNS הראשוניים צריכים כלל משלהם המוגבל למפענח ולפורט 53, ולא היתר גורפות לכתובת של אותו מפענח. כל חריג צריך לציין את הסיבה לקיומו. היתר לכל תעבורת UDP לפורט ה VPN מכסה הרבה יותר מאותו שירות מאומת יחיד שהיה לכם בראש.

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

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

התאמת ממשק אינה הוכחה למנהרה בריאה

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

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

מה שורד קריסה של הדמון

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

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

נתיב התאוששות לפני הפריסה

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

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