לקוח OpenVPN לכל רשת ה-LAN ב-OpenWrt: סדר עבודה נכון

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

החליטו מה חולק את המנהרה

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

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

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

תנו למנהרה בעלים

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

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

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

הגדירו אזור, ואז העבירו אליו

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

config interface 'vpn'
    option device 'tun0'
    option proto 'none'

config zone
    option name 'vpn'
    list network 'vpn'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq '1'

config forwarding
    option src 'lan'
    option dest 'vpn'

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

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

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

ציינו את הקישור העולה האמיתי ב-NAT

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

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

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

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

פצלו את ה-Wi-Fi עם טבלה שנייה

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

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

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

חשדו בשעון ובסימון ההתקן

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

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