האם תפוקה נמוכה של VPN היא בעיית אנטרופיה? בדרך כלל לא

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

שני תסמינים שנראים דומים

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

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

systemd-analyze blame | head -10
journalctl -u [email protected] -o short-precise | head -40
cat /proc/sys/kernel/random/entropy_avail

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

איך נראית באמת המתנה למספרים אקראיים

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

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

strace -f -e trace=getrandom -p $(pidof openvpn) 2>&1 | head -20
dmesg | grep -i 'random\|crng'

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

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

איך נראית באמת איטיות מתמשכת

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

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

ss -tin dst 203.0.113.10
nstat -az | grep -i 'drop\|retrans'
ethtool -S eth0 | grep -i 'drop\|error'

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

בחרו את התיקון לצוואר הבקבוק שמדדתם

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

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

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