MikroTik IPv6 DIGI PPPoE-vel

Sziasztok!

Elég sokat szórakoztam az utóbbi időben a MikroTik és az IPv6 kapcsolatával, hogy elérjem a számomra legoptimálisabb állapotot. Jelenleg DIGI-vel használom, azaz egy darab /64-es prefixet kapok, így ezt egy hálózatban tudom felhasználni. Az eszközök el vannak tűzfalazva, azaz befelé új kapcsolat nem jöhet, kivétel a related és established, kifelé viszont mehet a kommunikáció a kliensekről. A routerről szintén mehet minden kifelé, de befelé én csak az SSH-t engedem. Ezen kívül a DHCPv6 működését is lehetővé teszem a tűzfalon. Álljon tehát itt a beállítás menete!
A leírást 2021-12-21-én frissítettem, a scriptek kíméletesebbek a flash-sel, ROS7-esek (ROS6-on szerintem nem is mennek), és stabilabbak.

A lépéseket elsősorban CLI-n, másodsorban - egy darabig - a WebFig-en keresztül fogom megmutatni. Grafikus interfészt egyáltalán nem használok (WinBox, WebFig), így a WB-ről semmi tapasztalatom.
A CLI-t elérhetjük SSH-n, vagy a WinBox terminal részén. A WebFig pedig a webes kezelőfelület.

Első lépésként állítsuk be a PPPoE interfészre a service-name-t. Ez elvileg nem kell, gyakorlatilag nekem csak így volt hajlandó működni.
Lépjünk ide:
/interface/pppoe-client
Print-tel írassuk ki az interfészeket, majd a DIGI-sre állítsuk be a service-name-t. Ha például 0-ás az ID-je.
set 0 service-name="digi"
WebFig esetén katt az interfaces-re, majd a PPPoE kapcsolatra a táblázatban, és a Dial Out-nál a Service-hez kell írni "digi" (idézőjelek nélkül).
Nézzük meg azt is, milyen profile van hozzá beállítva (alapból default), későb kelleni fog.

Következő lépés a DHCPv6 kliens beállítása
CLI-n:
/ipv6/dhcp-client
add interface=digi-pppoe pool-name=digi request=address,prefix
WebFig: Katt IPv6 > DHCP Client, és adjunk hozzá egy új elemet.
Interfész a PPPoE interfész (fenntebb láthattuk)
request: address,prefix
Pool Name: digi
Pool Prefix Length: 64
Use Peer DNS: Igény szerint, használja-e a DIGI-s DNS-t
Minden más maradhat, ahogy van.
Mentés után meg kell jelennie a prefixnek, és a címnek.

Harmadik lépés, a RA beállítása
Két út áll előttünk a címek osztását tekintve. Vagy RA-val (ilyenkor a kliensek kérnek címet EUI64-gyel), vagy DHCPv6 szerver. Mivel a DIGI-nél rendszeresen változik a prefix, ezért maradunk a RA-nál, ezzel kapnak címet a LAN hálózatomban (br-lan bridge) lévő gépek.
CLI:
/ipv6/address
add address=::1 from-pool=digi interface=br-lan
WebFig: IPv6 > addresses
Katt az add-ra, majd a From Pool-hoz "digi" (idézőjelek nélkül), és az interface-nél a LAN interfész (nálam br-lan). Az address legyen ::1/64. Ez azért fontos, mert a két kettőspont mentén töri a címet a szkript (ld. lenntebb).
Ezen kívül mást nem is kell piszkálni, mehet a mentés.
Azzal, hogy ::1 lett a cím, az interfész /64-es prefix-én a ::1 mindig a routerre fog mutatni.

