האם מנהרה מלאה פשוטה יותר מרשימה ארוכה של מנהרה מפוצלת?

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

התחילו בספירת הכללים שאתם מתחזקים

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

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

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

בדקו אם השער יכול לשאת את ברירת המחדל

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

ip -s link show dev tun0
conntrack -C
ss -s

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

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

ודאו ששירותים מקומיים ו-DNS פרטי עדיין עובדים

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

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

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

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

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

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

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

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