Két legyet egy csapásra - ismerkedés a Mikrotik és a pfSense világával

 ( gergelykiss | 2018. november 4., vasárnap - 23:47 )

Mivel a jelenlegi munkahelyemen sajnos nincs lehetőség (és általában idő sem) a saját továbbképzésemre, ezért amennyire a szabadidőm engedi, ki szoktam találni magamnak különféle hobbiprojekteket, hogy ezeken keresztül új megoldásokkal tudjak szabadon, kötöttségek és határidők nélkül megismerkedni. Legutóbb azt vettem a fejembe, hogy az otthoni Netgear WNDR4300-as routeremet lecserélem egy profibb/gyorsabb/modernebb megoldásra...

Sokszor hallottam már elismerően nyilatkozni szakmabelieket a Mikrotik eszközökről, illetve a pfSense-zel is szemezek már egy ideje, így arra gondoltam, megpróbálok felépíteni egy routert ezekből otthonra. A megoldás két alappillére egy Mikrotik hAP ac^2 access point, illetve az (egyébként is non-stop üzemben működő) HTPC-re KVM alá felhúzott, 2.4-es verziójú pfSense lett.

A Mikrotikkel volt már dolgom korábban, de nem mélyültem el a működésében különösebben, a webes varázsló felülettel lőttem be egy szimpla router-t az egyik ügyfélnek, ami kb. 2 perc volt vakarózással együtt. A megfelelő eszköz felkutatása során a Mikrotik routerek ár/érték aránya fogott meg először: a ma kapható legolcsóbb SOHO kategóriás Mikrotik doboz már 6-7 ezer Ft-ért beszerezhető, ami elképesztően alacsony ár a hasonló tudású, széles körben elterjedt "nagy" gyártók routereihez képest. Ezért a pénzért egy level 4-es licenccel szállított routert kapunk, rendkívül aprólékos konfigurálási lehetőségekkel. A jelenleg kapható legkisebb modell (hAP lite) egyetlen említésre méltó hátránya a 100 megabites switch, de legyünk realisták: egy egyszerű, netmegosztásra használt otthoni hálózaton ADSL vagy koax kábeles netkapcsolat mellé akár ez is elegendő lehet.

Mivel otthon digis internetünk van, így mindenképp gigabites modellt akartam venni a későbbi bővíthetőséget szem előtt tartva. Leginkább az ár/érték aránya miatt a már említett hAP ac^2-es modellt választottam végül. Ez a kis doboz alapvetően mindent tud, amit ma egy modern otthoni routernek tudnia kell: 802.11ac szabványú wifi, ötportos gigabites switch, és ezek kiszolgálásához egy kellően gyors és modern SoC 2 Gbps korüli switching és routing képességgel és a tudásához képest relatíve alacsony fogyasztással (15W). Ez a modell biztosan nem a design-ja miatt lesz emlékezetes (mondhatni "ronda és finom", ha esetleg emlékszik még valaki...), igazából elég minimalista a formatervezés: egyszínű, fekete gumírozott ház, elől kis dobókocka pötyökkel, hátul számozással a switchportok felett, és még néhány általános jelölés itt-ott. A némileg egyhangú külső ellenére elég fejlett a hardver, és a beépített 2,5 dBi-s antennák egy kis panellakásban tökéletesen elegendőnek bizonyultak a tesztek alapján lefedettség és sebesség szempontjából is (de erről később).

A csomagolásból kibontva egy default konfigurációval áll fel a rendszer, amit az 192.168.88.1-es IP-címre kapcsolódva lehet hegesztgeni webes felületről vagy a WinBox nevű tool-lal. Mivel az én esetemben nem router-ként, hanem csak szimpla switch+AP kombóként akartam beállítani, így első lépésként töröltem a konfigot. A windows-os beállító szoftver nagyon praktikusnak bizonyult, az kifejezetten tetszett, hogy az IP-cím ismerete nélkül, MAC-cím alapján is lehet kapcsolódni a dobozhoz (CDP rulez :), ami nem csak az első konfigurálásnál, de egy elbaltázott IP-konfiguráció (vagy feledésbe merült IP-cím) esetén is nagy segítség tud lenni.

