כתובת peer של PPP או נקודת קצה VPN: מה נכנס ל-via

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

שתי קריאות של שורת ממשק אחת

קחו סשן שבו הממשק מדווח inet 10.64.3.9 peer 10.64.3.1/32. קריאת תת-הרשת מתייחסת ל-10.64.3.9 כמארח בודד על אי /32 ואז מחפשת נתב כדי להגיע לכל דבר שמעבר לו. מכיוון שהכתובת האחרת היחידה בקישור היא ה-peer, הקריאה הזו מציעה בסופו של דבר את 10.64.3.9 עצמו כשער, וזה מעגלי.

קריאת נקודת הקצה היא המתועדת. בממשק נקודה-לנקודה, peer שם את הקצה המרוחק של אותו קישור יחיד, ולכן 10.64.3.1 הוא הצעד הבא השמיש ו-10.64.3.9 הוא תמיד רק כתובת מקור.

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

מה הסשן כבר התקין

לפני שתכתבו טבלה משלכם, הדפיסו מה הגיע עם הקישור. שילוב PPP נתמך מתקין בדרך כלל מסלול התקן ומסלול peer בהקמת הסשן, ושתי הרשומות האלה כבר מקודדות את הקריאה הנכונה.

ip -4 addr show dev ppp0
ip route show dev ppp0
ip route show table main | head -n 5

מסלול התקן כמו 10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 אינו נושא שער כי הממשק עצמו הוא הנתיב. מסלול שמכנה את ה-peer באמצעות via הוא אובייקט אחר עם תוחלת חיים אחרת, והוא נעלם כשהסשן נופל. העתקת אחת משתי הצורות לטבלה מתמשכת בלי לבדוק כיצד היא מותקנת מחדש היא הסיבה הרגילה לכך שמנהרה עובדת מאבדת את המסלול שלה אחרי התחברות מחדש.

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

כלל וטבלה הם החלטות נפרדות

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

חצי מסלול ברירת מחדל אינו מסלול ברירת מחדל. 0.0.0.0/1 אחת מכסה רק את החצי התחתון של מרחב IPv4, ולכן מדיניות שמתכוונת לתפוס הכול זקוקה גם ל-128.0.0.0/1 המתאים, או ל-default אמיתי. קריאת תצורה עובדת והעתקת אחד משני החצאים היא הדרך שבה אנשים מגיעים ללולאת ניתוב שנשברת רק ביעדים מסוימים.

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

שאלו את החיפוש את השאלה שהאפליקציה שלכם שואלת

ip route get פותר נתיב, ip route show מציג רשומות שמורות, והשניים יכולים לחלוק בלי שאף אחד מהם שגוי. כללו את הקשר המקור, כי כללים מבוססי מקור מתאימים רק כשהחיפוש נושא מקור.

ip route get 198.51.100.23 from 10.64.3.9
ip route get 198.51.100.23 from 10.64.3.9 iif ppp0
ip -4 rule show

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

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

היכן ההשוואה מתהפכת

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

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

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.ppp0.rp_filter
sysctl net.ipv4.conf.all.src_valid_mark

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