משתמש MikroTik VPN מגיע רחוק מדי: הגבילו למארח אחד ולפורט אחד

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

האימות נגמר במקום שבו ההרשאה מתחילה

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

בדקו לאיזה מסלול מתייחסת הבקשה לפני שכותבים משהו. תעבורה למארחים שמאחורי הנתב עוברת ב-forward, ואילו תעבורה לנתב עצמו, כולל winbox ו-SSH, עוברת ב-input. היקף שמכסה רק forward משאיר את המכשיר פתוח לאותו לקוח.

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

צרפו את המושב לרשימה בעלת שם

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

צרו קודם את הפרופיל, ואז קשרו אליו את ה-secret במפורש. secret שעדיין מצביע לפרופיל ברירת המחדל משחזר את הבעיה המקורית.

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

/ppp profile add name=scoped-consultant remote-address=consultant-pool address-list=vpn-scoped-clients
/ppp secret add name=consultant password=... service=ovpn profile=scoped-consultant

רשמו את השירות המותר ברשימה אחת

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

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

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

/ip firewall address-list add list=vpn-targets address=10.0.0.10 comment="consultant RDP target"

סדרו את הקפיצה לפני כל accept רחב

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

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

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

/ip firewall filter
add chain=forward action=jump jump-target=scoped-vpn src-address-list=vpn-scoped-clients
add chain=scoped-vpn action=accept protocol=tcp dst-address-list=vpn-targets dst-port=3389
add chain=scoped-vpn action=drop

אמתו באמצעות מונים וחברות ברשימה

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

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

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

/ip firewall filter print stats where chain=scoped-vpn
/ip firewall address-list print where list=vpn-scoped-clients