הגבילו את כלל ה-SNAT של OpenVPN לפני שהוא ישבור את nginx

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

ודאו שהקונטיינר יכול ליצור התקן tun

שום דבר אחר לא חשוב אם ממשק המנהרה לא יכול להתקיים. בדקו ש-/dev/net/tun קיים ושהיצירה של התקן בדיקה מצליחה, כי ספקים רבים משביתים tun בתוך קונטיינרים כברירת מחדל. שום עבודת firewall לא מפצה על התקן שמעולם לא נוצר.

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

החליטו מה MASQUERADE עושה בממשק הזה

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

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

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

הגבילו את הכלל ל-pool אחד ולממשק אחד

לתסמין השני סיבה אחרת: כלל POSTROUTING בלי הגבלת מקור ובלי הגבלת פלט. כלל כזה משכתב כל חבילה שיוצאת מהמארח.

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

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

הפכו את הכללים לקבועים וגלו למי עוד הם שייכים

כללים שהוספו ביד נעלמים באתחול, לכן שמרו אותם עם iptables-save או נהלו אותם דרך netfilter-persistent במקום שבו הוא מותקן. אשרו שהשחזור רץ לפני ש-OpenVPN מתחיל. ואז אתחלו פעם אחת בכוונה במקום לגלות את הפער במהלך תקרית.

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

אמתו עם מונים ועם זרימה אחת שנלכדה

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

בשרת, קראו את מוני החבילות בכללי ה-NAT וה-FORWARD עם iptables -t nat -L -v -n וצפו בזרימה אחת בלכידה. אם כתובת הלקוח מופיעה בלכידה ולא מגיעה תשובה, הפער הוא בנתיב החזרה או בסינון של הספק, ולא בפרופיל הלקוח. השוו את המקור שנלכד לכתובת שהכלל מתרגם אליה, כי אי-התאמה פירושה שכלל אחר התאים קודם. זרימה אחת שנצפתה מכריעה יותר מעמוד של קריאת קונפיגורציה.

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