MikroTik PPPoE-server til ISP'er

Resumé En MikroTik PPPoE-server lader en ISP autentificere abonnenter, tildele hver en IP-adresse og håndhæve en hastighedsgrænse pr. abonnement — alt sammen fra RouterOS, uden ekstern RADIUS ved små installationer. Opsætningen er en kort, ordnet kæde: en IP-pool, en PPP-profil, abonnent-secrets, PPPoE-tjenesten og NAT. Det sværere problem er ikke at konfigurere én koncentrator, men at køre en konsistent, verificerbar konfiguration på mange af dem — ofte bag CGNAT. Denne guide dækker begge.

Hvad Er en MikroTik PPPoE-server?

En MikroTik PPPoE-server er en RouterOS-tjeneste, der autentificerer hver abonnent over Point-to-Point Protocol over Ethernet, giver dem en IP fra en pool og anvender en profil, der styrer deres gateway, DNS og hastighedsgrænse. Sådan håndterer de fleste små og mellemstore ISP’er kundeforbindelser: en kunde logger på med brugernavn og adgangskode, serveren tjekker legitimationsoplysningen, og sessionen arver det tildelte abonnement — autentificering pr. bruger, IP-tildeling og båndbreddekontrol uden separat udstyr (MikroTik-dokumentation — PPPoE).

PPPoE forbliver ISP-standarden på grund af ansvarlighed. Hver abonnent har en individuel legitimationsoplysning, så du kan deaktivere en konto ved manglende betaling, se hvem der er online, og binde en fast adresse eller hastighed til en person — intet af dette leverer bridge- eller DHCP-levering rent. Hele konfigurationen koger ned til én idé: definér abonnementet én gang i en profil, og tilknyt derefter abonnenterne til det.

Trin 1 — Opret IP-poolen

Start med de adresser, RouterOS låner ud til abonnenter. En pool er en navngivet blok — for eksempel /ip pool add name=pppoe-pool ranges=10.20.0.2-10.20.255.254 — dimensioneret efter de samtidige sessioner, denne koncentrator vil bære, med spillerum. Hold profilens gateway-adresse (altså local-address) uden for det udlånbare interval, så den aldrig ved et uheld gives til en klient.

Dimensionér poolen efter hardwaren — en beskeden router klarer hundredvis af sessioner, en enhed i CCR-klassen tusindvis (Tech@Layer-x — PPPoE Server on MikroTik for ISP Deployments). For at uddele offentlige IP’er i stedet, ret poolen mod din rutbare blok og spring NAT i Trin 5 over.

Trin 2 — Byg PPP-profilen

PPP-profilen er, hvor et abonnement lever. Den sætter local-address (den gateway, hver abonnent ser), remote-address-poolen fra Trin 1, DNS-serverne og — vigtigst for en ISP — den rate-limit, der begrænser hver session. Tildel profilen til en abonnent, og de arver hastigheden, så et “20/10”-abonnement er én profil genbrugt på tusindvis af konti (madankc.com.np — MikroTik PPPoE Server Complete Setup Guide).

Én detalje snyder næsten alle: retningen. RouterOS læser profilens rate-limit som rx-rate/tx-rate set fra serverens synspunkt — abonnentens upload først, download derefter, det modsatte af, hvordan kunder beskriver deres abonnement. En pakke “100 Mbps ned / 30 Mbps op” skrives rate-limit=30M/100M. Vend det om, og hver kunde får i stilhed et byttet abonnement — netop den flådedækkende fejl, som skabelonkonfiguration forhindrer.

Trin 3 — Tilføj abonnent-secrets

Hver abonnent har brug for en “secret” — et brugernavn, en adgangskode og den profil, der definerer deres abonnement, oprettet under /ppp secret. For en lille base er dette hele brugerdatabasen: tilføj en secret pr. kunde, fastgør eventuelt en fast remote-address for en statisk IP, og deaktivér secret’en for at afbryde tjenesten. Det er den samme ansvarlighed pr. legitimationsoplysning, som MikroTiks User Manager udvider for hotspot-abonnenter, dækket i vores guide til 10.5.50.1-hotspot-gatewayen og User Manager.

Lokale secrets holder op med at skalere i intervallet hundreder til tusinder, hvor det at redigere én router pr. kundeændring bliver flaskehalsen. På det tidspunkt flytter du autentificeringen til en ekstern RADIUS-server, og koncentratorerne spørger blot RADIUS, om et login er gyldigt — så abonnentdatabasen holdes ét sted.

