משתמש VPN צריך מדפסת אחת, לא את כל ה-LAN

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

התסמין: הכלל הצר לא שינה דבר

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

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

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

לאיזו מערכת כללים התעבורה באמת מגיעה

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

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

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

כתבו את כלל המעבר מתוך משימת ההדפסה

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

התנגדו להוספת פורטי גילוי או ניהול כדי לרצות אשף. כלל שמתיר את כל המדפסת הוא מדיניות שונה מזו שמתירה תור הדפסה.

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

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

תנו ללקוח נתיב בלי הרשאת LAN

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

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

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

בדקו גם את הסירוב וגם את המשימה

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

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