שרת PPPoE MikroTik לספקי אינטרנט

תקציר שרת PPPoE MikroTik מאפשר לספק אינטרנט לאמת מנויים, להקצות לכל אחד כתובת IP ולאכוף מגבלת מהירות לכל חבילה — הכול מתוך RouterOS, ללא RADIUS חיצוני בפריסות קטנות. ההגדרה היא שרשרת קצרה ומסודרת: מאגר IP, פרופיל PPP, secrets של מנויים, שירות ה-PPPoE ו-NAT. הבעיה הקשה יותר אינה להגדיר מרכז גישה אחד, אלא להריץ תצורה עקבית וניתנת לאימות על רבים מהם — לעיתים קרובות מאחורי CGNAT. מדריך זה מכסה את שניהם.

מהו שרת PPPoE MikroTik?

שרת PPPoE MikroTik הוא שירות RouterOS שמאמת כל מנוי דרך Point-to-Point Protocol over Ethernet, מעניק לו IP ממאגר ומחיל פרופיל השולט בשער הגישה, ב-DNS ובמגבלת המהירות שלו. כך מנהלים רוב ספקי האינטרנט הקטנים והבינוניים את חיבורי הלקוחות: לקוח מתחבר עם שם משתמש וסיסמה, השרת בודק את האישור, וההפעלה יורשת את החבילה המוקצית — אימות לכל משתמש, הקצאת IP ובקרת רוחב פס ללא ציוד נפרד (תיעוד MikroTik — PPPoE).

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

שלב 1 — צרו מאגר IP

התחילו מהכתובות ש-RouterOS ישאיל למנויים. מאגר הוא בלוק בעל שם — לדוגמה /ip pool add name=pppoe-pool ranges=10.20.0.2-10.20.255.254 — בגודל המותאם להפעלות הבו-זמניות שמרכז זה יישא, עם מרווח. שמרו את כתובת שער הגישה של הפרופיל (כלומר local-address) מחוץ לטווח הניתן להשאלה כדי שלעולם לא תימסר ללקוח בטעות.

התאימו את גודל המאגר לחומרה — נתב צנוע מטפל במאות הפעלות, התקן ממחלקת CCR באלפים (Tech@Layer-x — PPPoE Server on MikroTik for ISP Deployments). כדי לחלק כתובות IP ציבוריות במקום זאת, הפנו את המאגר לבלוק הניתן לניתוב שלכם ודלגו על ה-NAT בשלב 5.

שלב 2 — בנו פרופיל PPP

פרופיל ה-PPP הוא המקום שבו חיה חבילה. הוא מגדיר את local-address (שער הגישה שכל מנוי רואה), את מאגר ה-remote-address משלב 1, את שרתי ה-DNS ו— החשוב ביותר לספק אינטרנט — את ה-rate-limit המגביל כל הפעלה. הקצו את הפרופיל למנוי והוא יורש את המהירות, כך שחבילת “20/10” היא פרופיל אחד שנעשה בו שימוש חוזר על פני אלפי חשבונות (madankc.com.np — MikroTik PPPoE Server Complete Setup Guide).

פרט אחד מכשיל כמעט את כולם: הכיוון. RouterOS קורא את ה-rate-limit של הפרופיל כ-rx-rate/tx-rate מנקודת מבט השרת — ההעלאה של המנוי קודם, ההורדה אחר כך, הפוך מהאופן שבו לקוחות מתארים את חבילתם. חבילת “100 Mbps הורדה / 30 Mbps העלאה” נכתבת rate-limit=30M/100M. הפכו זאת וכל לקוח יקבל בשקט חבילה מוחלפת — בדיוק השגיאה בקנה מידת הצי שתצורה מבוססת-תבנית מונעת.

שלב 3 — הוסיפו secrets של מנויים

כל מנוי זקוק ל”secret” — שם משתמש, סיסמה והפרופיל המגדיר את חבילתו, הנוצר תחת /ppp secret. עבור בסיס קטן זהו מסד נתוני המשתמשים כולו: הוסיפו secret לכל לקוח, נעצו אופציונלית remote-address קבוע ל-IP סטטי, והשביתו את ה-secret כדי לנתק את השירות. זו אותה אחריותיות לכל אישור שה-User Manager של MikroTik מרחיב למנויי hotspot, הנדונה במדריך שלנו על שער ה-hotspot 10.5.50.1 ו-User Manager.

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

