מחוברים ל-OpenVPN אבל שום דבר לא נטען: מסלול מהלקוח החוצה

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

התחילו בלקוח ועבדו החוצה

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

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

שתי לכידות מראות היכן החבילות עוצרות

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

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

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

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

ip -4 route get 9.9.9.9

השדה dev בפלט הזה הוא השם שכלל ה-NAT יזדקק לו מאוחר יותר, אז שמרו אותו.

העברה היא מתג בקרנל ומדיניות של חומת אש

הקרנל חייב להסכים להעביר מלכתחילה. קראו את הערך הנוכחי, ואז הפכו את ההגדרה לקבועה במקום לכתוב אותה רק בקרנל הפועל:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

העברה היא רק חצי. במארח עם UFW מדיניות ההעברה נקבעת ב-/etc/default/ufw וחייבת להיות ACCEPT לפני שטעינה מחדש תיכנס לתוקף. דחייה כברירת מחדל בנתיב ההעברה משאירה את לחיצת היד בריאה לגמרי ובו-זמנית משליכה בשקט כל חבילה שמנסה לצאת דרך המנהרה, וזה בדיוק התסמין שאיתו התחלתם.

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

תנו שם לממשק היציאה האמיתי בכלל ה-NAT

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

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

הכשל הקלאסי הוא כלל שהועתק ממדריך שאומר -o eth0 במכונה שהמתאם שלה נקרא אחרת. הכלל מותקן בלי אזהרה, לא מתאים לשום דבר, והלקוח עדיין בלי אינטרנט. המאגר הוא החצי השני של אותה טעות: אם השרת מחלק 10.44.0.0/24 והכלל מכסה 10.8.0.0/24, שום דבר לא יתאים לעולם.

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

iptables -t nat -L POSTROUTING -v -n

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

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

DNS הוא הכשל השני מאחורי הראשון

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

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

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

לקוחות Windows עשויים בכל זאת לחזור לפותר המקומי, וזה בדיוק מה ש-block-outside-dns קיים כדי למנוע, במחיר של אובדן שמות שרק הרשת המקומית יכולה לפתור. לקוחות Linux עם systemd-resolved מתעלמים לעיתים קרובות מפותר שנדחף אלא אם סקריפט מתקין אותו, אז בדקו resolvectl status עבור התקן המנהרה לפני שתסיקו שהדחיפה התעלמה.

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