נתב LAN ולקוח VPN: שני התקנים, שתי טבלאות ניתוב

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

שרטטו את שתי הקפיצות לפני שנוגעים במסלול

קחו פריסה להמחשה: מארחי LAN ב-192.168.50.0/24, הנתב הרגיל ב-192.168.50.1, לקוח ייעודי ב-192.168.50.15, ורשת LAN מרוחקת ב-10.60.0.0/24 שזמינה רק דרך המנהרה שאותו לקוח מחזיק. אף אחד משני הטווחים הפרטיים אינו חופף לשני, ולמנהרה יש תוכנית כתובות משלה.

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

שלב 1: כוונו את הנתב אל הלקוח, לא אל המנהרה

בנתב ה-LAN, הוסיפו מסלול יעד שהקפיצה הבאה שלו היא כתובת ה-LAN של הלקוח:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

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

בדקו את התשובה של הפקודה השנייה. אם היא מדווחת על הלקוח כ-gateway ועל ממשק ה-LAN כ-device, הקפיצה הראשונה נכונה והעבודה שנותרה היא במכונה השנייה.

שלב 2: תנו ללקוח מסלול משלו בצד המנהרה

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

הסתכלו לפני שמוסיפים משהו:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

מסלול תחילית חסר בכל הטבלאות הוא הממצא שאתם מחפשים. הוסיפו אותו דרך התצורה של המנהרה עצמה, כדי שההתחברות הבאה תתקין אותו מחדש; ip route add ידני נעלם עם הסשן ומחזיר את התקלה בזמן הכי לא נוח. הקפיצה הבאה היא ממשק המנהרה או הכתובת שה-VPN מקצה כעמית, בהתאם ללקוח, וכתובת העמית צריכה לבוא מהפרופיל הנוכחי ולא מהערה ישנה.

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

שלב 3: אפשרו העברת חבילות ובחרו את מסלול החזור

קבלה והעברה הן הרשאות שונות. net.ipv4.ip_forward=1 בלקוח מאפשר מעבר ברמת הקרנל, וכלל חומת אש עדיין צריך לאפשר אותו בין ממשק ה-LAN למנהרה. כלל שמתיר גישה לעמוד הניהול של הלקוח עצמו לא יתיר מעבר אל ה-LAN המרוחק, וההבחנה קלה לפספוס כשאותו מארח עונה לפינגים באופן מקומי.

לצד המרוחק יש את הבעיה המקבילה. הוא חייב לדעת ש-192.168.50.0/24 נגיש דרך הלקוח המאומת הזה. עם OpenVPN זה בדרך כלל אומר מסלול לכל לקוח שנדחף על ידי תצורת השרת, או קובץ ייעודי ללקוח בשרת שמצהיר על ה-LAN שמאחורי הלקוח. בלי זה, ה-LAN המרוחק או מפיל את התגובה או שולח אותה לשער ברירת המחדל שלו, כלומר לאינטרנט.

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

שלב 4: הפכו את שתי ההחלטות לקבועות, ואז בדקו את המסלול האמיתי

לכל מסלול יש בעלים, והבעלים הוא התצורה שמתחדשת בעת האתחול או בעת ההתחברות מחדש. בנתב זה יכול להיות רשומת מסלול סטטי; בלקוח זה יכול להיות פרופיל ה-VPN, NetworkManager או systemd-networkd. אמתו על ידי חיבור מחדש של המנהרה והפעלה מחדש של הלקוח, ואז קראו את הטבלה שוב במקום לסמוך על העריכה.

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

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