שלב 4 — הפעילו את שרת ה-PPPoE בממשק הגישה

כעת הפעילו את השירות. הוסיפו שרת PPPoE עם /interface pppoe-server server, קשרו אותו לממשק הפונה אל רשת הגישה שלכם (יציאה, VLAN או bridge), הגדירו את ה-default-profile שלו לפרופיל משלב 2, ובחרו את שיטות האימות — pap, chap או mschap2. RouterOS אז משיב לגילוי PPPoE באותו ממשק ומאמת כל לקוח שמתחבר עם secret תקף.

שתי הגדרות חשובות בקנה מידה. האפשרות one-session-per-host מונעת ממנוי לפתוח כמה הפעלות בו-זמנית, ואת max-mtu/max-mru יש להגדיר כך שתקורת ה-PPPoE לא תפצל את תעבורת הלקוח. במקום שבו רשת הגישה מפולחת לכל לקוח או אזור, מדריך תצורת ה-bridge של MikroTik שלנו מכסה את יסוד שכבה 2 שעליו נשען השרת.

שלב 5 — הוסיפו כללי NAT וחומת אש

אם הקצתם למנויים כתובות פרטיות בשלב 1, תעבורתם זקוקה לתרגום. הוסיפו כלל masquerade בשרשרת srcnat הקשור לממשק יציאת ה-WAN שלכם כך שכל הפעלת PPPoE תגיע לאינטרנט — אותם יסודות NAT הנדונים במדריך שלנו לתצורת NAT ב-MikroTik. אם חילקתם כתובות IP ציבוריות, דלגו על ה-masquerade ונתבו את הבלוק.

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

שלב 6 — נהלו ואמתו את הצי מרחוק

הנה החלק שמדריכי נתב יחיד מדלגים עליו. הקמת PPPoE על מכונה אחת קלה; הרצת פרופילים, הגדרות MTU וכללי חומת אש זהים על עשרות מרכזים — והוכחה שכל אחד מאמת הפעלות ואוכף את ה-rate limits הנכונים — היא בעיית ספק האינטרנט האמיתית. זה נעשה קשה יותר כשנתב גישה יושב מאחורי Carrier-Grade NAT ללא IP ציבורי, נפוץ יותר ויותר ככל שמפעילים נשענים על קישורי LTE ו-Starlink.

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

טיפים

• עשו תבנית לפרופיל, לא ל-secrets — כל שינוי חבילה צריך לגעת בפרופיל אחד, לעולם לא באלפי חשבונות.
• עקבו אחר ה-CPU של מרכז הגישה: התורים לכל הפעלה מ-rate-limit מצטברים, ומכונה עמוסה מפילה הפעלות בשקט.
• הגדירו max-mtu/max-mru במודע. PPPoE מוסיף 8 בתים של תקורה, והפיצול הנובע מכך הוא הסיבה הנסתרת לרוב פניות ה”איטי באתר אחד”.
• רכזו את האימות מעבר לכמה מאות משתמשים — secrets מקומיים המפוזרים על נתבים הופכים לבלתי ניתנים לביקורת.

שלטו בכל קצה ה-PPPoE שלכם ממסך אחד

שרת PPPoE על MikroTik אחד הוא קל. להריץ אותו על פני צי של ספק אינטרנט — פרופילים זהים, כיוון rate-limit נכון על כל מכונה, ניהול נעול והוכחה שכל מרכז מאמת גם מאחורי CGNAT ללא IP ציבורי — הוא המקום שבו מפעילים מאבדים אחר צהריים שלמים. זו המשימה שעבורה נבנה MKController: להגיע לכל נתב דרך מנהרה יוצאת מאובטחת, לבקר את התצורה, לצפות בהפעלות חיות ולדחוף תיקון על פני הצי כולו בבת אחת, עם טלמטריה המסמנת מכונה עם הפעלות נופלות לפני שלקוח בכלל מתקשר. כך ספקי אינטרנט המריצים PPPoE על MikroTik הופכים עמל של נתב אחר נתב למישור בקרה יחיד.

התחילו את תקופת הניסיון החינמית של MKController