מתג נפילה בנתב שמכסה FORWARD, OUTPUT ו-IPv6
מתג נפילה ב-FORWARD בלבד משאיר את הנתב חופשי לדלוף, וכללים של IPv4 בלבד משאירים את IPv6 פתוח. סדרו את השרשראות ובדקו כשהמנהרה למטה.
אתם מתחברים לנתב, מדביקים סט כללים של מתג נפילה מהודעה בפורום, וה-LAN מפסיק לגלוש ברגע שהמנהרה נופלת. יומיים אחר כך הנתב עדיין מעדכן את רשומת ה-DNS הדינמית שלו דרך ה-WAN הרגיל, והמחשב הנייד של האורחים עדיין מגיע לאתרי IPv6. שתי ההתנהגויות נורמליות, כי הכללים שהודבקו כיסו שרשרת אחת ומשפחת כתובות אחת, ואף אחד מאלה אינו הנתב כולו. מעבר על מסלולי החבילות לפי הסדר מראה בדיוק מה הוחמץ.
התחילו בנתב, לא במחשב הנייד
מדיניות ברמת הנתב מושכת משרד קטן כי כל מכשיר שמאחוריה יורש את אותה התנהגות ואיש לא יכול לשכוח להפעיל מתג במחשב הלקוח. היא גם נותנת לכם מקום אחד לבדוק אחרי כל עדכון קושחה. מה שהיא לא נותנת הוא כיסוי אוטומטי של התעבורה של הנתב עצמו או של משפחת כתובות שנייה, ואלה שני הפערים שמאחורי רוב הפריסות שנכשלו.
לפני שאתם עורכים משהו, רשמו שלוש עובדות על נייר: שם ממשק ה-WAN, שם גשר ה-LAN, והכתובת והפורט של נקודת הקצה של ה-VPN. תזדקקו לשלושתם בכללים, וניחוש שמות ממשקים הוא הסיבה הנפוצה ביותר לכך שסט כללים שנראה נכון לא עושה דבר.
עברו על שלושת המסלולים שחבילה יכולה לעבור
תעבורה ממחשב נייד לאינטרנט מועברת הלאה, ולכן היא עוברת דרך שרשרת FORWARD. תעבורה שהנתב עצמו מייצר, כמו העברת DNS, שאילתות NTP, עדכוני DDNS וערוץ הבקרה של ה-VPN, עוברת דרך OUTPUT. תעבורת ניהול שממוענת לנתב מגיעה דרך INPUT.
מתג נפילה שנבנה רק ב-FORWARD מגן אפוא על הלקוחות ולא על דבר אחר. הטבלה מראה מדוע הדליפה בסצנת הפתיחה צפויה ולא מסתורית.
| Packet path | Example | Chain that sees it |
|---|---|---|
| LAN client to WAN or tunnel | Browser request | FORWARD |
| Router-originated | DDNS update, NTP | OUTPUT |
| Addressed to the router | SSH from the LAN | INPUT |
ברוב התכנונים אין צורך במתג נפילה ב-INPUT, אבל חייבים לשמור על גישת הניהול עובדת כשהמנהרה למטה. אחרת, בפעם הראשונה שה-VPN נכשל, נוסעים למשרד עם כבל קונסול.
סדרו את הכללים כך שהמנהרה עדיין תוכל לעלות
מתג נפילה שעובד הוא רשימת הרשאות שמסתיימת בדחייה, והסדר הוא מה שהופך אותו למתג נפילה ולא ללבנה. הרשו קודם loopback, את נקודת הקצה של ה-VPN, תשובות לזרימות קיימות ואת ממשק המנהרה; דחו את השאר אחרון.
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 51820 -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o wg0 -j ACCEPT
iptables -A OUTPUT -o eth0 -j REJECTנקודת הקצה חייבת להיות כתובת בשלב זה, לא שם מארח. ברגע שהדחייה הסופית חוסמת את ה-DNS, כלל שמציין את שם המארח של הספק לא יכול עוד להיות מתורגם, ואז המנהרה לא תעלה יותר לעולם לאחר אתחול. אם הספק מחליף נקודות קצה, תרגמו את השם לפני שהמדיניות מיושמת ורעננו את הכלל הזה מאותו סקריפט.
שכפלו את הצורה ב-FORWARD עבור תעבורת הלקוחות, והציבו כלל ניהול מפורש מעל הדחייה. שמרו על כלל הניהול הזה צר אך נגיש, ואמתו אותו בפתיחת הפעלת SSH שנייה לפני שסוגרים את הראשונה. נעילה מחוץ למערכת בזמן שינוי מתג נפילה נפוצה מספיק כדי לתכנן אותה. בנתב שמריץ WireGuard, ה-allowed-ips של העמית קובעים מה נכנס למנהרה, בעוד שהכללים האלה קובעים מה מותר לצאת בלעדיה.
ל-IPv6 דרוש דלת משלו
כל האמור לעיל הוא IPv4. אם ל-LAN שלכם יש IPv6 עובד והמנהרה נושאת רק IPv4, לכל מכשיר מכוסה עדיין יש מסלול ישיר לאינטרנט שהכללים החדשים שלכם לא רואים לעולם. מחשב נייד עם שני סטקים יעדיף אותו בשמחה, ומתג הנפילה ייראה שבור רק למי שבודק עם IPv4.
ip6tables -A FORWARD -i br-lan -j REJECT
ip6tables -A OUTPUT -o eth0 -j REJECT
ip6tables -A OUTPUT -o lo -j ACCEPTגם כאן הסדר חשוב: הרשאת ה-loopback חייבת לבוא לפני דחיית ה-WAN, אחרת שירותים מקומיים בנתב מתחילים להיכשל בדרכים מוזרות. אם הרשת לא משתמשת ב-IPv6 בכלל, פשוט יותר להשבית אותו ב-WAN וב-LAN וזה לא משאיר דבר לשכוח.
חלק מלקוחות ה-VPN מתקינים מסלול ברירת מחדל רק עבור IPv4 ומשאירים את מסלול ברירת המחדל של IPv6 הקיים ללא שינוי. בדקו את טבלת הניתוב אחרי שהמנהרה מתחברת, במקום להניח שהלקוח טיפל בזה.
הוכיחו זאת כשהמנהרה למטה
עצרו את המנהרה מהנתב ובדקו משלושה מקומות בסדר הזה:
# systemctl stop wg-quick@wg0
# ip route get 203.0.113.1
# curl -m 5 -sS http://example.com || echo blocked
# iptables -vnL OUTPUT | head
# ip6tables -vnL OUTPUT | headחיפוש המסלול אומר לכם לאן חבילה הייתה הולכת, והמונים אומרים לכם אם הכללים שלכם אי פעם התאימו. כלל בלי אף חבילה אחרי בדיקה שנכשלה לא מגן על דבר, והסיבה הרגילה היא שם ממשק ששונה מזה שהקלדתם. בדקו במפורש תעבורה שהנתב מייצר, כי בדיקה מצד ה-LAN לא יכולה להפעיל את OUTPUT.
החליטו על מצב הכשל לפני שתזדקקו לו. fail-closed משאיר את הלקוחות לא מקוונים עד שהמנהרה חוזרת; fail-open מחזיר גישה רגילה ל-WAN ומבטל את המטרה עבור התעבורה שאכפת לכם ממנה. מסלול blackhole אל מאגר ה-VPN עם מטריקה גבוהה הוא שכבה שנייה שימושית לתכנוני fail-closed, כי הוא שורד כשמסלול המנהרה נעלם במקום ליפול חזרה לברירת המחדל.
קבלו את התצורה רק כאשר לקוח ב-LAN, בקשה שהנתב מייצר ובקשת IPv6 נכשלים כולם כשהמנהרה למטה, ושלושתם עובדים שוב ברגע שהיא עולה.