לחיצת היד של WireGuard עובדת, אבל תת-הרשת של המשרד לא עונה

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

AllowedIPs הוא גם רשימת גישה וגם טבלת ניתוב

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

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

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.66.0.1/32, 192.168.50.0/24

ההעברה והתרגום שייכים לשרת

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

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

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

כשה-LAN עבר והכלל לא

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

iptables -t nat -n -L POSTROUTING
ip -br addr show

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

שני אתרים מאחורי NAT זקוקים למקום להיפגש

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

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

הפרידו את השכבות בארבע בדיקות

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

wg show
ip route get 192.168.50.20
tcpdump -ni wg0 icmp
iptables -vnL FORWARD --line-numbers

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