Negyedik lépés, finomítás és tűzfal (teljesen újraírva)
Alapvetően az IPv6 szabvány nem úgy van kitalálva, ahogyan az IPv4, vagy is nem szereti a rendszeres címváltozásokat. Mivel a v6 még nincs olyan nagyon elterjedve, a gyártók nincsenek lépéskényszerben, így még kedvenc RouterOS-unk sem képes kezelni ezt a problémát. Emiatt készítettem néhány scriptet, amik majd elő fognak szépen lassan jönni.
Először be kell állítani a RA-t, hogyan hirdesse a címeket. Mivel abszolút CLI-n vagyok (ahogy fenntebb írtam), ezért itt elhagynám a GUI-s maszatolást, talán kikövetkeztethető a dolog.
Az alap, összes IF-re vonatkozó beállítást teljesen kikapcsoljuk
/ipv6 nd
set [ find default=yes ] disabled=yes
Egy sajátot pedig felveszünk
add advertise-dns=no interface=br-lan ra-delay=0s ra-interval=3m-6m ra-lifetime=10m
Ezzel beállítottuk a RA packetek-et, hogy 3--6 percenként legyen újrahirdetés. Ez bőségesen elég, ha 1--2 hirdetmény (pl. Wi-Fi) nem érne célba, az előző élettartama alatt még bőven van lehetőség próbálkozni.
Következő lépésben némi prefix-specifikus beállítást kell elvégezni. Ennek annyi a baja, hogy mint említettem dinamikus az egész, emiatt nem tudunk konkrét előtagot beállítani, csak a default-ot. ennek nyilvánvaló hátránya, hogy ha használnánk ULA-t, akkor azt mindenképp kézzel kéne felparaméterezni ettől eltérően, másik dinamikus prefixet meg kb esélytelennek tartok így használni. No de.
Állítsuk be, hogy a RA csomag maximálisan 33 percig éljen, de preferáltan 30 percig. A preferált és a valid közt annyi az eltérés, hogy preferált után már befelé nem lehet új kapcsolatokra használni, és ha van új cím, mindenképp azt fogja preferálni az OS. Ezt viszont a cím élettartama miatt úgy sem érjük el, mert dinamikus a prefix, ezért nem tudjuk, mikor kell eröltetve lejártra rakni minden IPv6 kliensen a RA-t.
/ipv6 nd prefix default
set preferred-lifetime=30m valid-lifetime=33m

Mivel dinamikus a prefix, emiatt le kell kezelni a változásokat. Ehhez scripteket kell létrehozni, amit én böngészővel csináltam, a router IP-jének 80-as portján, a system > scripts helyen, itt a legegyszerűbb a szkripteket kezelni. A scriptekben változókat kell megadni, ezek esetemben
wan if: digi-pppoe
desiredif / LAN if: br-lan
pool: digi
Hozzunk létre egy újat, legyen a neve ipv6-up, tartalma pedig ez. Közvetlen a fájl a raw linken lehet elérni.
Most hozzunk létre egy új scriptet pppoe-up néven, ezzel a tartalommal
:execute [/system/script/run ipv6-up]
majd mentés (OK). Ez így egy kicsit nyakatekert, de az az oka, hogy ha valaki használni akarja azt a scriptet is, ami specifikusan engedi eszközök elérését kívülről (mint a port forward), annak egyszerűbb dolga legyen.
Hozzunk létre egy új scriptet, most ipv6-down néven, a tartalma pedig ez legyen. Itt is létre lehet hozni pppoe-down scriptet külön, ha valakinek esetleg van más is amit az interfész bontásakor futtatna, de alapvetően nem kell. A tartalmakat nyilván a source-ba kell rakni, jogosultságból meg én megadtam neki mindet, így működik.

Most CLI-n a
/ppp/profile
részen, vagy WebFig-en a PPP > Profiles részen a PPPoE kliensünk által használt profilra (alap esetben ez a default) az on-up-hoz vegyük fel a korábbi pppoe-up profilt, a down-hoz pedig az ipv6-down-t. A down-nál lehet ugye más is, ahogy fenntebb írtam, csak akkor abból hívjuk meg ezt az ipv6-down-t.
set 0 on-up="pppoe-up" on-down="ipv6-down"

Ezzel az IPv6-os címkiosztás, és a lejáró címek problémája megoldva. HA eljön a heti PPPoE bontás ideje, a bontóscript lefut, megkísérli lenullázni a címeket a klienseken (tapasztalat szerint többnyire sikeresen), majd a következő sikeres PPPoE kapcsolódásnál újra elkezdi hirdetni, a már új prefix-et.