Első körben a switchet kezdtem el felkonfigurálni: az elképzelés az volt, hogy az 1-es portba megy a Digi UTP kábele, az 5-ösbe pedig a HTPC, egy trönkölt kapcsolattal (1-es VLAN: belső háló, 2-es VLAN: internet), a maradék három port sima access port lesz az 1-es VLAN-on belül. Ezt alapvetően nem nehéz beállítani, viszont ahogy az ide vonatkozó wiki oldalon írtakból is kiderül, az általam használt eszköz Atheros 8327-es switch IC-vel van szerelve, ami kicsit rendhagyó módon kezeli a VLAN-okat a többi chiphez képest. Itt nincs hatása a "VLAN header" opcióknak (add-if-missing | always-strip | leave-as-is), mivel a chip egy belső logika mentén dönti el, hogy egy frame-et tagelve vagy tagelés nélkül kell-e kiküldenie. A wiki oldalon három helyen is említést tesznek erről, viszont ezek egymásnak ellentmondanak, így kicsit magamra maradtam, csak kísérletezgetéssel tudtam rájönni, hogyan is kellene a trönkportot beállítani... órákhosszat nézegettem a doksit és kísérletezgettem a beállításokkal, mire nagy nehezen meglett a "helyes megfejtés". Ez a switch IC a "default-vlan-id" beállítás alapján dönti el, hogy az adott porton kell-e tagelni a kiküldött frame-eket vagy sem, miközben "belsőleg" minden frame tagelve van. Ez azt jelenti, hogy a trönkportot be kellett raknom egy "kamu" VLAN-ba (egy olyan ID-t adtam meg a default-vlan-id beállításban, ami nincs definiálva a VLAN táblában), így már mindkét VLAN forgalma rendesen, tagelve ment ki a HTPC felé. A tagelési logikához még hozzátartozik, hogy ha két olyan port között továbbít forgalmat a switch, amik azonos natív VLAN-ba tartoznak, akkor a frame automatikusan tag nélkül fog továbbítódni - ebből kiindulva a Digi-s portnak a 2-es ID-t állítottam be default-nak, a belső hálózat access portjaira pedig értelemszerűen az 1-est.

A switch konfigurálás után beállítottam a wifi interfészeket (2.4 és 5GHz), az IP-paramétereket (cím, gateway, DNS szerver), belőttem egy NTP klienst, végül összefogtam egy bridge-be az 1-es VLAN-ba tartozó interfészeket (4 switchport + 2 wifi interfész). Ez már csak opcionális, de mivel nem a Mikrotik eszköz lesz a router hálózatban, kikapcsoltam az "IP forwarding" opciót és a biztonságos működést szem előtt tartva letiltottam minden felesleges feature-t (itt szépen összeszedték egy kupacba a legfontosabb beállításokat). A wiki egyébként nagyon sokat segített a konfigurálásban, a switch konfigurálásával kapcsolatos szívásokat leszámítva szép részletes, mindenféle eshetőségre kitérő doksit sikerült összeraknia a gyártónak. A beállítófelület egyébként elég jól áttekinthető, mindig rájöttem magamtól, mit hol keressek, és a legtöbb paramétert önállóan, a dokumentáció böngészgetése nélkül be tudtam állítani.

Jöjjön hát a pfSense telepítése!

A pfSense-ről régóta tudom, hogy BSD-alapokon nyugszik (FreeBSD alaprendszer és OpenBSD-ből portolt komponensek elegye), amit a pár hónapja megejtett FreeBSD-re átállás csak még szimpatikusabbá tett. A pfSense otthonra kicsit verébre ágyú kategória, mivel egy elég komplex rendszerről beszélünk, egy szimpla tűzfal-routing-NAT kombót össze lehet hozni sokkal egyszerűbben is, de ahogy írtam is az elején, elsősorban önképzés miatt döntöttem a pfSense használata mellett. A telepítés roppant egyszerű, gyakorlatilag egy az egyben a FreeBSD installerére épül az egész, ez a rész semmi meglepetést nem tartogatott. Telepítés után még konzolos módban konfigurálni kellett pár alapvető hálózati beállítást (VLAN-ok, IP-címek, LAN/WAN interfészek kijelölése), viszont ezt követően rögtön elérhetővé vált a webes felület, ahol egy gyorsbeállító felületen keresztül percek alatt össze lehetett kattintani egy egyszerű, működő konfigurációt.

A virtualizáció miatt kicsit ügyködni kellett a VLAN-okkal a HTPC-n: először felkonfiguráltam a VLAN interfészeket, majd ezeket betettem egy-egy bridge-be, és ezeket bekötöttem a guest alá VirtIO interfészként. Ennek a megoldásnak előnye, hogy így a pfSense két, nem VLAN-osított interfészt lát, így ott már sokkal egyszerűbb dolgom volt a konfigurálással.

