VPN ורשת הבית על אותה תת-רשת: קודם לעקוב אחר המסלול
שני המתאמים תובעים 192.168.1.0/24 ומסלול אחד מנצח. עקבו אחר רשימת המתאמים, המסלול המנצח ונתיב החזרה לפני שממספרים מחדש או מאשימים את ה-DNS.
אתם מתחברים ל-VPN של המשרד, הסמל במגש הופך לירוק, האינטראנט נטען, והמדפסת שני מטרים מכאן מפסיקה לענות. השיתוף שעבד הבוקר נכשל בזמן המתנה באותו מחשב, ואף יומן לא מזכיר מדפסת. הרפלקס הוא DNS, כי שם שלא נפתר נראה כמו שם שלא קיים, אבל הבעיה היא בכתובת: שני מתאמים תובעים כעת 192.168.1.0/24 ורק מסלול אחד יכול לנצח בקידומת הזו. עברו על זה בסדר הזה ותראו איזה מתאם לקח אותה לפני שתשנו משהו.
התחילו מהתסמין, לא מהמנהרה
הרמז הוא ההיקף. אם האינטראנט עובד וכל התקן מקומי נכשל, המנהרה תקינה והנתיב המקומי לא. אם התקנים מקומיים עובדים והאינטראנט נכשל, ההפך. אם הכול עובד מלבד מארח אחד, אתם מול כתובת אחת שקיימת בשני הצדדים.
רשמו כתובת מקומית אחת וכתובת מרוחקת אחת לפני שנוגעים בהגדרה. ״המדפסת״ אינה ניתנת לבדיקה; 192.168.1.40 כן. הצעד האחד הזה מונע את השעה המבוזבזת הנפוצה ביותר בבעיה הזו, והיא כתיבה מחדש של הגדרות DNS בגלל החלטת ניתוב.
שלב 1: ראו את שני המתאמים תובעים את הקידומת
פתחו חיבורי רשת (ncpa.cpl) וקראו את שני המתאמים זה לצד זה. מתאם ה-Ethernet מציג 192.168.1.50/24 עם שער 192.168.1.1. מתאם ה-VPN מציג 192.168.1.201/24, שנדחף מהשרת. שניהם לגיטימיים, שניהם מאמינים שהקידומת היא on-link, והמחסנית תשמור מסלול אחד עבורה.
הפקודה Get-NetIPAddress -AddressFamily IPv4 מפרטת את הכתובות, ו- Get-NetIPInterface | Sort-Object InterfaceMetric מציגה את הסדר שבו המחסנית תשתמש בהן. עמודת המדד הזו היא ההחלטה שאתם עומדים לקרוא, לכן רשמו את המספרים במקום לזכור אותם.
הפריכו את תיאוריית ה-DNS בזול: Resolve-DnsName printer.office.lan מחזיר את אותה כתובת שהחזיר אתמול. השם נפתר; החבילה יצאה אז דרך המתאם הלא נכון. שתי דקות כאן חוסכות אחר צהריים בהגדרות הפותר.
שלב 2: קראו את המסלול שבאמת ניצח
Find-NetRoute -RemoteIPAddress 192.168.1.40 מדפיס את הממשק, הקפיצה הבאה והמקור שהמחסנית תשתמש בהם לכתובת הזו. התייחסו לפלט הזה כתשובה, לא כרמז. route print -4 נותן את כל הטבלה כאשר רוצים לראות איזו רשומה הפסידה ובכמה.
ספציפיות מנצחת כוונה. 192.168.0.0/25 שנדחף מנצח 192.168.0.0/24 מקומי כי הקידומת ארוכה יותר, ולכן 192.168.0.0 עד 192.168.0.127 יוצאים דרך המנהרה בעוד החצי העליון נשאר מקומי. היעלמות חצי רשת מקומית בלי הודעת שגיאה היא ההתנהגות הנכונה של הטבלה הזו.
tracert -d 192.168.1.40 מאשר זאת מחוץ לטבלה: אם הקפיצה הראשונה היא כתובת מנהרה ולא הראוטר שלכם, המסלול הוא כל הסיפור. ב-Linux אותה שאלה היא ip route get 192.168.1.40, שמדפיס כתובת מקור והתקן בשורה אחת. כשהתשובה מזכירה tun0, הפסיקו להסתכל בדפדפן.
שלב 3: בדקו את נתיב החזרה לפני שמאשימים את הלקוח
מסלול קדמי תקין עדיין נכשל אם הצד המרוחק לא יכול לענות. כשמגיעים לרשת לקוח דרך המנהרה, השער של אותה רשת חייב לדעת היכן נמצא מאגר המנהרה: ip route add 10.8.0.0/24 via 192.168.1.12 באותו ראוטר, ו- push “route 192.168.1.0 255.255.255.0” מהשרת כדי שהלקוחות ידעו את החזרה.
בלי הרשומה הראשונה התשובה עוזבת את היעד אל שער ברירת המחדל שלו, שמעביר כתובת פרטית לספק וזורק אותה. הסימפטום חד-כיווני וקל לקריאה שגויה: בקשות מופיעות ב- tun0, תשובות לעולם לא.
כלל masquerade במארח ה-VPN מבטל את הצורך במסלול הסטטי הזה: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. הוא גם מסתיר את כתובות המקור האמיתיות, מה שמקשה על כל שאלת יומן מאוחרת. מארח יעד עם שער ברירת מחדל שגוי מייצר את אותה שתיקה, עם הפניית ICMP במקרה הטוב וחור שחור במקרה הרגיל, ולכן הלכידה שייכת לשני הקצוות.
שלב 4: בחרו תיקון שאפשר לחיות איתו
לכך משתמשים בחמישה תיקונים והם אינם ניתנים להחלפה. בחרו לפי מה שחייב להישאר נגיש בו-זמנית, לא לפי איזו פקודה קצרה יותר.
| Repair | What it fixes | What it costs |
|---|---|---|
| Flip interface metrics | Alternating access: office now, home later, never both | Get-NetAdapter -Name "Ethernet 2" | Set-NetIPInterface -InterfaceMetric 21; set the VPN adapter back to 5000. A client that rewrites metrics on connect defeats it |
| Renumber one side | Every host reachable in both directions | DHCP reservations, printer queues, firewall rules and hard-coded addresses all move |
| Narrow the advertised prefix | Remote hosts really live in the upper half | Breaks the day someone adds a host below the cut |
| Translate with client-nat | Both address plans stay untouched | Stateless per-client mapping, unreadable logs, anything embedding addresses breaks |
| Publish one service with DNAT | One service on the VPN host reachable from the LAN | Both address plans stay; source addresses and reverse lookups stop being meaningful |
מדדים הם האפשרות הזולה וזו שאנשים פונים אליה ראשונה. השינוי חל על הממשק, כך שהוא עובד כל עוד המנהרה למעלה, ומקומו בסקריפט לצד הלקוח ולא במעטפת שתשכחו. הוא לא יכול לתת גישה בו-זמנית לאותה כתובת בשתי רשתות, וזה הגבול ששולח את כל האחרים להמשך הטבלה.
מספור מחדש של רשת הבית ל- 10.10.0.0/24 הוא התיקון הנקי: חידוש חכירת DHCP אחת ועוד ההזמנות, תורי ההדפסה והכתובות המקודדות שמזכירות את הטווח הישן. מספור מחדש של צד המשרד בדרך כלל אינו ההחלטה שלכם. IPv6 מבטל את ההתנגשות לגמרי כששתי הרשתות נושאות אותו, עם קידומת מקומית ייחודית מ- fd00::/8 במקום משהו שקל לזכור, אבל בדקו את היישום דרך TCP ולא בפינג, כי ICMP יכול לעבוד בזמן שהשירות לא.
אפשרות התרגום של OpenVPN עצמו היא המוצא האחרון, נדחפת מהשרת לרשומת תיקייה ספציפית ללקוח. היא מקבלת ארבעה פרמטרים אחרי שם האפשרות — כיוון, רשת, מסכה וכינוי — והכינוי אינו אופציונלי: push "route 192.168.2.0 255.255.255.0" ו- push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". הרשת והמסכה הן הטווח שהלקוח רואה (192.168.2.0/24), הכינוי הוא טווח המשרד האמיתי בצד השרת (192.168.1.0/24), והמסלול הנדחף הוא מה שהופך את הטווח הנראה הזה לנגיש. המשרד מופיע אז לאותו לקוח תחת 192.168.2.x. תעדו את המיפוי בפרופיל, אחרת האדם הבא ינפה אותו כתקלת ניתוב.
פרסום שירות אחד הוא הגרסה הצרה של תרגום, והוא אינו זקוק לאפשרות של OpenVPN כלל. כלל DNAT במארח ה-VPN מפרסם מחדש פורט אחד, כך שהרשת המקומית שומרת על הכתובות שלה ומגיעה לשירות בכתובת המארח שהיא כבר מכירה. המחיר הוא הרגיל: השירות רואה את מארח ה-VPN כמקור, ולכן יומנים לפי לקוח וחיפושים הפוכים מפסיקים לומר משהו. זה מכסה תור הדפסה אחד או עמוד ניהול אחד, לא מארחים משני הצדדים שמגיעים זה לזה.
מה עוד לא יעבוד, ומה לתעד
שידור אינו עובר דרך מנהרה מנותבת. DLNA, UPnP, עיון NetBIOS ו- Wake-on-LAN תלויים בשידור או בריבוי שידור שהתקן tun אינו נושא, ולכן שום מסלול לא מתקן גילוי. גישור עם dev tap מאריך את הקטע, ואיתו שידורי DHCP, ARP וכל חבילת גילוי אחרת; עדיפו מסלול מארח חד-שידורי כמו route 192.168.2.1 255.255.255.255 עבור הכתובת בצד הרשת של ראוטר מרוחק.
שני ראוטרים ששניהם משתמשים ב- 192.168.1.1 באותו נתיב שייכים לאותה משפחת בעיות: הכתובת המקומית תמיד מנצחת, ולכן העמוד של הראוטר המרוחק נשאר לא נגיש עד שאחת הרשתות עוברת. הוספת מתאם שני לא משנה דבר באף אחד משני המקרים.
תעדו את הראיות לפני שאתם עורכים משהו: ip route get או Find-NetRoute, ping -c 3 לכתובת המדוברת, traceroute, ו- tcpdump -ni tun0 icmp בלקוח, ואז טבלת הניתוב ומוני NAT בשרת. פינג שעובד בכיוון אחד ומת בשני מצביע על נתיב החזרה, לא על המנהרה, וההבחנה הבודדת הזו קובעת איזה מהתיקונים למעלה באמת נחוץ לכם.