לקוחות OpenVPN מגושרים בלי אינטרנט? בדקו את כלל ה-NAT

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

המונה הוא הראיה, לא השורה בטבלה

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

iptables -t nat -L POSTROUTING -v -n

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

מצאו את השם שהקרנל באמת רושם

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

ip -brief link

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

כתבו את הכלל מחדש מול התקן המנהרה

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tap0 -j MASQUERADE

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

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

למה הכרטיס הפיזי אף פעם לא מתאים

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

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

הוכיחו זאת מקצה לקצה ואז הפכו אותו לקבוע

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

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

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