מה route-nopull של OpenVPN באמת מונע מהשרת לדחוף
route-nopull מפיל מסלולים ואפשרויות DHCP שנדחפים, לא את לחיצת היד. בחרו בין זה, pull-filter או כלום, ואז הוסיפו את המסלולים בעצמכם.
שמתם route-nopull בפרופיל לקוח כדי למנוע מהמנהרה לבלוע את ברירת המחדל שלכם, ועכשיו תת־הרשת של המשרד אינה נגישה בעוד הלקוח עדיין אומר שהוא מחובר. שתי התצפיות נכונות, ושום דבר לא נכשל. הדגל אומר ללקוח לדלג על המסלולים ועל רשומות ה-DHCP שהשרת דוחף, הוראה צרה יותר ממה שרוב האנשים מצפים לה כשהם מוסיפים אותה. מה שנשאר הוא מנהרה עובדת בלי דעה לגבי אילו יעדים צריכים להשתמש בה.
הפער הזה הוא כל ההחלטה שהמאמר הזה עוסק בה. או שהשרת מתאר את הרשת, או שהלקוח עושה זאת, והדגל מעביר את המשימה הזו ללקוח בלי לעשות ממנה דבר עבורכם.
מה הדגל מכבה בזמן החיבור
לקוח OpenVPN שמושך מקבל בדרך כלל מהשרת לאחר האימות חבילה: מסלולים, הפניה מחדש של שער ברירת המחדל, שרתי DNS וכמה הנחיות כיוונון. כשהדגל route-nopull בתוקף הלקוח עדיין מקבל את הסשן, עדיין מאמת תעודות, עדיין מנהל משא ומתן על צפנים ועל keepalive, ועדיין מעלה את הממשק. מה שהוא מפיל הוא ההחלה של שורות route שנדחפות ושל שורות dhcp-option שנדחפות, כולל DNS.
הבלבול נובע ממחוון ירוק שליד יישום מת. המנהרה קיימת; המיפוי של יעדים למנהרה הזו לא. שום דבר בלוח המצב של הלקוח לא מבדיל בין «מחובר ומנתב» לבין «מחובר ולא פעיל», כי מנקודת המבט של המנהרה שני אלה הם אותו מצב.
למה מנהרה חיה עדיין לא מנתבת דבר
הממשק מופיע עם הכתובת שלו ובקישור מנקודה לנקודה לרוב אין בו משהו ספציפי יותר ממסלול מארח אל העמית. תת־רשת פרטית נעשית נגישה רק כשמסלול כלשהו מצביע על הממשק הזה עם הקידומת הנכונה, וכשהדחיפה כבויה המסלול הזה לא מגיע לעולם. גם הפרופיל שהורד בדרך כלל לא יכול לעזור, כי הוא נכתב בהנחה שהשרת יספק בדיוק את המידע הזה. לכן הממשק יכול להיראות בריא בעוד תת־הרשת נשארת חשוכה.
קריאת הפרופיל מוכיחה אפוא מעט מאוד. קראו את המצב הרץ, במכונה המחוברת:
ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10כתובת בלי מסלול תת־רשת בפקודה השנייה היא החתימה של הבעיה הזו. הפקודה השלישית עונה אז על השאלה שבאמת מעניינת משתמשים, כי היא מדווחת על הממשק שהליבה הייתה בוחרת עבור יעד מסוים ולא על הרשימה שקיוויתם שתשתמש בה. אם היא עונה דרך הקישור הפיזי שלכם, המנהרה בכלל לא בנתיב.
פתרון שמות נכשל מסיבה קשורה, לא מסיבה נפרדת. רשומות dhcp-option DNS שנדחפות מדולגות באותו דגל, כך ששאילתות על מארחים פנימיים הולכות לכל פותר שהרשת המקומית סיפקה. לפותר הזה אין אזור למשרד, כך שהשאילתה נכשלת או מחזירה תשובה ציבורית, והכשל נראה כמו בעיית שרת כשהוא בעיית תצורת לקוח. בדיקת כתובת לפני שם היא מה שמפריד בין השניים.
הבחירה בין הדגל למסנן קידומות
שתי האפשרויות פותרות צורות שונות של אותה תלונה, ובחירה גרועה היא מה שיוצר את המצב של מחובר אבל חסר תועלת. האחת מחליפה את המדיניות שנדחפת לגמרי, והאחרת עורכת אותה לפי קידומת. הטבלה נותנת את הגרסה הקצרה, והפסקה שאחריה מכסה את החלק שתופס אנשים.
| Setting | What the client keeps | Reasonable when |
|---|---|---|
| no option | every pushed route and DHCP entry | the server's view of the network is correct |
route-nopull | the session, none of the pushed routing or DNS | you will write the full local policy yourself |
pull-filter | everything except lines matching your prefixes | the push is nearly right and one or two lines are wrong |
pull-filter הוא מתאים קידומות עם שלושה פעלים, כך שהוא יכול לקבל משפחה של שורות, להתעלם מהן בשקט או לדחות את החיבור לחלוטין כשקידומת מופיעה. ההתנהגות האחרונה היא זו שכדאי להכיר: כלל דחייה הופך מחלוקת מדיניות ללחיצת יד כושלת במקום להשמטה שקטה. המדריך של OpenVPN 2.6 מפרט את הקידומות המתקבלות ואת המשמעות המדויקת של כל פועל.
דרך אמצע נפוצה היא לדחות רק את redirect-gateway ולתת למסלולי המשרד ול-DNS להגיע כמתוכנן. זה משאיר את הדחיפה עובדת עבור החלקים שהשרת מבין טוב מכם, ובו בזמן מונע את השורה האחת שהייתה משתלטת על ברירת המחדל שלכם.
הוספת מסלולים ופותר ביד
אם אתם משאירים את הדגל, הפרופיל חייב לומר את מה שהשרת היה אומר. הנחיות route בצד הלקוח מוחלות לאחר שהחיבור נוצר, כך שהן פועלות לצד הדגל ולא נחסמות על ידו. שימו אותן בפרופיל, לא בשורת פקודה אינטראקטיבית, אחרת החיבור הבא לא ישחזר את המצב העובד.
route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53שורת ה-DNS נמצאת בעמדה לא נוחה: זו הנחיה בצד הלקוח, אבל חלק מהלקוחות מיישמים אותה רק דרך שילוב ה-DNS של הפלטפורמה, שעלול לדרוס אותה כשהקישור משתנה. במארח systemd, הגדרת הפותר ישירות על ממשק המנהרה צפויה יותר מלקוות שהלקוח ינצח בתחרות העדיפויות:
resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.comתחום הניתוב חשוב כמו הכתובת. בלעדיו שאילתות על שמות ציבוריים עלולות גם להישלח לפותר הפנימי, וכל פותר פנימי שמסרב רקורסיה ישבור גלישה בעוד האזור הפרטי ממשיך לעבוד. איתו רק שמות מתחת לסיומת הזו מנותבים לפותר המנהרה וכל השאר הולך לפי הקישור הפיזי.
בדיקת התוצאה: כתובת, שם והנתיב החיצוני
שלושה מבחנים מפרידים בין הכשלים האפשריים. הביאו את הכתובת הפרטית לפי IP, אחר כך את אותו מארח לפי שם, אחר כך אתר ציבורי רגיל. IP שעובד עם שם שנכשל מצביע על הפותר; IP שנכשל עם שם שעובד מצביע על הניתוב; כשל של שניהם בדרך כלל אומר שהמנהרה לא בנתיב.
אחר כך הביטו החוצה ולא פנימה. המסלול של נקודת הקצה של המנהרה עצמה חייב לשרוד את השינוי, וכל כשל חוסם חייב להיות מוגבל למנהרה בלי לתפוס את נקודת הקצה. לקוח שממשיך לגלוש אחרי שהמנהרה נופלת הוא בעיית מדיניות, לא בעיית ניתוב, והיא לא תופיע באף אחד משלושת המבחנים למעלה.
כתבו את הרשימה הסופית בתיעוד הפרופיל: המסלולים, הפותר, התחומים והסיבה שקיים כל אחד. חיבור מחדש שמשחזר את אותה טבלה הוא ההוכחה היחידה שהמדיניות המקומית שלמה. אם יישומים עדיין נכשלים כשהמנהרה למעלה וכל שלושת המבחנים עוברים, המקום הבא להסתכל בו הוא סוג הבעיות של מחובר אבל לא מקוון ולא תעודות שכבר אומתו.