Konfigurálás után tesztelgettem kicsit a rendszert, néztem sebességet, konnektivitást, teljesen meggyőző volt az egész, leszámítva két furcsaságot:

1. A különféle sebességtesztes felületeknél csak a letöltési teszt működött, a feltöltési teszt mindig timeout-olt valami miatt.
2. A HTPC nem volt képes "kilátni" a netre, a névfeloldás működött, a ping működött, viszont semmilyen TCP kapcsolat nem tudott felépülni az internet felé.

Mint kiderült, mindkét jelenséget egy checksum offloading nevű feature okozta: ez a virtio interfésszel hibásan működik, ami valószínűleg az ethernet vezérlő driver-ének hiányosságára vezethető vissza. A megoldás: a System -> Advanced -> Networking menüben be kellett jelölni a "Disable hardware checksum offload" checkboxot, és voilá, mindkét probléma azonnal megoldódott.

Az ac-s wifi lefedettsége kiváló, a lakás különféle pontjain végeztem méréseket, mindenhol stabilan 80 Mbps fölötti sebességeket mértem a Digi felé, szakadozást, vagy átmeneti lassulásokat egyáltalán nem tapasztaltam. Ennél többet egyelőre nem tudok mondani, de az már most látszik, hogy a wifi jel abszolút stabil, nincsenek szakadozások vagy átmeneti lassulások se az n-es (2.4 GHz-es), se az ac-s (5 GHz-es) eszközökkel.

A konklúzió: nem csalódtam se a Mikrotikben, se a pfSense-ben, mindkettő profi, méltán elismert márka, azóta több ismerősnek is ajánlottam Mikrotik eszközöket SOHO környezetbe. A pfSense kapcsán egyedül a licencelés az, ami okozhat egy kis fejtörést, ugyanis hiába open source a projekt, a licenc nem engedi meg a közvetlen értékesítést: vagyis, el lehet adni egy hardvert, amin pfSense fut mint "tűzfal megoldás", de mint szoftvertermék, nem szabad értékesíteni (nem szerepelhet a számlán önálló tételként). Kicsit töprengtem eleinte, hogy pfSense-et vagy opnSense-et telepítsek, de nem igazán tudtam dűlőre jutni, így maradtam a pfSense-nél az eredeti elképzelésnek megfelelően. Ha esetleg van valakinek ide vonatkozó tapasztalata (azaz, miért éri meg opnSense-et használni pfSense helyett), várom a kommenteket! Ezt az (egyébként jól összeszedett) összehasonlítást néztem már, de nem igazán sikerült meglátnom a fényt az alagút végén (egyébként egy kicsit a LEDE vs. openwrt különválásra emlékeztet a sztori)...

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Köszi az összefoglalót!

Én egy hete kezdtem pfSense-t használni, szóval:
sub

Egyébként teljesen elégedett vagyok vele, nekem egy Hyper-V Server alatt fut, hibátlanul.
A hw az nálam Pentium N3700 (4 mag kiosztva), 1G ram, ennyi biztosan nem kell neki, de a szolgáltatások miatt megéri.
Ég és föld a TP-Link Archer C2-höz képest.

Amit sehogy sem sikerült megoldanom a műanyag dobozzal (openvpn szerver, network boot legfőképp) az itt gond nélkül, pár perc konfigurálással megoldható lett.
Nálam 80/20 mbit wan sebesség alig észrevehető CPU használattal simán megy, de állítólag lesz hamarosan FTTH-s Gigabit. Volt alkalmam kipróbálni ezt a vasat DIGI 1000 előfizetéssel, ott is ment simán 900 mbit fölött, bár akkor már érezhetően kevés tartalék maradt benne, igaz, futnak mellette más szolgáltatások is, pl. fájlszerver, dlna és egy teszt WDS.

A műanyag doboz azóta csak WIFI AP-ként van használva. :)

