הגישה ל-LAN דרך OpenVPN שבורה? בדקו אזורים, מסלולים ונתיב חזרה

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

איזה מסנן רואה חבילה המיועדת ל-LAN

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

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

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

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

למה מנהרה מפוצלת זקוקה לקידומת שנדחפת

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

push "route 192.168.50.0 255.255.255.0"

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

ip route show | grep 192.168.50

עמית מאתר לאתר מבקש יותר מדחיפה. השרת חייב ללמוד אילו קידומות נמצאות מאחורי אותו עמית, וזה מה ששורה iroute בקובץ ה-client-config-dir שלו עושה, וגם הטבלה שלו זקוקה למסלול מתאים אל תוך המנהרה.

התשובה זקוקה לכתובת שהיא יכולה להגיע אליה

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

tcpdump -ni tun0 host 192.168.50.20

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

סולם שמסתיים במקום הנכון

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

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

שמות שייכים לסוף הסולם, לעולם לא להתחלה. שיתוף שמשיב כ-192.168.50.20 אבל לא כ-nas.local מצביע על פתרון שמות או על סיומת חיפוש, ועריכות בחומת האש לא יכולות לשנות אף אחד מהם.

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