És végül a feketeleves,a tűzfal. Mivel IPv6-nál nincsen NAT, ezért by-default, MT eszközökön minden eszköz elérhető kívülről. Aki nem hiszi, járjon utána, azaz próbálja ki.
Fokozni fogjuk a biztonságot, szerintem ez egy minimális-elégséges IPv6 tűzfal. CLI-ről mutatom a parancsokat, ki lehet következtetni mit kell a WebFig megfelelő részén beállítani (IPv6 > Firewall).
/ipv6/firewall/filter
add action=accept chain=forward comment="related,established to clients" connection-state=established,related
add action=accept chain=forward comment="all out on DIGI" out-interface=digi-pppoe
add action=accept chain=forward comment="allow ICMPv6 on forward" protocol=icmpv6
add action=accept chain=input comment="related,established to router" connection-state=established,related
add action=accept chain=input comment="ICMP to router" protocol=icmpv6
add action=accept chain=input comment="DHCPv6 to router" dst-port=546 protocol=udp src-port=547
add action=drop chain=forward
add action=drop chain=input

Ha ez megvan, akkor van egy működő IPv6 konfigunk a MikroTik router-ünkön, ami az eszközöket megvédi a kintről jövő új kapcsolatoktól, viszont ebbe beletartozik, hogy ha van egy háziszerverünk például, SSH-n azt sem lehet majd elérni.
Ennek a problémának a megoldásában segít ez a script.
Ezt is fel kell venni a script-ek közé, mondjuk dynamic-ipv6-firewall néven. A változókat fenntebb leírtam, itt is azokat kellene használni.
A script tetején van egy machines tömb, itt vesszük fel a kliensek EUI64-es címét, vagy is a cím második részét, amit célszerű fixálni (alap esetben a legtöbb eszközön random, hogy a változó prefix és a fix második rész egyben kitegyen egy olyan címet, amire már beengedhető a forgalom.
A példa kedvéért két eszköz van a tömbben, a címük második felével. A címfixálást én most Debian-on mutatom, hogy kell, de más disztrókon sem lehet nagyon eltérő. Fel kell venni a /etc/sysctl.conf-ba az alábbi két sort
net.ipv6.conf.default.addr_gen_mode = 0
net.ipv6.conf.eth0.addr_gen_mode = 0
(A második sorban az eth0-t lehet, át kell írni a valós interfészre)
Eztán sudo sysctl -p, meg célszerű újraindítani a hálózatot is. Ezutóbbi rendszerfüggő, egy géprestart mindenesetben megoldja.
Eztán az ip a paranccsal lehet megnézni adott IF-nél mi ez a második rész. Valami ilyesmit kell látni
inet6 2a01:36d:4444:4444:abcd:cbda:1234:4321/64 scope global dynamic mngtmpaddr
valid_lft 1946sec preferred_lft 1766sec
A 4444:4444-ig a prefix, az abcde-vel kezdődően meg már a suffix, tehát ahogy a példában is látszik, úgy kell megadni, ahogy itt látszik. Persze ez éles esetben más lesz, az EUI64 a MAC alapján generálódik.
HA beállítottuk, mentés után a pppoe-up script végére érdemes rakni egy ilyet. A delay késleltet egy kicsit, utána jön csak a script, hogy biztosan kapjon címet.
:delay 3s
:execute [/system/script/run dynamic-ipv6-firewall]

Ennyi lenne. Ez a második rész nem kötelező az első rész működéséhez, így aki annak a végéig, vagy aki idáig eljutott, annak gratulálok, a tudomásom szerinti legjobb IPv6 kezelés birtokosa, amire a Router OS képes az itthoni PPPoE-s dinamikus IPv6 prefixes hálózatokon.
A scriptek forrása GitHub repo.

Az építő jellegű kritikákat kommentben várom, viszont ha valami segítség kell, akkor célszerűbb ha a MikroTik topik-ba írtok, erre ritkábban járok. Bízom benne, tudtam segíteni az IPv6 után áhítozó MikroTik felhasználóknak, és köszönöm, hogy elolvastad!

Frissítve: 2021-12-21

Hirdetés

3 pénzügyi döntés, amit minden kisvállalkozónak érdemes átgondolnia az év végéig

PR Ahogy az év vége közeledik, itt az ideje, hogy egy pillanatra megálljunk és áttekintsük vállalkozásunk pénzügyi helyzetét. Ne hagyjuk, hogy az év utolsó hónapjai elússzanak a sürgető feladatok és elfeledett határidők között!

Még van hozzászólás! Tovább