Köszi, jó összefoglaló.
Több év Mikrotik után Proxmox alapra otthoni kis fogyasztású házi szerveren használtam VM-ben pfSense, OPNsense, Sophos UTM Home tűzfalakat. A Sophos Home (otthonra ingyenes) a legkomplexebb ha mindenféle védelem kell, de ha sok minden be van kapcsolva akkor lassít is rendesen. Vagyis valószínűleg kellene neki az erősebb gép. Jelenleg OPNsense működik, maradtam is nála már jó ideje. A pfSense is hasonlóan jó volt. Nem tudok sok indokot egyik, másik felé, inkább szimpatizálás kérdése szerintem a kezelő felület, beállítások téren. OPNsense-re mintha jóval sűrűbben jönnének a frissítések.
A Mikrotik azóta nálam is wifi AP-ként üzemel.

Az OPNsense licensz azt hiszem barátságosabb is, ha már az is szóbakerült. Úgy tudom, maradtak sima BSD.

Amit próbáltam és se OPNsense, se pfSense alatt nem sikerült rendesen beállítanom az a Suricata. Egy rakat leírást, doksit végig böngészve se nagyon jött össze úgy hogy rövid idő után ne blokkoljon mondhatni mindent az internet felől. Persze lehet én értelmeztem rosszul valamit. Na és persze ez a része már erősen RAM és CPU igényes.
Sophos UTM-ben ezt az IDS,IPS dolgot valahogy úgy sikerült összehozni hogy nincs vele túl sok tennivaló, bekapcs és működik.

Mivel pár hónapja én is elkezdtem bohóckodni opnsense-el (nem szégyellem bevallani h. nem értek hozzá annyira, mint amennyire szeretnék), leírom én mit tapasztaltam:

Az opnsense vette a freebsd-t alaprendszernek. Ezt lecserélték egy 2-emberes hardenedbsd nevű forkolt hobbiprojectre. Ezzel azt nyerték, h. elvileg(!) sokkal secure-abb lett az OS, mint a kiindulási freebsd. Cserébe nincs mögötte szinte semekkora developer tömeg, és semekkora user bázis összehasonlítva a freebsd mögötti tömegekkel (ami még mindig sehol nincs a linux-hoz képest). Azaz ha pl. teljesítményproblémáid vannak, ami kernel v. driver kód miatt van, freebsd fórumok helyből kilőve: nem fognak tudni neked segíteni mert nem generic freebsd kernelt használsz, hanem valójában széjjelpeccselt hardenedbsd kernelt. Azaz kb. évekig is eltarthat mire javítják / backportolják az eredeti freebsd-ből hardenedbsd-be a fixet. Ha egyáltalán..

Az opnsense gyakorlatilag húzott egy konfig backendet+GUI frontendet a bsd fölé. Innentől 2 választása van az embernek:

1) vagy használja csak a GUI-t csak azokra a funkciókra, amikről a fejlesztők úgy gondoltak a usereiknek csak ennyire lesz szükségük.

2) Vagy, ha ezen kívül még más is kellene, akkor meg mehet CLI-be, és konfigolja kézzel.
Itt viszont átlag userként meg vagy lőve, mert developer/backend manualokat kellene átnyálazni: mi hogyan van megvalósítva a háttérben, hogy a te kézzel matatásod ne fektesse meg a rendszer konfig többi részét. Azaz freebsd doksikat olvasni megint zsákútca, mert a konfig fájlok helyett itt konfigd van, nem pont azokat és pont azokon a helyeken levő konfigfájlokat használja, amik a freebsd példákban szerepelnek. Na ez a része kínkeservesen lelassítja az embert, és a végén muszájból te is developerré kell előlépj ha piszkálni akarod. Fájdalmasan hosszú tanulási folyamat, és nem biztos h. megéri a belefeccolt munka.

Az opnsense-el dolgozni tipikus FOSS feeling: kaotikus, észnélkül lapátolják bele a fícsöröket. Dokumentálva semmi nincs! Tényleg semmi! Az installt letudják egy 2-3 oldalas szűkszavú next-next finish-el. Vadászhatod fórumból, github kommentekből h. mi újság. A howto-k nagy részét inkább pfsense-ből érdemes hozzánézni, ott értelmes(ebb)en le van írva minden, szépen hierarchikusan csoportosítva. Opnsense howto-k meg a "csak legyen vmi h. befogja a száját a user" szinten vannak sebtiben összehányva, kategórizálatlanul. Mivel náluk nincs leírva szinte semmi, túrhatod a freebsd alap manualjait. Remélve h. nem valami hardenedsd hülyeségbe futottál bele. Hardenedbsd manualja meg dettó ugyanaz, mint az opnsense doksijai. Vették a freebsd manual-t, és hozzáírtak 1-2 új fejezetet. De érzésre azok is félkész, elavultak. Valószínű emberhiány miatt az sem lesz használhatóbb állapotban sosem. Ha megakadtál, megpróbálhatod a pfsense doksijait, remélve a keresett rész nem különbözik a 2 rendszer között (túlságosan).

