מחוברים ל-OpenVPN אבל אין פינג או שיתוף SMB? בדקו שלושה שערים

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

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

העברה היא מדיניות בשרשרת FORWARD

קבלת המאזין של OpenVPN מתרחשת ב-INPUT, ולכן המנהרה יכולה להתחבר בזמן שכל מנה המיועדת ל-LAN נזרקת. התנועה שמגיעה ב-tun0 ויוצאת דרך ממשק ה-LAN עוברת ב-FORWARD, ומארח עם מדיניות DROP כברירת מחדל שם זורק אותה בשקט. בדקו גם את ה-sysctl וגם את השרשרת לפני שנוגעים במשהו אחר: sysctl net.ipv4.ip_forward ו-iptables -L FORWARD -v -n.

אפשרו את הכיוון שאתם רוצים ואת התשובות ששייכות לו, למשל כלל accept מממשק המנהרה לממשק ה-LAN ועוד כלל stateful לתנועת established ו-related. אם ה-LAN נמצא מאחורי נתב אחר, אותו נתב צריך מסלול חזרה לבריכת הלקוחות או source NAT בשרת ה-VPN. אשרו את המסלול הזה בפינג אחד לפני שמוסיפים כללים נוספים, כי כלל שאי אפשר להגיע אליו לא מופיע לעולם במונה.

SMB צריך יותר מפורט אחד

שיתוף קבצים אינו שיחה אחת של TCP 445. הגילוי משתמש ב-UDP 137 ו-138, שיחות NetBIOS ישנות משתמשות ב-TCP 139, ושיחות SMB מודרניות משתמשות ב-TCP 445. כלל שפותח רק 445 יוצר את המקרה המרגיז שבו כונן ממופה עובד וגלישה ברשת לא, או להפך.

העברות גדולות דרך מנהרה נתקלות גם בבעיות MSS שנראות כמו שיתוף שבור. SYN שמכריז על גודל הסגמנט המלא של ה-LAN נזרק בגלל ה-MTU הקטן יותר של המנהרה, והחיבור נתקע אחרי לחיצת היד. הידוק MSS במסלול ההעברה, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, מסיר סוג כזה של תקיעה. אמתו עם העתקה של כמה מגה-בייט ולא עם רשימת תיקייה, כי תשובות קטנות עוברות גם כשהעברות גדולות לא.

מתאם המנהרה מגיע כפרופיל רשת חדש

Windows מסווג כל מתאם לפרופיל רשת, ומתאם מנהרה חדש נוחת בדרך כלל ב-Public, שם כללי שיתוף הקבצים והמדפסות חסומים. זו החלטה של חומת האש של המארח בשרת הקבצים, לא בעיית ניתוב בשרת ה-VPN. שנו את הקטגוריה בכוונה עם Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private לאחר שאישרתם שהמדיניות מאפשרת זאת, כי הקטגוריה משנה גם אילו כללי כניסה חלים.

אותו פרופיל מסביר פינג שנכשל בזמן ש-TCP 445 מצליח: בקשות הדהוד נזרקות ב-Public כברירת מחדל.

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

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

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

בדקו שכבה אחת בכל פעם וקראו את הכשל הראשון

התקדמו כלפי מעלה: עשו פינג לשער המנהרה, עשו פינג למארח LAN לפי כתובת, ואז פתחו את פורט השירות עם Test-NetConnection -ComputerName 10.8.0.5 -Port 445, ורק אחר כך הזדהו מול השיתוף. הצעד הראשון שנכשל הוא השכבה שתוקנים, וכל צעד אחריו הוא רעש עד שהוא עובר. פינג שעונה בזמן שהפורט נשאר סגור מצביע על חומת האש של שרת הקבצים עצמו, ואילו פורט שנפתח למרות פינגים שקטים מצביע על סינון ICMP. רשמו את הצעד הראשון שנכשל לפני שמשנים משהו, כי שינוי שני מסתיר את התוצאה של הראשון.

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

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