Tutorial
MikroTik PPPoE-server for ISP-er
Slik setter du opp en MikroTik PPPoE-server for en ISP: IP-pooler, PPP-profiler, secrets, rate limits og fjernstyring av abonnenter bak CGNAT.
Sammendrag En MikroTik PPPoE-server lar en ISP autentisere abonnenter, tildele hver en IP-adresse og håndheve en hastighetsgrense per abonnement — alt fra RouterOS, uten ekstern RADIUS for små installasjoner. Oppsettet er en kort, ordnet kjede: en IP-pool, en PPP-profil, abonnent-secrets, PPPoE-tjenesten og NAT. Det vanskeligere problemet er ikke å konfigurere én konsentrator, men å kjøre en konsistent, verifiserbar konfigurasjon på mange av dem — ofte bak CGNAT. Denne guiden dekker begge.
Hva Er en MikroTik PPPoE-server?
En MikroTik PPPoE-server er en RouterOS-tjeneste som autentiserer hver abonnent over Point-to-Point Protocol over Ethernet, gir dem en IP fra en pool og bruker en profil som styrer gatewayen, DNS-en og hastighetsgrensen deres. Slik håndterer de fleste små og mellomstore ISP-er kundeforbindelser: en kunde logger på med brukernavn og passord, serveren sjekker legitimasjonen, og økten arver det tildelte abonnementet — autentisering per bruker, IP-tildeling og båndbreddekontroll uten separat utstyr (MikroTik-dokumentasjon — PPPoE).
PPPoE forblir ISP-standarden på grunn av ansvarlighet. Hver abonnent har en individuell legitimasjon, så du kan deaktivere en konto ved manglende betaling, se hvem som er pålogget, og binde en fast adresse eller hastighet til en person — ingenting av dette leverer bridge- eller DHCP-levering rent. Hele konfigurasjonen koker ned til én idé: definer abonnementet én gang i en profil, og knytt deretter abonnentene til det.
Trinn 1 — Opprett IP-poolen
Start med adressene RouterOS låner ut til abonnenter. En pool er en navngitt blokk — for eksempel /ip pool add name=pppoe-pool ranges=10.20.0.2-10.20.255.254 — dimensjonert etter de samtidige øktene denne konsentratoren skal bære, med margin. Hold profilens gateway-adresse (altså local-address) utenfor det utlånbare området, så den aldri ved et uhell gis til en klient.
Dimensjoner poolen etter maskinvaren — en beskjeden ruter takler hundrevis av økter, en enhet i CCR-klassen tusenvis (Tech@Layer-x — PPPoE Server on MikroTik for ISP Deployments). For å dele ut offentlige IP-er i stedet, rett poolen mot den rutbare blokken din og hopp over NAT i Trinn 5.
Trinn 2 — Bygg PPP-profilen
PPP-profilen er der et abonnement bor. Den setter local-address (gatewayen hver abonnent ser), remote-address-poolen fra Trinn 1, DNS-serverne og — viktigst for en ISP — rate-limit som begrenser hver økt. Tildel profilen til en abonnent, og de arver hastigheten, så et “20/10”-abonnement er én profil gjenbrukt på tusenvis av kontoer (madankc.com.np — MikroTik PPPoE Server Complete Setup Guide).
Én detalj lurer nesten alle: retningen. RouterOS leser profilens rate-limit som rx-rate/tx-rate sett fra serverens synsvinkel — abonnentens opplasting først, nedlasting etterpå, motsatt av hvordan kunder beskriver abonnementet sitt. En pakke “100 Mbps ned / 30 Mbps opp” skrives rate-limit=30M/100M. Snu det, og hver kunde får i stillhet et byttet abonnement — nettopp den flåtedekkende feilen som malkonfigurasjon forhindrer.
Trinn 3 — Legg til abonnent-secrets
Hver abonnent trenger en “secret” — et brukernavn, passord og profilen som definerer abonnementet deres, opprettet under /ppp secret. For en liten base er dette hele brukerdatabasen: legg til en secret per kunde, fest eventuelt en fast remote-address for en statisk IP, og deaktiver secret-en for å stenge tjenesten. Det er den samme ansvarligheten per legitimasjon som MikroTiks User Manager utvider for hotspot-abonnenter, dekket i vår guide til 10.5.50.1-hotspot-gatewayen og User Manager.
Lokale secrets slutter å skalere i intervallet hundrevis til tusenvis, der det å redigere én ruter per kundeendring blir flaskehalsen. På det punktet flytter du autentiseringen til en ekstern RADIUS-server, og konsentratorene spør bare RADIUS om en pålogging er gyldig — slik holdes abonnentdatabasen ett sted.
Trinn 4 — Aktiver PPPoE-serveren på tilgangsgrensesnittet
Slå nå på tjenesten. Legg til en PPPoE-server med /interface pppoe-server server, bind den til grensesnittet vendt mot tilgangsnettet ditt (en port, VLAN eller bridge), sett dens default-profile til profilen fra Trinn 2, og velg autentiseringsmetodene — pap, chap eller mschap2. RouterOS svarer da på PPPoE-discovery på det grensesnittet og autentiserer enhver klient som logger på med en gyldig secret.
To innstillinger betyr noe i stor skala. Alternativet one-session-per-host hindrer en abonnent i å åpne flere samtidige økter, og max-mtu/max-mru bør settes slik at PPPoE-overhead ikke fragmenterer kundetrafikk. Der tilgangsnettet er segmentert per kunde eller sone, dekker vår guide til MikroTik bridge-konfigurasjon Lag 2-grunnlaget serveren bygger på.
Trinn 5 — Legg til NAT- og brannmurregler
Hvis du tildelte abonnenter private adresser i Trinn 1, trenger trafikken deres oversettelse. Legg til en masquerade-regel i srcnat-kjeden bundet til WAN-utgangsgrensesnittet ditt, slik at hver PPPoE-økt når internett — de samme NAT-grunnprinsippene dekket i vår guide til å konfigurere NAT på MikroTik. Hvis du delte ut offentlige IP-er, hopp over masquerade og rut blokken.
Beskytt deretter konsentratoren. PPPoE-tjenesten bør være tilgjengelig for abonnenter, men ruterens administrasjonsgrensesnitt bør ikke, så legg til brannmurregler som dropper Winbox-, API- og WebFig-tilgang fra abonnentvendt side. En konsentrator som bærer reell kundeinntekt er nettopp enheten du ikke vil ha tilgjengelig fra en kapret økt.
Trinn 6 — Styr og verifiser flåten eksternt
Her er delen enkeltruter-veiledninger hopper over. Å reise PPPoE på én maskin er enkelt; å kjøre identiske profiler, MTU-innstillinger og brannmurregler på dusinvis av konsentratorer — og å bevise at hver enkelt autentiserer økter og håndhever de rette rate limits — er det reelle ISP-problemet. Det blir vanskeligere når en tilgangsruter sitter bak Carrier-Grade NAT uten offentlig IP, stadig vanligere etter hvert som operatører lener seg på LTE- og Starlink-opplinker.
Det er her sentralisert styring gjør seg fortjent: MKController holder hver ruter tilgjengelig over en autentisert utgående tunnel selv når den ikke har en offentlig adresse — samme tilnærming som i vår guide til MikroTik fjerntilgang bak CGNAT — slik at du reviderer konfigurasjon og skyver rettelser ut på hele flåten, med telemetri som markerer en maskin med tapte økter før kundene ringer.
Tips
- Lag mal av profilen, ikke av secrets — hver abonnementsendring bør berøre én profil, aldri tusenvis av kontoer.
- Følg med på konsentratorens CPU: kø-per-økt fra
rate-limitlegger seg opp, og en overbelastet maskin slipper økter i stillhet. - Sett
max-mtu/max-mrubevisst. PPPoE legger til 8 byte overhead, og den resulterende fragmenteringen er den skjulte årsaken til de fleste “det er tregt på ett sted”-sakene. - Sentraliser autentisering utover noen hundre brukere — lokale secrets spredt på rutere blir umulige å revidere.
Styr hele PPPoE-kanten din fra én skjerm
En PPPoE-server på én MikroTik er enkel. Å kjøre den på tvers av en ISP-flåte — identiske profiler, riktig rate-limit-retning på hver maskin, styringen låst og bevis for at hver konsentrator autentiserer selv bak CGNAT uten offentlig IP — er der operatører taper hele ettermiddager. Det er oppgaven MKController er bygget for: nå hver ruter over en sikker utgående tunnel, revidere konfigurasjon, se live-økter og skyve en rettelse ut på hele flåten på én gang, med telemetri som markerer en maskin med tapte økter før en kunde i det hele tatt ringer. Slik gjør ISP-er som kjører PPPoE på MikroTik en ruter-for-ruter-plikt om til ett enkelt kontrollplan.