Ha nagyon megakadsz, és nem segít a fórum meg a community, még mindig vehetsz fizetős supportot az opnsense anyacégétől a Deciso-tól. Akik természetesen saját opnsense appliance-et is árulnak. Pfsense-nél pontosan ugyanez a helyzet, csak ott a Netgate nevű céggel.

Vagy ott van pl. a tűzfal rész, ami tisztán bsd-s "pf", az opnsense "csak" egy GUI-t tesz elé. A pf-ről magáról kb. semmit nem ír az opnsense, ergo a kedvenc tűzfal disztribed leglényegesebb részéhez hozzá tudj szagolni, kutathatsz külsős pf könyvek után.

Vagy be akarod állítani a pppoe-t: CLI-ből installkor nem kapsz rá lehetőséget, muszáj vagy GUI-ból csinálni. Eleve az opnsense CLI-s interfész beállítása magasan a legérthetetlenebb nyelvezetű az összes eddig látott *nix tűzfalhoz képest.

Vagy akarsz állítani bridge interfészt 2 NIC-re CLI-ből. Na ezt se tudod, csak GUI-ból. Ami akkor ciki, ha nincs konzol access-ed v. olyan NIC elérhető, amit nem érint a bridge konfigurálás. Hát nem triviális, az biztos.

Vagy névfeloldást akarsz beállítani. Van a rendszerben by default unbound, de van emellett még dnsmasq, és pluginként ott van a jó régi bind is. Na akkor most ki kivel van mikor és miért? Ki oldja fel a neveket a klienseknek, és ki a tűzfal doboznak magának? Szerintem nem átlátható.

És igen, valóban 2-hetente lehet updatelni egy tűzfalat! Általában muszáj is, mert mindig van benne olyan bug ami érint, és addigra kijavítják. Cserébe kerül bele új teszteletlen kód is, amiben megint lesznek bugok, szóval 2 héttel később megint lehet updatelni. És ez így pörög szerintem 3 éve, mióta opnsense van :-)

A digi gigabites internetet szintén érdekes kérdés egy opnsense mennyire bírja kihajtani. Nekem nagyon gyatra végeredmény jött ki, köszönhető a következőknek:
- mint utólag kiderült egy 4-core 1 ghz embedded AMD nem elég hozzá
- a digi pppoe protokollt használ, ebbe csomagolja az IP forgalmat. A pppoe pedig valamiért botrányosan gyengén muzsikál bsd-n. Mindenki csak tippelgeti h. most tényleg 1-szálú az interrupt handling ,hiába tud multi-queue-t az intel NIC, a receive oldal a szar RSS algoritmus miatt PPPOE esetén csak 1 queue-ba teszi a teljes pppoe forgalmat?
- a pf lassítja be a gigabitet 3-400 mbitre?

A többit olvasd el itt:

https://hup.hu/node/160279
--

Köszi, nekem nem is kell ennél több a pfSense vs. opnSense dilemma megoldásához. :)

Egyébként néztem most kábeles kapcsolattal is teszteket, stabilan 90/85 Mbps-os eredményeket mérek (Digi saját tesztelő felületén nézem), viszont közben úgy 170%-osan ki van terhelve 2 vCPU (igaz, kicsit gyengusz a vas, egy AMD Sempron 3850-es proci + 4 GB RAM)... nem kizárt, hogy egyszerűen ennyit tud ez a konfig (25W TDP!), de én inkább arra gyanakszom, hogy a PPPoE egyszálon futása lehet a háttérben (pláne, hogy a mérési eredményt nem befolyásolja, hogy 1 vagy 2 vCPU-t adok a VM-nek).

Ne értsd félre amit írtam, az opnsense, pfsense és úgy a'la natur a freebsd se alkalmas az APU2-n gigabit-es pppoe kezelésére, ha PF is képben van. Ugyanezen a vason egy Linux tűzfal disztrib netfilter-rel (pl. ipfire) sokkal jobban viszi, sokkal alacsonyabb load mellett! Nem éri el teljesen az sem a gigabitet, legyen mondjuk 800 mbit, de mégsem 200-250 (pillanatnyi állapot fv-ben). Valami nagson nem kóser a bsd+pf+pppoe trióval.
--

