למה תגובת ה-DNS נכשלת בחומת אש קצה של VPN חסרת מצב

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

שני החליפינים אינם אותו חליפין

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

query:  203.0.113.10:53018 -> 198.51.100.53:53
reply:  198.51.100.53:53 -> 203.0.113.10:53018

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

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

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

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

בנו את ההרשאה סביב הפרוטוקול, לא סביב מספר פורט

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

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

למה התרת כל פורט מקור 53 אינה תיקון

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

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

אמתו בגבול הנכון, בכיוון הנכון

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

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