pfSense nem AES NI vason -> ki hova migrál?

Fórumok

Ugyan még nincsen közel az a pont, amikor ezt meg kell lépni, de az ember igyekszik előre tervezni: 2.5-ös pfsense-től már probléma lesz a nem AES NI képes vasakkal.
Ott ahol a vas csere nem jön szóba a kifutásig, ki mire fog migrálni? opnSense-be nem másztam bele, mert sokan azt állították bugos, és nagyon jól elvoltunk eddig pfSense-el, így alulmotivált voltam a tesztelésére, most azonban itt az idő alternatívákat keresni (pl azon szerencsétlen SoHo ügyfelek számára akik a pcengines ALIX széria után az első generációs APU-ra [APU1x] alapoztak vélten hosszabb távon, csak mint kiderült már középtávon sem pfSense alapokon - mivel az APU1-esekben nincs AES NI).

pfSense-et kiváltó viszonylag friss migrációs tapasztalatokkal ne kíméljetek.

Hozzászólások

Nem eszik olyan forrón a kását. Ha ez a most felkapott CPU sebezhetőség a jövőben megoldást nyer, lesz más lehetőség a gépeken folyó műveletek távoli "kontrolljára". (Szuper-titkosítva v. kevésbé.)

A szoftver (Sense) pedig "fejlődik", megoldja majd, amit a hardver esetleg "hibásan" tud. Mindig lesznek megoldásra váró CVE-k. - Jók ezek a Sense-ek. (A routereknél az "abszolut nyílt" sztem. alapból biztonsági kockázat.)

Az újabb, már csak UEFI-hardvereknél a CPU-n felül, még lehet majd az UEFI-firmware miatt is aggódni, sztem. bőségesen vannak csontvázak betárolva abban a "szekrényben".

azt irjak hogy az aesni a titkositashoz kell mert sokan hasznalnak vpn meg mindent. namost akkor ha csak "sima" tuzfalnak hasznaljak, es nincs vpn meg hasonlo akkor miert is kell egy olyan ficsor a cpuban amit aztan nem hasznalnak ki? meg egyatalan miert baj az nekik ha a cpu "izombol" probalja megoldani a titkositast? ahol csak par kbajt megy titkositva edes mind1 hogy cpu mennyit fogyaszt. mellekessen teszteltem a kis kinai j9000 cpus cuccon openvpn-t (abban sincs aesni) es megis tudott >10Mbit felett.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Amikről beszélgetünk azok masnival átkötött, komplett, szines-szagos megoldások, az openbsd meg egy nyers oprendszer. Szóval köszi Emese.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

igazad van. az OpenBSD nem egy ilyen "összekattingatom" megoldás, ellenben használható ugyanarra a célra, ha rászánja az időt az ember.
a pcengines cuccok is teljesen támogatottak, úgyhogy szerintem van ugyanolyan jó alternatíva, mint bármelyik itt említett színes-szagos web interface.

Persze, csak úgy sejtem hogy nem otthoni, hobbi célról van szó (elég elvetemült aki otthonra pfsense-t telepít), magyarul valamilyen gazdálkodó szervezetet szolgál ki a kollega a cuccal. Ott meg nemigen szeretik a kreatív házi mutatványokat (még akkor is, ha azok ugyanolyan jók vagy akár még jobbak is).
Ezeknek a termékeknek van neve, supportja, doksija, van mibe kapaszkodni akkor is ha a kollega felmond vagy elüti a busz.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

részben egyetértek veled. de szerinted mennyire életszerű az egy magyar kkv-nál, ahol egy tákolt (sorry op) rendszer van, hogy fizetős support-ot használnak? dokumentációt pedig lehet írni az általad "készített" rendszerről is. mert attól, hogy egy honlapon elérhető valami, még nem biztos, hogy a következő kolléga tudni fogja használni, vagy akár újraépíteni, egy esetleges hardverhiba esetén backup config nélkül. (főleg,ahogy elnézem a mostani frissdiplomás mérnökinfósokat, akik a google-t se tudják használni és 2 perc után feladnak mindent, tisztelet a kivételnek persze)