Tutorial
MikroTik PPPoE-server för ISP:er
Så konfigurerar du en MikroTik PPPoE-server för en ISP: IP-pooler, PPP-profiler, secrets, rate limits och fjärrhantering av abonnenter bakom CGNAT.
Sammanfattning En MikroTik PPPoE-server låter en ISP autentisera abonnenter, tilldela var och en en IP-adress och tvinga fram en hastighetsgräns per abonnemang — allt från RouterOS, utan extern RADIUS för små installationer. Konfigurationen är en kort, ordnad kedja: en IP-pool, en PPP-profil, abonnent-secrets, PPPoE-tjänsten och NAT. Det svårare problemet är inte att konfigurera en koncentrator, utan att köra en konsekvent, verifierbar konfiguration på många av dem — ofta bakom CGNAT. Den här guiden täcker båda.

Vad Är en MikroTik PPPoE-server?
En MikroTik PPPoE-server är en RouterOS-tjänst som autentiserar varje abonnent över Point-to-Point Protocol over Ethernet, ger dem en IP från en pool och tillämpar en profil som styr deras gateway, DNS och hastighetsgräns. Så hanterar de flesta små och medelstora ISP:er kundanslutningar: en kund loggar in med användarnamn och lösenord, servern kontrollerar referensen, och sessionen ärver det tilldelade abonnemanget — autentisering per användare, IP-tilldelning och bandbreddskontroll utan separat utrustning (MikroTik-dokumentation — PPPoE).
PPPoE förblir ISP-standarden tack vare ansvarsskyldighet. Varje abonnent har en individuell referens, så du kan inaktivera ett konto vid utebliven betalning, se vem som är online och binda en fast adress eller hastighet till en person — inget av detta levererar bridge- eller DHCP-leverans rent. Hela konfigurationen kokar ner till en idé: definiera abonnemanget en gång i en profil, och koppla sedan abonnenterna till den.
Steg 1 — Skapa IP-poolen
Börja med adresserna RouterOS lånar ut till abonnenter. En pool är ett namngivet block — till exempel /ip pool add name=pppoe-pool ranges=10.20.0.2-10.20.255.254 — dimensionerat efter de samtidiga sessioner den här koncentratorn ska bära, med marginal. Håll profilens gateway-adress (alltså local-address) utanför det utlåningsbara intervallet så att den aldrig av misstag ges till en klient.
Dimensionera poolen efter hårdvaran — en blygsam router klarar hundratals sessioner, en enhet i CCR-klassen tusentals (Tech@Layer-x — PPPoE Server on MikroTik for ISP Deployments). För att dela ut publika IP:er istället, rikta poolen mot ditt routbara block och hoppa över NAT i Steg 5.
Steg 2 — Bygg PPP-profilen
PPP-profilen är där ett abonnemang bor. Den anger local-address (gatewayen varje abonnent ser), remote-address-poolen från Steg 1, DNS-servrarna och — viktigast för en ISP — den rate-limit som begränsar varje session. Tilldela profilen till en abonnent och de ärver hastigheten, så ett “20/10”-abonnemang är en profil återanvänd på tusentals konton (madankc.com.np — MikroTik PPPoE Server Complete Setup Guide).
En detalj lurar nästan alla: riktningen. RouterOS läser profilens rate-limit som rx-rate/tx-rate ur serverns synvinkel — abonnentens uppladdning först, nedladdning sedan, tvärtom mot hur kunder beskriver sitt abonnemang. Ett paket “100 Mbps ner / 30 Mbps upp” skrivs rate-limit=30M/100M. Vänd på det och varje kund får tyst ett ombytt abonnemang — precis det flottäckande felet som mallkonfiguration förhindrar.
Steg 3 — Lägg till abonnent-secrets
Varje abonnent behöver en “secret” — ett användarnamn, lösenord och profilen som definierar deras abonnemang, skapad under /ppp secret. För en liten bas är detta hela användardatabasen: lägg till en secret per kund, fäst eventuellt en fast remote-address för en statisk IP, och inaktivera secret-en för att stänga av tjänsten. Det är samma ansvarsskyldighet per referens som MikroTiks User Manager utökar för hotspot-abonnenter, beskriven i vår guide till 10.5.50.1-hotspot-gatewayen och User Manager.
Lokala secrets slutar skala i intervallet hundratals till tusentals, där att redigera en router per kundändring blir flaskhalsen. Vid den punkten flyttar du autentiseringen till en extern RADIUS-server, och koncentratorerna frågar bara RADIUS om en inloggning är giltig — så att abonnentdatabasen hålls på ett ställe.
Steg 4 — Aktivera PPPoE-servern på åtkomstgränssnittet
Slå nu på tjänsten. Lägg till en PPPoE-server med /interface pppoe-server server, bind den till gränssnittet vänt mot ditt åtkomstnätverk (en port, VLAN eller bridge), ange dess default-profile till profilen från Steg 2, och välj autentiseringsmetoderna — pap, chap eller mschap2. RouterOS svarar sedan på PPPoE-discovery på det gränssnittet och autentiserar varje klient som loggar in med en giltig secret.
Två inställningar spelar roll i stor skala. Alternativet one-session-per-host hindrar en abonnent från att öppna flera samtidiga sessioner, och max-mtu/max-mru bör sättas så att PPPoE-overhead inte fragmenterar kundtrafik. Där åtkomstnätet är segmenterat per kund eller zon täcker vår guide till MikroTik bridge-konfiguration Lager 2-grunden servern bygger på.
Steg 5 — Lägg till NAT- och brandväggsregler
Om du tilldelade abonnenter privata adresser i Steg 1 behöver deras trafik översättning. Lägg till en masquerade-regel i srcnat-kedjan bunden till ditt WAN-utgångsgränssnitt så att varje PPPoE-session når internet — samma NAT-grunder som beskrivs i vår guide till att konfigurera NAT på MikroTik. Om du delade ut publika IP:er, hoppa över masquerade och routa blocket.
Skydda sedan koncentratorn. PPPoE-tjänsten bör vara nåbar för abonnenter, men routerns hanteringsgränssnitt bör inte vara det, så lägg till brandväggsregler som släpper Winbox-, API- och WebFig-åtkomst från abonnentvänd sida. En koncentrator som bär verklig kundintäkt är just den enhet du inte vill ha nåbar från en kapad session.
Steg 6 — Hantera och verifiera flottan på distans
Här är den del som enskild-router-guider hoppar över. Att resa PPPoE på en maskin är lätt; att köra identiska profiler, MTU-inställningar och brandväggsregler på dussintals koncentratorer — och att bevisa att var och en autentiserar sessioner och tvingar fram rätt rate limits — är det verkliga ISP-problemet. Det blir svårare när en åtkomstrouter sitter bakom Carrier-Grade NAT utan publik IP, allt vanligare när operatörer lutar sig mot LTE- och Starlink-upplänkar.
Det är här central hantering förtjänar sin plats: MKController håller varje router nåbar över en autentiserad utgående tunnel även när den saknar publik adress — samma tillvägagångssätt som i vår guide till MikroTik fjärråtkomst bakom CGNAT — så att du granskar konfiguration och skjuter ut fixar över hela flottan, med telemetri som flaggar en maskin med tappade sessioner innan kunderna ringer.
Tips
- Mallförsedd profil, inte secrets — varje abonnemangsändring bör röra en profil, aldrig tusentals konton.
- Håll koll på koncentratorns CPU: kö-per-session från
rate-limitadderas, och en överbelastad maskin tappar sessioner tyst. - Sätt
max-mtu/max-mrumedvetet. PPPoE lägger till 8 byte overhead, och den resulterande fragmenteringen är den dolda orsaken till de flesta “det är långsamt på en plats”-ärendena. - Centralisera autentisering bortom några hundra användare — lokala secrets utspridda på routrar blir omöjliga att granska.
Styr hela din PPPoE-kant från en enda skärm
En PPPoE-server på en MikroTik är lätt. Att köra den över en ISP-flotta — identiska profiler, rätt rate-limit-riktning på varje maskin, hanteringen låst och bevis på att varje koncentrator autentiserar även bakom CGNAT utan publik IP — är där operatörer förlorar hela eftermiddagar. Det är uppgiften MKController är byggt för: nå varje router över en säker utgående tunnel, granska konfiguration, se live-sessioner och skjuta ut en fix över hela flottan på en gång, med telemetri som flaggar en maskin med tappade sessioner innan en kund ens ringer. Så förvandlar ISP:er som kör PPPoE på MikroTik en router-för-router-syssla till ett enda kontrollplan.