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

שתי מדיניות, מנהרה אחת

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

התוצאה המעשית היא שמנהרה עובדת לא אומרת דבר על המדיניות השנייה, ומדיניות שנייה נכונה לא הופכת את הראשונה למיותרת.

התירו את המאזין החיצוני בפועל

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

firewall-cmd --get-active-zones
firewall-cmd --zone=public --list-all
firewall-cmd --info-service=openvpn

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

אשרו את היעד המפוענח בנפרד

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

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

למה אמון בממשק הוא הקיצור השגוי

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

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

אמתו שלושה דברים, כולל דחייה אחת

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

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

מאמרים קשורים