למה כלל חסימת לקוח OpenVPN לא מגיע אף פעם ל-FORWARD

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

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

שני מסלולים שחבילת עמית יכולה לעבור

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

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

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

כאשר המונה לא זז אף פעם

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

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

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

לבחור גבול שיכול לסנן

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

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

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

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

לבדוק בידוד במקום לסמוך על כלל

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

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

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