Postfix, VPN ו-smarthost: תור אינו חומת אש

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

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

שתי דרישות שאנשים ממזגים לאחת

הריליי אומר ל-Postfix לאן למסור דואר; relayhost = [smtp.corp.example]:587 מציין מארח ופורט, והסוגריים מדכאים בחירה מבוססת MX עבור הקפיצה הבאה. הנתיב אומר לליבה לאן מותר לחבילות ללכת. relayhost נכון בלי הגבלת נתיב עדיין מאפשר ל-Postfix להגיע לאינטרנט ישירות כשטבלת הניתוב מאפשרת זאת, וחומת אש נכונה עם relayhost שגוי שולחת דואר למקום הלא נכון. אף אחד מהם אינו גורר את השני.

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

מה defer_transports באמת עושה

defer_transports מחזיק הודעות עבור התעבורות הנקובות, כך שלא נעשה ניסיון מסירה עד שסבב תור נוגע בהן. זהו בקרת תזמון, וריקון תור גובר עליו; זו התכנון ולא פגם. השתמשו בשמות התעבורה האמיתיים מתוך master.cf, משום שתעבורה מותאמת או תעבורת ריליי בשם נפרד אינה מכוסה רק מפני שהתוכנית שלה מדברת גם SMTP. ניסיון חוזר רגיל הוא מנגנון אחר: עם נתיב fail-closed, ניסיונות המסירה פשוט נכשלים ונשארים בתור, בלי שום הנחיית דחייה.

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

אכפו את הנתיב בשכבת הרשת

ההגבלה שייכת לגבול הפלט המקומי או לתוך מרחב שמות רשת מבודד. היא חייבת לכסות את הכתובות האמיתיות של הריליי, את התעבורה ואת הפורט, כולל IPv6 אם הוא מופעל, משום שכלל שחוסם TCP 25 לא עושה דבר לריליי על 587 או 465. החזיקו את ה-loopback ואת נתיבי השליחה המקומיים בנפרד כדי שהתור עצמו ימשיך לעבוד. המדיניות צריכה להישאר סגורה כשנתיב המנהרה נעלם או מופיע מחדש תחת שם ממשק אחר.

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

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

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

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

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