OPNsense 18.1.4

FreeBSD

Megjelent a pfSense-ből forkolódott, nyílt forrású, FreeBSD-alapú tűzfal és routing platform, az OPNsense (HUP teszt) 18.1.4-es kiadása. Részletek a bejelentésben.

( elod v | 2018. 03. 10., szo – 20:09 )

Van mintha egy teszt rendszered. Hogy muzsikál?

Jaja. Van egy kifejezetten tesztelésre beállított virtuális gépem, amin folyamatosan upgrade-elem az OPNsense-t. Public IP, NAT, DHCP, VPN van rajta egy játszós hálózathoz. Előtte pfSense volt itt. Egy hónapja cseréltem le OPNsense-re ezt is:

https://flic.kr/p/25716Li

A terv az jelenleg, hogy fokozatosan a többi helyen is lecserélem a pfSense-t.

--
trey @ gépház

Használattal kapcsolatos nem sok. Az OPNsense menüje újabb és szebb, a telepítés gyakorlatilag ugyanaz. Az OPNsense upgrade-ek eddig mindig szépen sikerültek távolról.

Nem mellesleg az OPNsense beemeli a HardenedBSD által fejlesztett mitigációs technikákat és egyéb biztonsági megoldásokat:

https://twitter.com/lattera/status/971564369111867392

Shawn Webb, a HardenedBSD társalapítója az OPNsense core team tagja.

A licencéből fakadóan számomra az OPNsense-nek van jövője.

--
trey @ gépház

A pfSense Apache 2 licencű, az OPNsense pedig FreeBSD/Simplified BSD licencű. Ez a két licenc az én tudásszintemen azonos, és a wikipédia által kiemelt fő jellemzőik is azonosak, akkor miért jelent előnyt a licenc az OPNsense számára?

Én is nagyon szeretném tudni, hogy minek van inkább jövője, mivel a következő hetekben el kell döntsem melyiket telepítem a tűzfalaimra, és jelentős érvem nincs egyik mellett sem.

Amit én látok:
A pfsense közösségi bázisa jóval nagyobbnak tűnik, és nekem úgy tűnik, jobban fejlesztik, az opnsense pedig modernebb kinézetű (de ez csak dizájn) és bátrabban építenek bele újabb technológiákat. Ezeken kívül nem látom a nagy előnyöket/hátrányokat.

Eddig csak pfsense-el dolgoztam, de nagyon keveset. Ami ott biztos megy és kell nekem: haproxy, letsencrypt integráció, HA mód (két router között tükrözi a konfigot, teljes fail overt nyújtva), openvpn - out-of-the-box csomagok letöltése/felhasználó. Még részletesen nem elemeztem ki, de úgy nézem ezeket az opnsense is támogatja.

Én idáig nagyon egyszerű teszteket csináltam:

opnsense feltelepít, közvetlen a kábelmodemem mögé feldugott virtuális gépre, mögé meg egy ubuntu vm.
Meg ugyanez pfsense-el.

Tesztfeladatok:
#1. engedni, hogy a wan interfész felől a "rendes" otthoni hálózatomról is elérjem az amdin felületet.
#2. a mögötte lévő bantu szépen muzsikáljon natívan ipv6-on.

Eredmények:
- opnsense-el próbálkoztam először:
- wan-felőli admin nyitás. nem működött, hiába engedélyeztem bármit. hiába vettem fel a szabályt, egyszerűen, mintha figyelmen kívül hagyta volna, vagy valami erősebb rejtett szabállyal override-olta volna.
- ubuntu nem kapott ipv6-os címet, csak ipv4-est.
- ha kézzel felhúztam egy ipv6-os címet az ubuntura, abból az alhálózatból, ami a lan interfésze felőli publikus ipv6 tartomány volt, amit dhcp-n kapott, akkor tudott működni az ubuntu is ipv6-on. Ezen túl nem vizsgáltam a történetet, hogy a https://test-ipv6.com/ 10/10-et adott vissza némi kézimunkás ubuntu setup után.

Itt, ezen felkúrtam magam, és hetekig nem is foglalkoztam a projekttel.

- pfsense: with flying colors, minden esetben:
- Admin access ip-kre/adott subnetre wan port felől, ahogy a nagykönyvben meg van írva.
- ubuntu magától felhúzza a publikus ipv6-os címet, mindenféle kézimunka nélkül
- beengedtem egy adott külső pubip-t (ec2 instance) ipv6-on a bantum felé 22-es porton. -> be tudott jönni.

Végeredmény: valószínűleg a pfsense-t megtartom, meg belenézek rajta konfigokba. De hacsak nem történik addig valami más, a végleges otthoni routerem egy freebsd vm lesz, "kézzel írott" konfigokkal. Esetleg a konfig valami automatizmussal (ansible/puppet) beletolva és scm-ben (git) tárolva.