Végeztem méréseket PPPoE-vel ("házi" PPPoE szerverrel), sajnos sikeresen reprodukáltam az általad leírtakat. :(

A mostani 100/100-as nettel nem okoz gondot a lassúság, de ha gigabitre bővítenék (bármikor megtehetném, a házban kiépített infrastruktúra elbírja), a max. sebesség 30-40%-át tudnám csak kihasználni...

A CPU terhelés 67%-ig kúszott fel a pfSense-es VM-ben, a PPPoE szerveren kb. 10-12% volt a csúcs (egy magon mérve) és a terhelés arányosan eloszlott a négy mag között, így biztosan nem a szerver miatt jött ki ez a gyatra eredmény. Ahogy írtam az összefoglalóban, a Mikrotik doboz 2 Gbps switching sebességre képes (ez mért, valós teljesítmény, nem "papírforma"), így ez sem lehet szűk keresztmetszet. Megpróbáltam növelni a vCPU-k számát 2-ről 4-re a KVM-ben, illetve a memóriát 512MB-ról 2GB-ra, de ezek egyáltalán nem befolyásolták a mért átviteli sebességet.


*** PPPoE iperf teszteredmények (három, 10mp-es mérés átlaga) ***

SZERVER:

Dell Latitude E5440 (i5-4310U @ 2.00GHz / 4 GB RAM)
FreeBSD 11.2p4
mpd 5.8_7

KLIENS:

KVM 2 vCPU-val (AMD Sempron(tm) 3850 @ 1.30GHz / 512 MB RAM)
pfSense 2.4.4-RELEASE

TCP: 352 Mbps
UDP (1Gbps BW limittel): 140 Mbps

------------------------------------------------------------
Server listening on TCP port 5001
Binding to local address 10.1.1.1
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[ 4] local 10.1.1.1 port 5001 connected with 10.1.1.2 port 45521
[ ID] Interval Transfer Bandwidth
[ 4] 0.0- 1.0 sec 44.4 MBytes 373 Mbits/sec
[ 4] 1.0- 2.0 sec 42.4 MBytes 356 Mbits/sec
[ 4] 2.0- 3.0 sec 41.1 MBytes 345 Mbits/sec
[ 4] 3.0- 4.0 sec 43.1 MBytes 361 Mbits/sec
[ 4] 4.0- 5.0 sec 41.6 MBytes 349 Mbits/sec
[ 4] 5.0- 6.0 sec 40.1 MBytes 336 Mbits/sec
[ 4] 6.0- 7.0 sec 40.8 MBytes 343 Mbits/sec
[ 4] 7.0- 8.0 sec 43.0 MBytes 361 Mbits/sec
[ 4] 8.0- 9.0 sec 40.7 MBytes 341 Mbits/sec
[ 4] 9.0-10.0 sec 40.3 MBytes 338 Mbits/sec
[ 4] 0.0-10.0 sec 418 MBytes 350 Mbits/sec
[ 5] local 10.1.1.1 port 5001 connected with 10.1.1.2 port 32795
[ 5] 0.0- 1.0 sec 44.7 MBytes 375 Mbits/sec
[ 5] 1.0- 2.0 sec 41.1 MBytes 345 Mbits/sec
[ 5] 2.0- 3.0 sec 41.7 MBytes 350 Mbits/sec
[ 5] 3.0- 4.0 sec 41.3 MBytes 347 Mbits/sec
[ 5] 4.0- 5.0 sec 41.7 MBytes 350 Mbits/sec
[ 5] 5.0- 6.0 sec 42.4 MBytes 356 Mbits/sec
[ 5] 6.0- 7.0 sec 41.5 MBytes 348 Mbits/sec
[ 5] 7.0- 8.0 sec 40.9 MBytes 343 Mbits/sec
[ 5] 8.0- 9.0 sec 42.6 MBytes 358 Mbits/sec
[ 5] 9.0-10.0 sec 41.7 MBytes 350 Mbits/sec
[ 5] 0.0-10.0 sec 420 MBytes 352 Mbits/sec
[ 4] local 10.1.1.1 port 5001 connected with 10.1.1.2 port 52984
[ 4] 0.0- 1.0 sec 41.5 MBytes 348 Mbits/sec
[ 4] 1.0- 2.0 sec 42.1 MBytes 353 Mbits/sec
[ 4] 2.0- 3.0 sec 41.2 MBytes 346 Mbits/sec
[ 4] 3.0- 4.0 sec 39.9 MBytes 335 Mbits/sec
[ 4] 4.0- 5.0 sec 41.0 MBytes 344 Mbits/sec
[ 4] 5.0- 6.0 sec 41.2 MBytes 346 Mbits/sec
[ 4] 6.0- 7.0 sec 40.6 MBytes 340 Mbits/sec
[ 4] 7.0- 8.0 sec 45.5 MBytes 382 Mbits/sec
[ 4] 8.0- 9.0 sec 45.4 MBytes 381 Mbits/sec
[ 4] 9.0-10.0 sec 42.0 MBytes 352 Mbits/sec
[ 4] 0.0-10.0 sec 421 MBytes 353 Mbits/sec

------------------------------------------------------------
Server listening on UDP port 5001
Binding to local address 10.1.1.1
Receiving 1470 byte datagrams
UDP buffer size: 41.1 KByte (default)
------------------------------------------------------------
[ 3] local 10.1.1.1 port 5001 connected with 10.1.1.2 port 36160
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 3] 0.0- 1.0 sec 16.7 MBytes 140 Mbits/sec 0.079 ms 0/11899 (0%)
[ 3] 1.0- 2.0 sec 16.4 MBytes 137 Mbits/sec 0.083 ms 0/11675 (0%)
[ 3] 2.0- 3.0 sec 16.6 MBytes 139 Mbits/sec 0.077 ms 0/11837 (0%)
[ 3] 3.0- 4.0 sec 17.3 MBytes 145 Mbits/sec 0.079 ms 0/12361 (0%)
[ 3] 4.0- 5.0 sec 16.8 MBytes 141 Mbits/sec 0.077 ms 0/12002 (0%)
[ 3] 5.0- 6.0 sec 16.7 MBytes 140 Mbits/sec 0.077 ms 0/11943 (0%)
[ 3] 6.0- 7.0 sec 16.5 MBytes 139 Mbits/sec 0.078 ms 0/11796 (0%)
[ 3] 7.0- 8.0 sec 16.7 MBytes 141 Mbits/sec 0.077 ms 0/11948 (0%)
[ 3] 8.0- 9.0 sec 16.7 MBytes 140 Mbits/sec 0.081 ms 0/11918 (0%)
[ 3] 9.0-10.0 sec 16.3 MBytes 137 Mbits/sec 0.078 ms 0/11614 (0%)
[ 3] 0.0-10.0 sec 167 MBytes 140 Mbits/sec 0.072 ms 0/118996 (0%)
[ 4] local 10.1.1.1 port 5001 connected with 10.1.1.2 port 10805
[ 4] 0.0- 1.0 sec 17.0 MBytes 142 Mbits/sec 0.080 ms 0/12095 (0%)
[ 4] 1.0- 2.0 sec 16.7 MBytes 140 Mbits/sec 0.076 ms 0/11891 (0%)
[ 4] 2.0- 3.0 sec 16.6 MBytes 140 Mbits/sec 0.078 ms 0/11864 (0%)
[ 4] 3.0- 4.0 sec 17.1 MBytes 143 Mbits/sec 0.081 ms 0/12182 (0%)
[ 4] 4.0- 5.0 sec 16.3 MBytes 136 Mbits/sec 0.074 ms 0/11606 (0%)
[ 4] 5.0- 6.0 sec 16.4 MBytes 137 Mbits/sec 0.076 ms 0/11687 (0%)
[ 4] 6.0- 7.0 sec 17.6 MBytes 147 Mbits/sec 0.077 ms 0/12536 (0%)
[ 4] 7.0- 8.0 sec 18.4 MBytes 154 Mbits/sec 0.080 ms 0/13093 (0%)
[ 4] 8.0- 9.0 sec 17.1 MBytes 144 Mbits/sec 0.081 ms 0/12215 (0%)
[ 4] 9.0-10.0 sec 16.6 MBytes 140 Mbits/sec 0.077 ms 0/11874 (0%)
[ 4] 0.0-10.0 sec 170 MBytes 142 Mbits/sec 0.088 ms 0/121125 (0%)
[ 3] local 10.1.1.1 port 5001 connected with 10.1.1.2 port 53052
[ 3] 0.0- 1.0 sec 16.9 MBytes 142 Mbits/sec 0.082 ms 0/12045 (0%)
[ 3] 1.0- 2.0 sec 16.3 MBytes 137 Mbits/sec 0.077 ms 0/11624 (0%)
[ 3] 2.0- 3.0 sec 16.6 MBytes 139 Mbits/sec 0.080 ms 0/11838 (0%)
[ 3] 3.0- 4.0 sec 17.0 MBytes 143 Mbits/sec 0.074 ms 0/12133 (0%)
[ 3] 4.0- 5.0 sec 16.4 MBytes 138 Mbits/sec 0.080 ms 0/11723 (0%)
[ 3] 5.0- 6.0 sec 16.9 MBytes 142 Mbits/sec 0.069 ms 0/12039 (0%)
[ 3] 6.0- 7.0 sec 16.5 MBytes 138 Mbits/sec 0.080 ms 0/11759 (0%)
[ 3] 7.0- 8.0 sec 17.0 MBytes 142 Mbits/sec 0.075 ms 0/12103 (0%)
[ 3] 8.0- 9.0 sec 17.0 MBytes 143 Mbits/sec 0.079 ms 0/12141 (0%)
[ 3] 9.0-10.0 sec 16.9 MBytes 142 Mbits/sec 0.075 ms 0/12041 (0%)
[ 3] 0.0-10.0 sec 167 MBytes 140 Mbits/sec 0.075 ms 0/119446 (0%)

