2022. szeptember 28., szerda

Gyorskeresés

MikroTik IPv6 DIGI PPPoE-vel

Írta: | Kulcsszavak: MikroTik . IPv6 . DIGI . RouterOS . ROS . dinamikus IPv6

[ ÚJ BEJEGYZÉS ]

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

Hozzászólások

(#1) UnA


UnA
Korrektor

Csak kíváncsiságból: mi értelme van egy IPv6 belső hálózatnak? (vagy csak én nem értek hozzá :) )

(#2) adika4444 válasza UnA (#1) üzenetére


adika4444
addikt

Ez nem belső hálózat, hanem a prefix beállítása, hogy legyen IPv6 forgalom a gépeken.

üdv, adika4444

(#3) UnA válasza adika4444 (#2) üzenetére


UnA
Korrektor

Biztosan velem van a probléma, mert még mindig nem látom az értelmét. Esetleg tanulós hálózatnak, talán...

(#4) adika4444 válasza UnA (#3) üzenetére


adika4444
addikt

Az IPv6 az IPv4-et hivatott lecserélni, mert sokkal több címet lehet kiosztani. Viszont teljesen más a filozófiája, emiatt a beállítása is, és még sokszor a gyártók sincsenek rá felkészülve, a felhasználókról nem is beszélve.

Jelenleg a v4 és a v6 egymás mellett él, de idővel utóbbi fog dominálni.

üdv, adika4444

(#5) UnA válasza adika4444 (#4) üzenetére


UnA
Korrektor

Az elméleteket ismerem, nem ez volt a kérdés - és pont a különbségek miatt nem látom azt a gyakorlati felhasználást, ahol egy olyan hálózaton le kellene cserélnem az IPv4-et, amit én menedzselek.

(#6) adika4444 válasza UnA (#5) üzenetére


adika4444
addikt

Manapság még valóban el lehet lenni az IPv6 nélkül. Viszont ha rendesen be van lőve, akkor nem gond, ha a DIGI IPv4-en NAT-ol, hisz v6-on elérhetik egymást az eszközök, illetve a Telekom is nyújtja már a v6-ot mobilneten, ahol a v4 szintén NAT-olt, és nehéz / lehetetlen kikapcsoltatni.
Az meg amúgy sem árt, ha az ember felkészül:D

üdv, adika4444

(#7) UnA válasza adika4444 (#6) üzenetére


UnA
Korrektor

Köszi :)

(#8) ncc1701


ncc1701
addikt

Köszi a leírást, működik. :)

(#9) Zwodkassy


Zwodkassy
senior tag

Aranyos leírás.
Én a MikroTik alap (default) IPv6 tűzfal konfigjából építkeztem. Valahol találtam is hozzá magyarázato(ka)t.

Talán itt :
https://help.mikrotik.com/docs/display/ROS/Building+Your+First+Firewall

[ Szerkesztve ]

(#10) Zwodkassy válasza adika4444 (#6) üzenetére


Zwodkassy
senior tag

Egyébként igen. Ma még lehet élni csak IPv4 alapon is, de látható az IPv6 térnyerése. Úgyhogy nem árt megismerni a jövő technikáját.

További hozzászólások megtekintése...
Copyright © 2000-2022 PROHARDVER Informatikai Kft.