לחיצת היד של WireGuard עובדת אבל אין אינטרנט: עקבו אחרי החבילה
לחיצת היד מוכיחה רק מפתחות ונגישות. עקבו אחרי חבילה אחת מ-AllowedIPs דרך העברה, NAT ומסלול החזרה כדי לראות היכן היא נעצרת.
המנהרה פעילה, wg show מדווח על לחיצת יד עדכנית, אפשר לעשות פינג לכתובת המנהרה של השרת, ושום דבר מעבר לה לא עונה. האינסטינקט הוא ליצור מפתחות מחדש או לשתף את התצורה שוב. זה משנה בדיוק את החלק במסלול שכבר הוכח שעובד.
לחיצת יד שהושלמה אומרת ששני הצדדים מסכימים על המפתחות, ש-UDP מגיע לנקודת הקצה, ושהניתוב הקריפטוגרפי מקבל את החבילה. היא לא אומרת דבר על האם החבילה יכולה לצאת מהשרת לאחר מכן.
לכן עקבו אחרי חבילה אחת במקום לנחש. יש ארבעה מקומות שבהם היא יכולה למות, וכל אחד משאיר עקבה אחרת.
מה לחיצת היד באמת מוכיחה
WireGuard הוא פרוטוקול UDP שמקים הפעלה עם לחיצת יד Noise ואז מצפין חבילות עבור עמית. כאשר wg show מציג לחיצת יד בת כמה שניות ומונה העברות שעולה, נקודת הקצה, המפתחות והמפתח הציבורי של העמית כולם נכונים.
מה שהיא לא מוכיחה הוא שהלקוח שלכם בכלל שולח תעבורה לכיוון האינטרנט לתוך הממשק, שהשרת מוכן להעביר אותה הלאה, או שתשובה יכולה למצוא את הדרך חזרה. אלה החלטות ניתוב של הגרעין ושל חומת האש, והן מתקבלות מחוץ למנהרה.
זו הסיבה שפינג לכתובת המנהרה של השרת הוא מבחן כל כך מטעה. החבילה הזו ממוענת לשרת עצמו, ולכן היא מסתיימת מקומית. היא אף פעם לא זקוקה להעברה, אף פעם לא לתרגום ואף פעם לא למסלול חזרה מהאינטרנט.
AllowedIPs הוא החלטת ניתוב
בלקוח, AllowedIPs עושה שני תפקידים. זהו טבלת הניתוב לפי מפתח קריפטוגרפי שקובעת אילו כתובות יעד נשלחות למנהרה של העמית הזה, וזהו רשימת כתובות המקור שהעמית יקבל מכם. אם תצורת הלקוח מפרטת רק 10.8.0.0/24, יעדים ציבוריים אף פעם לא נכנסים לממשק ומסלול ברירת המחדל הרגיל שלכם מוביל אותם מחוץ למנהרה. אז המנהרה עובדת באופן מושלם ולא עושה דבר ממה שרציתם.
הסתכלו על מה שהלקוח באמת התקין ולא על מה שכתוב בקובץ התצורה:
wg show wg0 allowed-ipsip route get 1.1.1.1
הפקודה השנייה היא המכרעת. אם התשובה מציינת את הממשק הפיזי שלכם ואת השער הרגיל, החבילה לא עוברת במנהרה ושום שינוי בצד השרת לא יתקן זאת. הוסיפו 0.0.0.0/0 עבור IPv4 ו-::/0 עבור IPv6 בנפרד; כלל שתופס הכול עבור משפחה אחת משאיר את השנייה במסלול המקורי שלה, וזו סיבה נפוצה למנהרת IPv4 שעובדת ולחיפוש IPv6 שנתקע.
היכן החבילה מתה בשער
אם המסלול נכון והחבילה עדיין לא מגיעה לשום מקום, היא מגיעה לשרת ונעצרת שם. ארבע בדיקות מכסות את רוב השערים.
העברה. sysctl net.ipv4.ip_forward שמחזיר 0 הוא התשובה הקלאסית, והפצות רבות עדיין נמצאות ב-0 כברירת מחדל. הוא חייב להיות 1, ויש לקבוע אותו באופן קבוע בקובץ sysctl ולא בפקודה שנעלמת באתחול מחדש. העברה של IPv6 היא מתג נפרד.
מדיניות הסינון. שרשרת FORWARD עם מדיניות השלכה כברירת מחדל תשליך תעבורה במנהרה בעוד שהיא מאפשרת תעבורה אל המארח עצמו, וזה מתאים בדיוק לתסמין. קראו את מערך הכללים החי, לא קובץ שמור: nft list ruleset או iptables -S.
תרגום או ניתוב. לקוחות שמשתמשים בכתובות מנהרה פרטיות זקוקים או ל-NAT מקור בממשק היציאה של השרת, או לתחילית מנותבת שהרשת שמעל יודעת להחזיר. הבחירה בין השניים הולכת לפי תוכנית הכתובות. הוספת MASQUERADE לרשת שכבר מנתבת את התחילית שלכם חזרה היא בלתי מזיקה אך חסרת טעם, והשמטתה במקום שאין בו מסלול משאירה תשובות ממוענות לטווח פרטי שאינו ניתן לניתוב.
מסלול החזרה. בתכנונים מנותבים, הנתב שמעל זקוק למסלול שמצביע על השרת שלכם. גם רשת הספק יכולה לחסום זאת: כמה עננים מפעילים בדיקת מקור ויעד על המופע, שמשליכה בשקט חבילות שמקורן אינו הכתובת של המופע עצמו, עד שהבדיקה הזו תושבת.
DNS נכשל אחרת מניתוב
חבילה לכתובת ידועה וחיפוש שם הם שני כשלים נפרדים, והודעות השגיאה מטעות בכיוונים הפוכים. אם ping 1.1.1.1 עובד והדפדפן לא מצליח לטעון דבר, המסלול תקין ופתרון השמות לא. אם הפינג עצמו נכשל, DNS לא רלוונטי ואתם חזרה בסעיף הקודם.
wg-quick יכול לקבוע פותר מהשורה DNS = בתצורה, ול-systemd-resolved יש התנהגות משלו לכל קישור. VPN שמחליף את הפותר בכתובת שנגישה רק בתוך המנהרה יכשיל כל חיפוש ברגע שהמנהרה נופלת, מה שנראה כאילו המנהרה שוברת את האינטרנט.
| Symptom | Layer to inspect |
|---|---|
| Tunnel address pings, nothing else does | Client route, then gateway forwarding |
| Public IP pings, hostnames fail | Resolver selection and reachability |
| Handshake completes, no reply ever | FORWARD policy or missing NAT on the server |
| Small requests work, large transfers stall | MTU and TCP MSS clamping |
סדר שמייצר ראיות
הריצו קודם את הבדיקה בצד הלקוח, כי זו פקודה אחת והיא מבטלת חצי מהאפשרויות. אחר כך אשרו אם השרת בכלל נועד להיות יציאה לאינטרנט; שער שנבנה לגישה פרטית אינו שבור כשיעדים ציבוריים נכשלים.
בשרת, התבוננו בממשק בזמן שאתם שולחים פינג מהלקוח: tcpdump -ni wg0 icmp אמור להראות את הבקשה, ו-tcpdump -ni eth0 icmp אמור להראות שהיא יוצאת, מתורגמת או לא. אם היא מופיעה בראשון ואף פעם לא בשני, העצירה מקומית בשרת. אם היא יוצאת ולא חוזרת תשובה, הבעיה נמצאת למעלה, וזו שיחה אחרת.
לבסוף, עשו שהתיקון ישרוד אתחול מחדש. העברה שייכת לקובץ sysctl, כללי חומת האש שייכים לשירות שטוען אותם, ומסלולי הלקוח שייכים לתצורה שמעלה את הממשק ולא ל-shell שתשכחו. התחברו מחדש, חזרו על אותן שתי בדיקות ואשרו שהמונים זזים.