Ha megosztanál 1 leírást, hogyan építettél pppoe szervert szimuláció gyanánt, nagyon hálás volnék érte, mert én is így szerettem volna lemérni az eredményt.
--

Nincs step-by-step leírásom, de megpróbálok rögtönözni valamit. Igazából annyit csináltam, hogy egy USB-s vinyóra felhúztam egy alap FreeBSD 11.2-est, majd utána egy "pkg install mpd5" paranccsal, csomagból telepítettem az mpd-t. A konfigot két helyről lestem ki, az egyik egy régi, de jól összeszedett guide volt, viszont ez túl összetettnek bizonyult egy szimpla sebességteszthez, így végül nem használtam fel. Helyette fogtam az mpd.conf.sample fájlból a "pppoe_server" részt és egy az egyben átemeltem az mpd.conf-ba. Lebontottam már a tesztkörnyezetet, de emlékeim szerint csak az interfész nevét (fxp0 helyett em0) és az IP-címeket ("set ipcp ranges 10.1.1.1 10.1.1.2") írtam át. Az mpd.secret fájlba felvettem egy usert ("usernev jelszo IP-cim" a szintaxis, szóközökkel elválasztva), ez így már elég volt ahhoz, hogy fel tudjon épülni a kapcsolat.

Ha az mpd.conf-ban a "set pppoe service..." sorban csillagot adsz meg névnek, akkor bármilyen service name megadásával lehet kapcsolódni (üres string is lehet).

