לקוחות הוט-ספוט על Pi לא מגיעים ל-LAN הביתי דרך VPN מסוג TUN

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

לקוחות Wi-Fi ו-Ethernet מקומיים מתחברים להוט-ספוט של ה-Pi, מושכים כתובת מטווח ה-DHCP שלו וטוענים דפי אינטרנט בלי תלונות. אותם לקוחות מגיעים לאחר מכן לפסק זמן כשהם פותחים שיתוף קבצים או ממשק ווב ב-LAN הביתי, בעוד ה-Pi עצמו מגיע ל-LAN הזה דרך המנהרה. שום דבר בשכבה האלחוטית אינו שבור. מה שחסר הוא חוזה מנותב: יש להעביר את קידומת ההוט-ספוט לתוך ממשק ה-TUN, ומשהו בצד הבית חייב לדעת איך לשלוח תשובות חזרה אליו. שני החצאים חייבים להתקיים לפני שמנה אחת תוכל להשלים את הלוך ושוב.

שלושה חיבורים עם שלושה תפקידים שונים

גשר Ethernet של לינוקס מעביר פריימים לפי כתובת ה-MAC של היעד. OpenVPN במצב TUN נושא מנות IP ואין לו שכבת MAC כלל, לכן הוספת גשר מקומי אף פעם אינה רושמת את המנהרה כפורט. התיעוד של ליבת TUN/TAP מסביר את ההפרדה הזו: התקן TAP נראה כמו ממשק Ethernet, התקן TUN לא. עיצוב שמגשר בין שני פורטים מקומיים ואז מנתב הוא נתב, ייקראו הממשקים איך שייקראו.

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

השאירו את המודם גם מחוץ לגשר הלקוחות. חיבור PPP אינו התקן Ethernet עם תווית אחרת, והלוגיקה המתועדת של מסלול ברירת המחדל ב-pppd רצה אחרי משא ומתן IPCP ומסירה את המסלול שלה כשהקישור הזה נופל. העתקת תבנית DHCP ושינוי השם של כל usb0 ל-ppp0 לא מוכיחה דבר על שער, מדד או מחזור חיים.

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

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

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

הבריכה הראשונה היא כתובת ה-underlay שספק התקשורת נתן למודם; היא חייבת להישאר מחוץ לכל תוכנית הפונה ללקוחות. השנייה היא תת-הרשת של המנהרה שהשרת בחר, לרוב /24 פרטית משלו. השלישית היא גשר ההוט-ספוט, והרביעית היא קידומת הבית שאליה אתם רוצים להגיע. במהלך הזה ההוט-ספוט מקבל 172.28.90.0/24 עם הגשר ב-172.28.90.1, וה-LAN של שירותי הבית שומר על 192.168.77.0/24, מה שנמנע מברירות המחדל 192.168.1.0/24 ו-10.0.0.0/24 שנתבים לצרכנים מגיעים איתן ומטווח הספק 100.64.0.0/10.

הכריזו על כתובת הגשר כשער בטווח ה-DHCP של ההוט-ספוט ותו לא. לעולם אל תיתנו ללקוחות ההוט-ספוט כתובת בית כשער; אין להם נתיב בשכבת הקישור לקטע הזה.

נתבו כל כיוון בצד שמחזיק בו

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

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

אם ip route get עדיין מדווח על ממשק ה-underlay, עצרו שם; שום דבר בהמשך הנתיב לא יכול לתקן חיפוש שגוי.

להתקנים ביתיים אין מסלול אל 172.28.90.0/24, לכן התשובות שלהם הולכות אחרי שער ברירת המחדל ומתות בנתב. קיימים שני תיקונים נתמכים. או הוסיפו מסלול סטטי בנתב הבית שמפנה את קידומת ההוט-ספוט לכתובת ה-LAN של שרת ה-VPN, או, כשהשרת עצמו הוא השער, רשמו את קידומת הלקוח בטבלת הניתוב של השרת עצמו. במצב ריבוי לקוחות של OpenVPN הספרייה הספציפית ללקוח נושאת את השיוך הזה: קובץ שנקרא על שם השם הנפוץ של תעודת הלקוח, שמכיל iroute 172.28.90.0 255.255.255.0 בתוספת שורת ה-route המתאימה שמתקינה אותו בליבת השרת. מסלול ליבה משוער בשרת אינו אותה הצהרה כמו לומר לשרת איזה לקוח מחזיק בקידומת.

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

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

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

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

חפשו כלל קבלה מ-br0 אל tun0 ואת כיוון התשובה המתאים, וכלל postrouting שעשוי לשכתב את המקור. אם מדיניות השרשרת היא drop ואף כלל לא מתאים, הוסיפו את הקבלות הצרות ובדקו מחדש במקום להפוך את המדיניות ל-accept.

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

ודאו את הלוך ושוב, ואז שברו אותו בכוונה

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

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

קראו את שתי הלכידות יחד. בקשות על br0 שלעולם אינן מופיעות על tun0 אומרות שה-Pi לא מעביר קדימה או שהמסלול מצביע למקום אחר. בקשות על tun0 בלי תשובות אומרות שלצד הבית אין מסלול חזרה או שהשרת סינן את המנה. תשובות על tun0 שלעולם אינן מופיעות שוב על br0 אומרות שכלל הסינון ההפוך חסר, כשהמנהרה נראית מושלמת והלקוח עדיין לא רואה דבר.

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

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

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