למה דירוג ה-Wi-Fi של הראוטר שלכם לא מנבא את תפוקת ה-VPN
קצב Wi-Fi מפורסם וקצב VPN נמדד מתארים שכבות שונות. עברו את הבדיקה המסודרת הזו לפני שאתם קונים ראוטר מהיר יותר.
ראוטר עם תג Wi-Fi של 3,000 Mbps עדיין יכול להעביר תעבורה מוצפנת בשבריר מהמספר הזה, ואף אחד משני המספרים אינו לא ישר. דירוג הרדיו מתאר את האפנון הטוב ביותר האפשרי של הקישור האלחוטי שהצ'יפסת תומך בו; מספר ה-VPN מתאר כמה מהר התקן אחד יכול לדחוף מנות מוצפנות דרך המעבד של הראוטר ומחוץ למעגל הגישה שלכם. אלה שכבות שונות, גדלי מנות שונים ושיטות מדידה שונות. התייחסו למספר שעל הקופסה כתקרה שאיש אינו מגיע אליה, לא כתחזית של מהירות המנהרה שלכם.
שלב 1: מפו את ארבע השכבות שמגבילות את המספר
כמעט כל תלונה על ראוטר איטי שעבדתי עליה נופלת לאחת מארבע רמות: הקישור האלחוטי, קצב גישת ה-WAN, נתיב ההעברה (NAT, חומת אש, מעקב חיבורים) או נתיב ההצפנה של ה-VPN. הם נערמים, והרמה האיטית ביותר קובעת את התוצאה. קצב Wi-Fi מפורסם מדבר רק על הרמה הראשונה, והוא מדבר עליה בנדיבות.
המספר הזה נובע ממספר הזרמים כפול רוחב הערוץ כפול האפנון הגבוה ביותר שהצ'יפסת יכול לנהל משא ומתן עליו. רדיו 2x2 ב-5 GHz ברוחב 80 MHz עם 1024-QAM מפורסם קרוב ל-1,200 Mbps, אבל Wi-Fi הוא אמצעי משותף וחצי-דופלקסי: לקוחות מתחלפים, שידורים חוזרים ותעבורת ניהול שורפים זמן אוויר, ו-TCP מוסיף את התקורה שלו. לקוח שמנהל משא ומתן על הקצב המרבי בתנאים אידיאליים מודד בדרך כלל הרבה פחות ממחציתו, ופחות כשמופיעות רשתות שכנות.
| Symptom | Tier to suspect first |
|---|---|
| Wired clients are slow too | WAN access or forwarding path |
| Only Wi-Fi clients are slow | Radio, airtime, or channel width |
| One stream is slow, four parallel streams add up | Per-connection CPU path, not the link |
| Every stream is slow and one core sits at 100% | Crypto path |
| Fast to LAN hosts, slow to the internet | WAN, not the tunnel |
אם הטבלה מצביעה על הרדיו, תקנו קודם את הצד האלחוטי: פס, רוחב ערוץ, מרחק. אם היא מצביעה מתחת לרדיו, ארבעת השלבים הבאים הם החשובים, ושום כמות של רכישת אנטנות לא תשנה זאת.
שלב 2: קחו בסיס קווי לפני שאתם נוגעים ברדיו
שימו את המחשב הנייד על Ethernet ומדדו קודם את הנתיב בלי המנהרה, כי זה נותן לכם מכנה. הריצו את כלי התפוקה בצד הרחוק, על ה-VPS או שרת הבית שמסיים את ה-VPN, והפנו את הלקוח לכתובת הציבורית שלו כדי שהתעבורה תעבור דרך הראוטר ומעגל הגישה שלכם.
# on the far host (VPN endpoint)
iperf3 -s
# wired client, direct to the endpoint's public address
iperf3 -c 203.0.113.10 -t 30
# same client, four parallel streams
iperf3 -c 203.0.113.10 -t 30 -P 4
שני מספרים מהבלוק הזה עונים על שאלות שונות. זרם אחד מציג את התקרה לכל חיבור, כולל התנהגות חלון TCP וכל עיצוב לפי זרם בנתיב. ארבעה זרמים מראים אם לקישור יש קיבולת שאתם לא מנצלים, כי זרמים מקבילים יכולים למלא צינור שזרם אחד אינו ממלא.
שמרו על זה הוגן: אותו מארח, שעה ביום ומשך, בלי שום דבר אחר שמשדר בבית. העברה גורפת של שלושים שניות היא היחידה הנכונה כאן, ו-RFC 6349, המסגרת לבדיקת תפוקת TCP, בנויה בדיוק על ההיגיון הזה, כי פרצים קצרים ובקשות קטנות מחמיאים לקישור. רשמו את קו הבסיס לפני שאתם משנים משהו.
שלב 3: הריצו את אותה בדיקה דרך המנהרה
עכשיו חזרו עליה מול כתובת המנהרה של נקודת הקצה, עם אותו לקוח, משך ומספר זרמים, כשהמנהרה פעילה ואין תעבורה אחרת. היחס בין שתי התוצאות אומר לכם מה עולים ההצפנה והעטיפה על החומרה הזו; המספר המוחלט אומר לכם אם זה מספיק לעבודה.
עקבו אחרי המונים בזמן ההעברה. ב-WireGuard, wg show מדווח על בתים שהועברו לכל עמית; ב-OpenVPN, קובץ סטטוס שנכתב במרווחים נותן לכם את אותה תצוגה.
watch -n 1 'wg show wg0 transfer'
# OpenVPN: add --status /run/openvpn/server.status 10 to the server config
tail -f /run/openvpn/server.status
אם מספר המנהרה קרוב לבסיס הקווי, ה-VPN אינו צוואר הבקבוק שלכם ואפשר להפסיק להאשים אותו. אם הוא שבריר מהבסיס, האובדן קרה בתוך נתיב ההצפנה וההעברה של הראוטר, והשלב הבא אומר לכם איזה חלק.
אזהרה אחת: ברגע שכתובת ה-IP היוצאת משתנה, חלק משירותי בדיקת המהירות בוחרים בשקט שרת מדידה אחר, כך שאתם משווים שתי נקודות קצה. נעצו את כתובת השרת בעצמכם.
שלב 4: קראו את המעבד כנתיב, לא כממוצע
ראוטר שמציג 30 אחוז מעבד כולל עדיין יכול להיות רווי: העבודה של מנהרה אחת נוטה לנחות על ליבה אחת, תור פסיקות אחד או תהליך ליבה אחד, כך שהממוצע מסתיר את התקרה. הסתכלו על מספרים לפי ליבה ועל softirq במקום על המחוג בלוח המחוונים.
mpstat -P ALL 1
top -H -p $(pgrep -f 'openvpn')
grep -o -m1 aes /proc/cpuinfoשלושה דברים חשובים בפלט הזה. ליבה אחת שנעצה קרוב ל-100 אחוז בזמן שהאחרות ריקות מצביעה על מגבלה לכל חיבור. %soft כבד או ksoftirqd עסוק על מעבד אחד מצביע על עיבוד מנות בצד הקבלה שאינו מתפזר בין התורים. ודגל aes חסר פירושו שלמעבד אין הוראות AES, ולכן הצפנה סימטרית רצה בתוכנה ועולה הרבה יותר לכל מנה.
גם המימוש חשוב. מופע OpenVPN מסורתי במרחב המשתמש מעבד את המנות של מנהרה אחת בעיקר במקום אחד, ולכן קופסה מהירה עם כמה ליבות יכולה להתנהג כמו בעלת ליבה אחת עבור המנהרה הזו. WireGuard בגרעין מפזר את העבודה בין המעבדים, ופריקת ערוץ הנתונים של OpenVPN מעבירה גם היא את טיפול המנות לגרעין, אבל רק בגרסאות ובפלטפורמות שתומכות בכך. הצהרת האצת חומרה בעמוד השיווק אינה הוכחה שנתיב הקוד שאתם מריצים משתמש בה.
שלב 5: החליטו מה לשנות, בסדר הזה
עברו על הרשימה הזו למטה ועצרו בשורה הראשונה שנכונה, כי שינוי משהו שמתחתיה לא יזיז את המספר.
1. תפוקה ישירה קווית נמוכה ממה שאתם משלמים עליו: דברו עם הספק, כי המנהרה לא יכולה ליצור קיבולת שמעגל הגישה לא מספק. 2. קווי ישיר בסדר אבל ליבה אחת נעצרת במהלך בדיקת המנהרה: נתיב ההצפנה של הראוטר הוא הגבול. 3. המעבד ריק אבל המנהרה איטית: בדקו MTU ופיצול, ואחר כך את הקיבולת של נקודת הקצה המרוחקת עצמה. 4. רק לקוחות Wi-Fi איטיים: החליפו פס או רוחב ערוץ, והשלימו עם כך שהקצב המפורסם מעולם לא היה מספר VPN.
כשהראוטר הוא באמת הגבול, האפשרויות הישרות הן התקן עם הוראות AES ונתיב העברה מהיר יותר, מנהרה בצד הגרעין כמו WireGuard במקום כזו במרחב המשתמש, או העברת הלקוח אל ההתקן עצמו כדי שהראוטר יפסיק להצפין. כיבוי הצפנה מאומתת כדי לנצח בנצ'מרק אינו אחת מהן; הוא מחליף תכונת אבטחה במספר שעדיין לא יתאים לקופסה.
לפני שאתם קונים משהו, הריצו שוב את שלבים 2 ו-3 בהתקן החדש עם אותו שרת ומשך, ואז השוו יחסים ולא שיאים.