Itt jegyezném meg, hogy az mpd (és a pppd is) érzékeny az interfészek neveire, ha pontot tartalmaz (pl. VLAN interfészeknél), akkor mindenféle érthetetlen hibaüzenetek generálódnak és a kapcsolat nem tud felépülni. A megoldás értelemszerűen annyi, hogy át kell nevezni az interfészt úgy, hogy ne legyen benne pont, ehhez a FreeBSD Handbook VLAN-okról szóló fejezetéből merítetem ihletet (az oldal legalján lévő példakonfigot másoltam le).

Még egy plusz infó a saját tesztemhez: a szerver oldaláról egy Intel I2xx/825xx, a kliens oldaláról egy Realtek RTL8168g (virtio-n keresztül kiadva a VM-nek) hálózati adapterrel teszteltem, hátha driverfüggő a probléma.

Kössz, igazából nekem elég lett volna a mpd.conf is :-) a többit már talán hozzá tudnám reszelni. De ha csak vetted az alap sample mpd.conf-ot, és azt a pár sort hozzákalapáptad, azt még tán én is meg tudom oldani.

A realtek-et mindenki szídja (bsd-sek is), szóval lehet h. nornális intel (igb/em) kártyával jobb eredményt értél volna el, és az is bizonyítaná h. a realtek-et gigabit környékén már felejteni kell.
--

"subscribe" :)

+1

+1

+1

Hat az en tapasztalatom szerint a pfSense egy kotvany a ROS-hoz kepest meg ha az utobbi sem egy hiabtlan elmeny.