ה-pull-filter של OpenVPN תואם ליותר מהמסלול שהתכוונת אליו
pull-filter משווה את הטקסט שלך כקידומת למול אפשרויות שנדחפות, כך ש-route תופס גם route-gateway ו-route-ipv6. בדוק את הפעלים, ואחר כך את המסלולים.
אתה מוסיף שורה אחת כדי לשמור על מסלול ברירת המחדל המקומי שלך, ואחריה המנהרה כבר לא מגיעה לשרת ה-DNS הפנימי. השורה הייתה pull-filter ignore "route", וזה לא אומר "התעלם מהמסלול הזה". זה אומר "זרוק כל אפשרות שנדחפה שהטקסט שלה מתחיל בחמש האותיות האלה", ובשרת רגיל זה כולל את route-gateway, route-metric ו-route-ipv6 יחד עם המסלולים עצמם. רשימת הבדיקה למטה היא מה שאני מריץ לפני שאני נוגע בפרופיל שמישהו אחר צריך להשתמש בו.
המסנן חל רק על אפשרויות שנדחפו
pull-filter פועל על שורות האפשרויות שהשרת שולח לאחר הקמת המנהרה, ועל שום דבר אחר. אפשרויות שנכתבו בקובץ המקומי שלך אינן מושפעות ממנו, וגם לא תעבורת יישומים. אם קיווית למנוע מתהליך להשתמש במנהרה, זה הכלי הלא נכון לגמרי ושום שילוב של מסננים לא יעשה זאת.
ההיקף הזה שימושי, כי הוא אומר שאתה יכול להשאיר את תצורת השרת בשקט ובכל זאת לסרב לחלק ממנה מקומית. זו גם מגבלה שראוי לרשום בכרטיס: מסנן משנה מה הלקוח הזה מקבל, לא מה השרת מציע. אין לו השפעה על משתמשים אחרים באותו פרופיל. הוא גם לא שורד מעבר ללקוח אחר שלא מיישם את האפשרות, וזה ראוי לדעת לפני שבונים עליו תהליך עבודה.
ודא מה השרת באמת שולח לפני שאתה כותב את התבנית. ברמת פירוט גבוהה הלקוח מדפיס את מחרוזת האפשרויות שנדחפה שהתקבלה, וזה המקור היחיד הישר לטקסט המדויק שאתה מתאים לו:
sudo openvpn --config /etc/openvpn/corp.ovpn --verb 4
sudo grep -n 'pull-filter' /etc/openvpn/corp.ovpnקרא את השורה שנדחפה כרשימת אפשרויות המופרדות בפסיקים, ושווה לב ששמות האפשרויות והארגומנטים שלהן מופרדים ברווחים. טקסט המסנן שלך מושווה לזרם הזה, ולכן הרווחים כל כך חשובים בשלב הבא.
ההתאמה היא קידומת, ולכן הרווחים הם כל המשחק
ההשוואה היא קידומת של מחרוזת, לא שם אפשרות מפורק. לכן "route" מתאים ל-route-gateway 10.8.0.1, ל-route-ipv6 2001:db8::/32 ול-route-metric 100. רווח אחד בסוף מצמצם אותו למשפחה שהתכוונת אליה כנראה, והקידומת המלאה מצמצמת אותו עוד ליעד מסוים.
| Filter text | What it actually matches | Typical outcome |
|---|---|---|
"route" | Every option beginning with those letters | Routes, gateway, metric and IPv6 routes all dropped |
"route " | Route entries only, not the hyphenated siblings | The routes go, the rest survives |
"route 10.60." | A single destination range | The narrowest rule, and the easiest to audit |
"dhcp-option DNS" | Pushed DNS settings | Resolver stays local, internal names stop resolving |
השורה האחרונה היא זו שתופסת אנשים בעבודה עם מנהרה מפוצלת. שמירה על resolver משלך היא בחירה לגיטימית, והיא אומרת שכל שם פנימי תלוי כעת ב-resolver שלא רואה את האזור הפרטי. זו תוצאה שמקבלים בכוונה, לא תופעת לוואי שמגלים בייצור.
התאמת קידומת אומרת גם שכלל יכול להתרחב מאוחר יותר בשקט. כשהשרת מוסיף אפשרות חדשה שמתחילה בטקסט שלך, המסנן שלך מתחיל לחול עליה בלי שאיש עורך את הפרופיל שלך. זה מצב הכשל שצריך לתכנן נגדו, וההקלה היא להתאים כמה שיותר מהאפשרות ולא כמה שפחות.
שלושה פעלים עם שלוש תוצאות שונות
accept, ignore ו-reject אינם שלושה איותים של אותו רעיון. הם נבדלים במה הלקוח עושה עם התאמה ובאם מישהו מגלה על כך.
ignore זורק את האפשרות המתאימה בשקט, וזה מה שאתה רוצה בהגדרה שהחלפת בכוונה. reject זורק אותה וגורם ללקוח להתלונן, וזה מה שאתה רוצה כאשר ההיעדר שלה צריך להיראות בלוג במקום להתגלות מאוחר יותר. accept הוא הצורה החיובית, משמשת כשאתה בונה רשימת היתר במקום להסיר אפשרויות בודדות.
יהיה אשר יהיה הפועל שתשתמש בו, המסננים מיושמים לפי הסדר שבו הם מופיעים, ולכן שני כללים חופפים נותנים תוצאה תלוית סדר שקשה מאוד לסקור. החזק כלל אחד לכל כוונה והצב בכל אחד את הטקסט הספציפי ביותר. אם אתה צריך רשימת היתר, העדף מעט כללי accept על פני ערימה של כללי ignore שמסתכמים לאותו דבר. אז הסוקרים יכולים לקרוא את הקובץ מלמעלה למטה ולחזות את התוצאה, וזה המבחן היחיד שמתאים לקנה מידה.
אמת את המסלול וה-resolver שהוחלו, לא את הפרופיל
מסנן שנראה נכון בקובץ עדיין יכול להשאיר אותך עם מנהרה שלא מנתבת שום דבר מועיל. אמת את ההשפעה על המערכת הפועלת, שבה האפשרויות שנדחפו כבר הוחלו או נזרקו:
ip route show default
ip route show | grep -c 'proto static'
resolvectl status | grep -A4 'Link.*tun0'
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://intranet.example.internal/שתי השורות הראשונות אומרות לך אם מסלול ברירת המחדל שנדחף הגיע וכמה רשומות סטטיות שרדו. שאילתת ה-resolver מראה באיזה שרת משתמש בפועל ממשק המנהרה, ובדרך כלל שם מופיעה הפתעת DNS. השורה האחרונה עונה על השאלה היחידה שמשנה למשתמש.
בדוק את שני הכיוונים בזמן שאתה שם. כלל שמשאיר את האינטרנט המקומי שלך עובד אבל שובר בשקט את פתרון השמות הפנימי עובר בדיקה שטחית ונכשל במשימה האמיתית הראשונה, לכן כלול באותה בדיקה גם משאב פנימי וגם אתר ציבורי.
תעד את החריג ומי הבעלים שלו
מסנן הוא חריג בתכנון של המפעיל, לכן רשום אותו עם סיבה ונקודת סקירה. "מתעלם ממסלולים שנדחפו כדי לשמור על ברירת המחדל המקומית" ניתן לסקירה; שורה חשופה בפרופיל לא, והאדם הבא ימחק אותה או ירחיב אותה בניחוש.
גם הגרסה חשובה כאן. התנהגות ההתאמה והתחביר המדויק המקובל עברו עידון לאורך OpenVPN 2.4, 2.5 ו-2.6, לכן אמת את התבנית מול המדריך של הבנייה שאתה מפיץ ולא מול פוסט בפורום על גרסה ישנה יותר. המדריך של OpenVPN 2.6 מתעד את האפשרות ואת כלל ההתאמה שלה.
לבסוף, הסכם על החריג עם מי שמפעיל את השרת. מסנן בצד הלקוח שסותר מדיניות שרת מכוונת הוא תקרית תמיכה שמחכה לביקורת הבאה, והרבה יותר זול לסגור אותה לפני שהפרופיל יוצא מאשר אחרי שמישהו מבחין שהמסלולים חסרים.