Trin 4 — Aktivér PPPoE-serveren på adgangsgrænsefladen

Tænd nu for tjenesten. Tilføj en PPPoE-server med /interface pppoe-server server, bind den til grænsefladen vendt mod dit adgangsnetværk (en port, VLAN eller bridge), sæt dens default-profile til profilen fra Trin 2, og vælg autentificeringsmetoderne — pap, chap eller mschap2. RouterOS svarer derefter på PPPoE-discovery på den grænseflade og autentificerer enhver klient, der logger på med en gyldig secret.

To indstillinger betyder noget i stor skala. Indstillingen one-session-per-host forhindrer en abonnent i at åbne flere samtidige sessioner, og max-mtu/max-mru bør sættes, så PPPoE-overhead ikke fragmenterer kundetrafik. Hvor adgangsnetværket er segmenteret pr. kunde eller zone, dækker vores guide til MikroTik bridge-konfiguration Lag 2-grundlaget, som serveren bygger på.

Trin 5 — Tilføj NAT- og firewallregler

Hvis du tildelte abonnenter private adresser i Trin 1, har deres trafik brug for oversættelse. Tilføj en masquerade-regel i srcnat-kæden bundet til din WAN-udgangsgrænseflade, så hver PPPoE-session når internettet — de samme NAT-grundprincipper dækket i vores guide til at konfigurere NAT på MikroTik. Hvis du uddelte offentlige IP’er, spring masquerade over og rut blokken.

Beskyt derefter koncentratoren. PPPoE-tjenesten bør være tilgængelig for abonnenter, men routerens administrationsgrænseflader bør ikke, så tilføj firewallregler, der dropper Winbox-, API- og WebFig-adgang fra abonnentvendt side. En koncentrator, der bærer reel kundeomsætning, er netop den enhed, du ikke vil have tilgængelig fra en kapret session.

Trin 6 — Styr og verificér flåden eksternt

Her er den del, enkeltrouter-vejledninger springer over. At rejse PPPoE på én maskine er nemt; at køre identiske profiler, MTU-indstillinger og firewallregler på snesevis af koncentratorer — og at bevise, at hver enkelt autentificerer sessioner og håndhæver de rette rate limits — er det reelle ISP-problem. Det bliver sværere, når en adgangsrouter sidder bag Carrier-Grade NAT uden offentlig IP, stadig mere almindeligt, efterhånden som operatører læner sig op ad LTE- og Starlink-uplinks.

Det er her, central styring gør sig fortjent: MKController holder hver router tilgængelig over en autentificeret udgående tunnel, selv når den ikke har en offentlig adresse — samme tilgang som i vores guide til MikroTik fjernadgang bag CGNAT — så du reviderer konfiguration og skubber rettelser ud på hele flåden, med telemetri, der markerer en maskine med tabte sessioner, før kunderne ringer.

Tip

• Lav skabelon af profilen, ikke af secrets — hver abonnementsændring bør røre én profil, aldrig tusindvis af konti.
• Hold øje med koncentratorens CPU: kø-pr-session fra rate-limit lægger sig oven i hinanden, og en overbelastet maskine taber sessioner i stilhed.
• Sæt max-mtu/max-mru bevidst. PPPoE tilføjer 8 byte overhead, og den resulterende fragmentering er den skjulte årsag til de fleste “det er langsomt på én lokation”-sager.
• Centralisér autentificering ud over et par hundrede brugere — lokale secrets spredt på routere bliver umulige at revidere.

Styr hele din PPPoE-kant fra én skærm

En PPPoE-server på én MikroTik er nem. At køre den på tværs af en ISP-flåde — identiske profiler, den rigtige rate-limit-retning på hver maskine, styringen låst og bevis for, at hver koncentrator autentificerer selv bag CGNAT uden offentlig IP — er der, hvor operatører taber hele eftermiddage. Det er den opgave, MKController er bygget til: nå hver router over en sikker udgående tunnel, revidere konfiguration, se live-sessioner og skubbe en rettelse ud på hele flåden på én gang, med telemetri, der markerer en maskine med tabte sessioner, før en kunde overhovedet ringer. Sådan forvandler ISP’er, der kører PPPoE på MikroTik, en router-for-router-pligt til ét enkelt kontrolplan.

Start din gratis MKController-prøveperiode