מתג החירום חוסם רק IPv4: למה IPv6 עדיין יוצא

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

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

שני סטים של כללים, שני ברירות מחדל

ב-Linux, iptables ו-ip6tables הם טבלאות נפרדות עם מדיניות נפרדת. הגדרת שרשראות INPUT ו-OUTPUT של טבלת IPv4 ל-DROP לא משנה דבר בטבלת IPv6, שבה ברירת המחדל היא בדרך כלל ACCEPT. אותה הפרדה קיימת ב-nftables, שבו אפשר לבדוק משפחה אחת ולגלות שרק אחת מהן נושאת את הכללים שלך. האסימטריה הזו נורמלית, וזו כל הבעיה.

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

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

מה תצורת הממשק מספרת לך

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

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

# what is actually installed, per family?
sudo iptables -S OUTPUT | head -20
sudo ip6tables -S OUTPUT | head -20

# nftables: inspect each family separately
sudo nft list ruleset inet | head -40

# does this host even have a usable IPv6 path?
ip -6 route show default

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

למה חיפוש אחד אינו כל הסיפור

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

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

בדוק את המצב שבו המנהרה למטה

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

# with the tunnel stopped, does anything still leave?
ip -6 route get 2606:4700:4700::1111
curl -6 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv6.example.net/
curl -4 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv4.example.net/

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

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