לקוחות OpenVPN לא רואים זה את זה: תת-רשת או net30?
הלקוחות מגיעים לשרת אבל לא זה לזה. הפרידו את התקלה בפינג אחד, ואז בחרו טופולוגיית תת-רשת, client-to-client או מקטע TAP מגושר.
שתי תקלות לא קשורות מייצרות אותה תלונה. בראשונה לקוח אחד לא מגיע לאחר אפילו לפי כתובת המנהרה, כי הכתובות אינן באותה תת-רשת או כי השרת אינו מעביר תנועה בין עמיתים. בשנייה ping עובד ורשימת ההתקנים של האפליקציה נשארת ריקה, כי הגילוי נשען על שידור ששכבת מנהרה 3 אינה יכולה לשאת. פינג אחד מפריד ביניהם, והתיקון לאחת ממש לא דומה לתיקון לשנייה.
פינג אחד מפצל את הבעיה לשניים
מלקוח אחד עשו פינג לכתובת המנהרה של הלקוח האחר, לא לשמו ולא לכתובת ה-LAN שלו. אם זה נכשל, הבעיה היא בהעברה או בכתובות והגילוי לא רלוונטי עד שזה יתוקן. אם זה מצליח, ההעברה כבר עובדת והפער שנותר הוא שידור או פתרון שמות.
ip addr show tun0קראו את ממשק הלקוח לפני כל דבר אחר, כי מסכת הרשת היא שמגדירה את הטופולוגיה. /24 או מסכת תת-רשת אחרת פירושה מאגר משותף; /30 עם כתובת עמית פירושה הפריסה הישנה של נקודה לנקודה, שבה לכל לקוח יש בדיוק שכן אחד, השרת.
net30 מול תת-רשת, כפי שנקרא מצד הלקוח
| What you observe | net30 | subnet |
|---|---|---|
| Client netmask | /30 with a peer address | The pool's own mask |
| Peers a client can address directly | One, the server | Every client in the pool |
| Addressing | One /30 block per client, with the server as the only peer | One pool mask shared by all clients |
| Effect of client-to-client | Required for any peer traffic | Required for peer traffic, still no broadcast |
עם net30 השרת מחלק בלוק קטן לכל לקוח, כך שאין מסלול לכתובת המנהרה של לקוח אחר אלא אם השרת מעביר אותו. עם תת-רשת כל המאגר הוא רשת אחת, כל לקוח יכול לפנות לכל אחר, והשרת מעביר ביניהם. לכן תצורת שרת אחת יכולה להיראות תקינה בזמן שפינג בין עמיתים נכשל: שום דבר לא מקולקל, הלקוחות פשוט לא נמצאים ברשת אחת. הלקוח רואה קישור עובד וכתובת עמית שאינה עונה, מה שנקרא כמו חומת אש אבל הוא פריסת כתובות.
החלפת ההנחיה היא עריכה בצד השרת בתוספת הפעלה מחדש, והיא חלה על החיבור הבא ולא על הפעלות שכבר פתוחות. חברו את הלקוחות מחדש לפני שתשפטו את השינוי. אם התקן מייצר את התצורה מחדש מממשק ווב, רשמו את ההנחיה, את הקובץ ואת התאריך, ועשו את העריכה דרך הממשק כשיש כזה, כי בנייה מחדש תדרוס עריכה ידנית בשמירה הבאה.
client-to-client הוא שער נפרד
אפילו בתוך תת-רשת אחת השרת מפיל מנות שמגיעות מלקוח אחד ומופנות לאחר, אלא אם client-to-client מוגדר. מילת המפתח הזו הופכת את השרת למעביר תנועה בין עמיתים במקום לנקודת קצה שרק מקבלת אותה. זה התנאי השני שאנשים מפספסים אחרי תיקון הטופולוגיה.
זה אינו מתרחב לשידור. ההגדרה מעבירה unicast בין לקוחות; היא אינה הופכת את המנהרה למקטע משותף, וכל כמות שלה לא תעביר שאילתת גילוי multicast לכל עמית.
TUN מול TAP, ומה כל אחד יכול לשאת
| Property | TUN | TAP |
|---|---|---|
| Layer | Layer 3, IP packets | Layer 2, Ethernet frames |
| Broadcast and multicast | Not carried | Carried |
| Bridging to the LAN | Not applicable | Required for a shared segment |
| Client platform support | Everywhere | Missing on Android and iOS, limited on macOS |
גישור התקן tap אל ה-LAN מכניס לקוחות מרוחקים לתחום השידור של המשרד, מה שפותר את הגילוי לחלוטין. המחיר הוא הפלטפורמות שאינן מיישמות TAP, גשר שחייב להתקיים בשרת, ותחום כשל שבו סערת שידור על כבל המשרד מגיעה לכל מחשב נייד מרוחק.
לשתי תחנות עבודה או שלוש שזקוקות לפתרון שמות, רשומת hosts או כתובת unicast זולה בהרבה מגשר. פנו ל-TAP כאשר פרוטוקול שאינכם יכולים להחליף תלוי בגילוי בשכבה 2, ולא לפני כן.
לקוחות באותה תת-רשת בלי גשר
הקצאת כתובת מטווח ה-LAN אינה שמה את הלקוח על הכבל. השרת מנתב בין המנהרה לאתרנט, ולכן ARP לכתובת הזו נעצר בממשק השרת ושאר ה-LAN לעולם לא לומד היכן היא נמצאת.
ip neigh add proxy 10.50.1.250 dev eth0Proxy ARP סוגר את הפער הזה בכך שהשרת עונה בשם הלקוח. לטווח, parpd מנהל את הרשומות כשהלקוחות באים והולכים, בעוד ש-sysctl net.ipv4.conf.eth0.proxy_arp=1 עונה לכל מה שמנותב למקום אחר, וזה רחב מספיק כדי ליצור הפתעות משלו בקטע עמוס.
בכל מסלול שתבחרו, הוציאו NAT בין המנהרה לכבל. כלל MASQUERADE מסתיר בדיוק את שאלת הכתובות שאתם מנסים להשיב עליה. הוא גם משאיר לאדם הבא טופולוגיה שאינו יכול לחשוב עליה מהצד של הלקוח.
לפני שמשנים משהו, תפסו ניסיון אחד בשרת עם tcpdump -ni tun0 ואמתו אם מנת העמית מגיעה בכלל. הגעה ואז השלכה מצביעה על client-to-client; אי-הגעה בכלל מצביעה על טופולוגיה או ניתוב. המדריך של OpenVPN 2.6 מתעד את שתי מילות המפתח ואת ברירת המחדל של הטופולוגיה, וכדאי להשוות אותו לגרסה שלכם לפני שמעתיקים שורה מפוסט בפורום.
- ממשק tun מציג מסכת מאגר ולא זוג עמיתים /30.
- פינג ישיר לכתובת המנהרה השנייה מצליח לפני שאתם בודקים את הגילוי.
- תצורת השרת כוללת את
client-to-clientבכל פעם שעמיתים חייבים להחליף מנות. - נקבו בשם פרוטוקול הגילוי שאתם בודקים במקום לומר שהאפליקציה נכשלת.
- השתמשו ב-TAP רק אם כל פלטפורמת לקוח בקבוצה תומכת בו.
- הרחיקו NAT מהנתיב בין המנהרה ל-LAN כשנגישות בתוך אותה תת-רשת חשובה.