pfSense על Virtio: TCP נתקע עד שה-offload כבוי
pfSense מוירטואלי עונה ל-ping ואז נתקע ב-TCP גדול. כבו את נתיב ה-offload של סכום הבדיקה ב-virtio ומדדו את המחיר במקום להחליף את כרטיס הרשת.
לקוח מדווח שהמנהרה מתחברת, שה-ping עונה, שדף הכניסה נטען ושההעברה קופאת באותה נקודה בכל ניסיון. התבנית הזאת כבר אומרת הרבה: הנגישות עובדת והתפוקה המתמשכת לא. לפני שפותחים את חומת האש, בררו אם ה-VPN בכלל משתתף בתקלה. שלחו TCP גדול דרך אותו שער ללא מנהרה בנתיב; אם גם הוא קופא, ל-OpenVPN לא היה כל חלק בכך.
לאורח pfSense עם כרטיס רשת virtio יש סיבה טובה מאוד להיכשל בדיוק בצורה הזאת.
מנות קטנות עוברות, TCP גדול נתקע
לחיצות ידיים, תשובות DNS והדהודי ICMP קטנים ובדרך כלל עוברים. העברות מתמשכות מכריחות את האורח לפצל, ושם בדיוק מתגלה נתיב offload פגום. התקלה לא חייבת להיות סימטרית: התעבורה היוצאת יכולה להיות נקייה בזמן שהנכנסת נופלת, או להפך, כך שמשתמש יכול להיכנס ואז להיתקע בתשובה הגדולה הראשונה. מכיוון שאותו לקוח עובד דרך שער אחר, האשמה נופלת על הרכיב החדש ביותר.
לכן בדקו את השער בלי המנהרה. הורדה מ-LAN ל-WAN גדולה מספיק כדי לרוץ כמה שניות מספיקה, והיא חייבת להיעשות לפני כל שינוי בהגדרות כדי שההשוואה אחר כך תהיה בעלת משמעות.
מה ה-offload באמת מבטיח
virtio הוא פרא-וירטואלי: המארח והאורח חולקים את העבודה, המארח מכריז על יכולות סכום בדיקה ופיצול ומצפה שהאורח יסיים את מה שהתחיל. אם המחסנית של האורח לא עושה זאת, המסגרות יוצאות עם סכומי בדיקה חסרים או שהמארח מפיל אותן. E1000 מדומה מציע מודל פשוט ואיטי יותר שבו הבעיה נעלמת בלי שינוי אחד ב-pfSense. משא ומתן על יכולות מתבצע לכל התקן בנפרד, מה שמסביר למה אורח אחד רץ חודשים והתאום שלו שנבנה מחדש נכשל ביום הראשון.
הסט שנקבע במשא ומתן תלוי בגרסת ההיפרביזור ובמודל כרטיס הרשת שנבחר, ולא רק בהגדרות שייבאתם.
תיבת סימון אחת משאירה את virtio
בממשק pfSense, מערכת ואז מתקדם ואז רשת מכיל תיבת סימון בשם השבתת offload של סכום בדיקה בחומרה. סימונה גורם לאורח לחשב סכומי בדיקה בתוכנה, מה שמתאים למה שמחסנית FreeBSD שמאחורי pfSense מצפה לו מהתקן פרא-וירטואלי. שתי אפשרויות קשורות באותו עמוד מכסות offload של פיצול TCP בחומרה ו-offload של קליטה גדולה בחומרה. פנו אליהן כשהלחיצות ידיים מצליחות אבל ההעברות הגדולות לא.
השאירו את כרטיס הרשת כ-virtio בזמן ביצוע השינוי. מעבר ל-E1000 שורף מעבד בכל מנה למשך כל חיי המכונה הווירטואלית ומסתיר את בעיית התצורה מכל מי שיירש את המארח, וזהו חילוף גרוע יותר מנתיב נתונים איטי במקצת אך צפוי.
מדדו את המחיר שזה עתה קיבלתם
חישוב סכומי בדיקה בתוכנה מעביר עבודה אל האורח, לכן מדדו את התפוקה אחר כך במקום להניח שזה לא עולה דבר. במכונה קטנה העונש אמיתי, אבל הוא גלוי ויציב, שלא כמו אובדן שקט. השוו את מוני השגיאות של הממשק ואת יומן הקרנל של האורח לפני ואחרי. היפרביזור שמסנן את הגשר הוא תקלה נפרדת עם ראיות אחרות, ושום דגל offload לא ירפא אותה.
שנו דבר אחד בכל בדיקה ורשמו את נתיב התפריט, את התיבה שסימנתם ואת המספר שמדדתם. כל מי שיתמודד עם האורח הבא שנבנה מחדש ירצה את שלושתם.
חומות אש אחרות מבוססות BSD מציעות שליטה שקולה בהגדרות הממשק שלהן, ולכן ההיגיון עובר גם כשנתיב התפריט לא.