Tee-se-itse: Rautapalomuurit (pfSense, Sophos UTM..) (Mitä käytätte ja miksi juuri se vaihtoehto?)

Kuinka vanhasta versioista voi Pfsensen päivittää suoraan uusimpaan? Voiko esim. 4.0 versiosta päivittää 5.2 versioon vai onko liian iso harppaus ja tarvitsee vallan uudelleen asennuksen johon pudottaa konfiksen? Ihan mielenkiinnosta kyselee hän.
 
Uusi huippualusta kotitekoiselle Sophos XG tai PfSense-muurille lähestyy julkaisuaan. Fitlet 3:n datalehti löytyy täältä:

Laitteessa näkyy olevan parhaimmillaan Intel® Atom x6425E -prosessori, joka on teholtaan noin 2x Fitlet 2:n J3455-prosessoriin verrattuna.

Tähän saa myös kunnollisen pitkän PCI Express M.2-kiintolevyn toisin kuin Fitlet 2:een.
 
Viimeksi muokattu:
Hohhoijaa yritin päivittää SG-1100 viimeisimpään Pfsense versioon 21.05.2, purkki korruptoitui ja meni boottilooppiin. Taitaa olla toinen tai kolmas firmware päivitys mikä brikkas ton
 
Viimeksi muokattu:
Hohhoijaa yritin päivittää SG-1100 viimeisimpään Pfsense versioon 21.05.2, purkki korruptoitui ja meni boottilooppiin. Taitaa olla toinen tai kolmas firmware päivitys mikä brikkas ton
Ei kyllä kuulosta hyvältä. Onko tuossa UFS vai ZFS?
 
Eipä ollut backupeja configsesta. Sain Netgaten tuesta uusimman firmiksen ja USB recoveryllä flashattua sen, sitten perusconfigset komentoriviltä sisään ja takas ajoon. Eipä tuossa mitään ihmeellisiä ollut, muutama staattinen dhcp iot vehkeille ja QoS säätöjä Teamsille.

EDIT. UFS levyjärjestelmä tuossa kai on.
 
Hyvä vinkki, otinkin backupin vielä yhteen paikkaan jemmaan konfiguraatiosta. Tosin Opnsense ajossa. Teams QoS kuulostaa myös fiksulta, täytynee tonkia tuota aihetta. Kiitos vinkistä.
 
Teams QoS on näköjään haasteena, että Teams käyttää defaulttina random portteja ja halutessaan Teams admin voi määrittää tietyt source port ranget. Defaulttina suositellaan määritettäväksi clientille seuraavia:
UDP 50,000–50,019 = Audio, suositus DSCP 46
UDP 50,020–50,039 = Video, suositus DSCP 34
UDP 50,040–50,059 = Ruudun jako, suositus DSCP 18

Ja kohdeporttina on taas mikä tahansa high portti 1,024-65,535 UDP
Paitsi jos nämä on blokattu niin destination portit vaihtuu ilmeisesti relay palvelimen portteihin UDP 3478-3481 ja jos tuokin vielä failais niin vissiin vaihtaa sitten vielä https (ja ääni on totaalisen kuraa)

Käsittääkseni oma organisaatio on ottanut juurin noi ekana mainitut port ranget käyttöön. Eli pfSenseen varmaan wan interfaceen QoS scheduleri päälle (esim PRIQ?) ja sitten floating rulella outbound liikenteelle merkkaus johonkin queue:hen?
 
Teams QoS on näköjään haasteena, että Teams käyttää defaulttina random portteja ja halutessaan Teams admin voi määrittää tietyt source port ranget. Defaulttina suositellaan määritettäväksi clientille seuraavia:
UDP 50,000–50,019 = Audio, suositus DSCP 46
UDP 50,020–50,039 = Video, suositus DSCP 34
UDP 50,040–50,059 = Ruudun jako, suositus DSCP 18

Ja kohdeporttina on taas mikä tahansa high portti 1,024-65,535 UDP
Paitsi jos nämä on blokattu niin destination portit vaihtuu ilmeisesti relay palvelimen portteihin UDP 3478-3481 ja jos tuokin vielä failais niin vissiin vaihtaa sitten vielä https (ja ääni on totaalisen kuraa)

Käsittääkseni oma organisaatio on ottanut juurin noi ekana mainitut port ranget käyttöön. Eli pfSenseen varmaan wan interfaceen QoS scheduleri päälle (esim PRIQ?) ja sitten floating rulella outbound liikenteelle merkkaus johonkin queue:hen?
Mitä etua tuo "Teams QoS" tuo esim fq_codeliin verrattuna?
 
Mitä etua tuo "Teams QoS" tuo esim fq_codeliin verrattuna?

No jaa-a

Perinteinen QoS confataan läjä Queue jonoja interfaceen ja määritellään säännöillä mitkä paketit menevät mihinkäkin Queue:hen ja miten pääsevät eteenpäin jonon prioriteetin perusteella. Ja jos mitään jonoa ei pääse syntymään niin silloin QoS ei myöskään vaikuta mihinkään.

fq_codel, jos ymmärsin oikein, tekee jokaisesta sessiosta oman Queue ja alkaa pudottaa niistä paketteja, jos ne makaa liian kauan queuessa ja pitää latenssia sitä kautta kurissa.

Kaippa tuota pitää kokeilla. 100/10 yhteydellä ei kyllä yleensä ole ongelmia äänen kanssa, mutta joskus kun muut perheet jäsenet katsoo youtubea tms saattaa ääni vähän pätkiä.
 
Itsellä tarkoitus asentaa kotiin 10Gb runkoverkko ja tämän seurauksena tilauksessa 10Gb kytkimiä (joiden saatavuus huono/olematon) ja samalla muuri pitää päivittää, koska muuri toimii samalla sisäverkon reitittimenä. Koko verkko on nyt Ubiquitia mutta koska Ubin muuritkin kiven alla niin alkanut katsomaan aidan yli Netgaten ja pFsensen suuntaan. Netgatella näyttäisi 6100 malli tarjoavan 2x10Gb SFP (7100 malli lopetettu).

Menisinkö pahasti metsään tuolla Netgate/pFsense ratkaisulla? Ajoin pfsenseä ennen siirtymistä Ubiquitin. Jossain päivityksessä sain pfsensen täysin solmuun jonka jälkeen onkin mennyt nyt 3 vuotta ubiquitilla.
 
Itsellä tarkoitus asentaa kotiin 10Gb runkoverkko ja tämän seurauksena tilauksessa 10Gb kytkimiä (joiden saatavuus huono/olematon) ja samalla muuri pitää päivittää, koska muuri toimii samalla sisäverkon reitittimenä. Koko verkko on nyt Ubiquitia mutta koska Ubin muuritkin kiven alla niin alkanut katsomaan aidan yli Netgaten ja pFsensen suuntaan. Netgatella näyttäisi 6100 malli tarjoavan 2x10Gb SFP (7100 malli lopetettu).

Menisinkö pahasti metsään tuolla Netgate/pFsense ratkaisulla? Ajoin pfsenseä ennen siirtymistä Ubiquitin. Jossain päivityksessä sain pfsensen täysin solmuun jonka jälkeen onkin mennyt nyt 3 vuotta ubiquitilla.
Itselläni vähän sama homma edessä ja sopivaa pfsense/opnsense rautaa kattellut josko saisi pientä ja söpöä mikä menisi kivasti räkkiin. Nyt käytössä on Ubiquitin dream machine pro ja siitä menee 10Gb linkki qnapin kytkimeen jossa 10Gb laitteet on kiinni. UDM:ssä ei mitään vikaa ole, mutta olisi tarvetta useammalle WAN yhteydelle, eikä UDM tue niitä... Olen katsellut Aliexpressistä Qotomin laitteita, niissä ei 10Gb:tä ole, mutta saisi vaikka 8x1Gb verran porttaja pienessä koossa ja olen myös katsellut tuota SG-6100 laitetta joka olisi kyllä sopiva ja melkoisen kykenevä laitekkin, mutta hintaa kyllä on ja siihen en usko että menee opnsense kiinni lainkaan. En ole toki tutkinut asiaa.
SG-3100 malli siirtyi juuri EOL tilaan, joten uskoisin, että SG-2100 ja SG-6100 väliin tulisi jotain uutta vielä jonkin ajan sisällä... Mutta et mene kyllä yhtään metsään jos tuon SG-6100 mallin ostat, mielestäni se on kyllä hyvä ja nopea laite.
 
Argh, tuo dual wan on itselle ehdoton ja jos ubin dream machine pro se versio ei myös tue tuota niin sitten suosiolla pfsenseen paluu.
 
Argh, tuo dual wan on itselle ehdoton ja jos ubin dream machine pro se versio ei myös tue tuota niin sitten suosiolla pfsenseen paluu.
Joo, mielestäni siinäkään ei toimi kuin fail over toisessa WAN portissa... Jotain komentorivi virityksiä on tainnut joku tehdä, mutta se taitaa olla aina purkkaviritys...
 
Uusi huippualusta kotitekoiselle Sophos XG tai PfSense-muurille lähestyy julkaisuaan. Fitlet 3:n datalehti löytyy täältä:

Laitteessa näkyy olevan parhaimmillaan Intel® Atom x6425E -prosessori, joka on teholtaan noin 2x Fitlet 2:n J3455-prosessoriin verrattuna.

Tähän saa myös kunnollisen pitkän PCI Express M.2-kiintolevyn toisin kuin Fitlet 2:een.
Itsellä Fitlet2 ja erittäin tyytyväinen. Vähän kallis, mutta kerran sen kirpaisi silloin kun sen maksoin. Tuo vaikuttaisi kovalta tuo Fitlet3. Veikkaan, että hinnat ovat vielä kovemmat nyt ja saatavuus tulee olemaan olematon. Ehkä sitten Fitlet4 ECC-tuki ja 10G-tuki.
 
Itsellä tarkoitus asentaa kotiin 10Gb runkoverkko ja tämän seurauksena tilauksessa 10Gb kytkimiä (joiden saatavuus huono/olematon) ja samalla muuri pitää päivittää, koska muuri toimii samalla sisäverkon reitittimenä. Koko verkko on nyt Ubiquitia mutta koska Ubin muuritkin kiven alla niin alkanut katsomaan aidan yli Netgaten ja pFsensen suuntaan. Netgatella näyttäisi 6100 malli tarjoavan 2x10Gb SFP (7100 malli lopetettu).

Menisinkö pahasti metsään tuolla Netgate/pFsense ratkaisulla? Ajoin pfsenseä ennen siirtymistä Ubiquitin. Jossain päivityksessä sain pfsensen täysin solmuun jonka jälkeen onkin mennyt nyt 3 vuotta ubiquitilla.
Tarvitseeko välttämättä reitittää 10g verkkojen välillä? Jos jotain NASia tms käytössä niin laittaisin vaan samaan verkkon kuin laitteet joilta käytetään.
 
Tarvitseeko välttämättä reitittää 10g verkkojen välillä? Jos jotain NASia tms käytössä niin laittaisin vaan samaan verkkon kuin laitteet joilta käytetään.

Tarvitsee koska laitteita noin 10 eri vlanissa. Gigaiset linkit hyvin käytetty tällä hetkellä. Tai 10g verkkojen välillä ei tarvitse välttämättä, mutta tuota liikennettä noissa 10 verkossa sen verran paljon, että gigan linkit on jo pullonkaula. Runkoverkko siksi muuttumassa 2x10Gb, että saa hetken hengähtää. Fyysiset serverit tulee myös 2X10Gb linkeillä runkoon.
 
Tarvitsee koska laitteita noin 10 eri vlanissa. Gigaiset linkit hyvin käytetty tällä hetkellä. Tai 10g verkkojen välillä ei tarvitse välttämättä, mutta tuota liikennettä noissa 10 verkossa sen verran paljon, että gigan linkit on jo pullonkaula. Runkoverkko siksi muuttumassa 2x10Gb, että saa hetken hengähtää. Fyysiset serverit tulee myös 2X10Gb linkeillä runkoon.
Äkkiä tulee mieleen että eikö jokaiselle tiettyyn verkkoon palveluita tarjovalle serverille kannata luoda ko. verkkoon oma interface? Jos tämä ei ole mahdollista tai muuten halutaan 10Gb reititystä niin ainakin RouterOS 7:ssa on mahdollista reitittää vlanien välillä nimellisnopeudella. Kait noita vastaavia optimointeja on muillakin verkkolaitevalmistajilla?
 
Itselläni vähän sama homma edessä ja sopivaa pfsense/opnsense rautaa kattellut josko saisi pientä ja söpöä mikä menisi kivasti räkkiin. Nyt käytössä on Ubiquitin dream machine pro ja siitä menee 10Gb linkki qnapin kytkimeen jossa 10Gb laitteet on kiinni. UDM:ssä ei mitään vikaa ole, mutta olisi tarvetta useammalle WAN yhteydelle, eikä UDM tue niitä... Olen katsellut Aliexpressistä Qotomin laitteita, niissä ei 10Gb:tä ole, mutta saisi vaikka 8x1Gb verran porttaja pienessä koossa ja olen myös katsellut tuota SG-6100 laitetta joka olisi kyllä sopiva ja melkoisen kykenevä laitekkin, mutta hintaa kyllä on ja siihen en usko että menee opnsense kiinni lainkaan. En ole toki tutkinut asiaa.
SG-3100 malli siirtyi juuri EOL tilaan, joten uskoisin, että SG-2100 ja SG-6100 väliin tulisi jotain uutta vielä jonkin ajan sisällä... Mutta et mene kyllä yhtään metsään jos tuon SG-6100 mallin ostat, mielestäni se on kyllä hyvä ja nopea laite.

Eikös UDMP:ssä ole gigan backplane? Jotain juoruja olen kuullut että hardware revikkojen myötä on saattanut parantua, mutta käsittääkseni rehellistä 10 gigan linkkiä UDMP ei jaksaisi vääntää.
 
Tarvitsee koska laitteita noin 10 eri vlanissa. Gigaiset linkit hyvin käytetty tällä hetkellä. Tai 10g verkkojen välillä ei tarvitse välttämättä, mutta tuota liikennettä noissa 10 verkossa sen verran paljon, että gigan linkit on jo pullonkaula. Runkoverkko siksi muuttumassa 2x10Gb, että saa hetken hengähtää. Fyysiset serverit tulee myös 2X10Gb linkeillä runkoon.

Itse ainakin olen tyytyväinen pfsense+unifi yhdistemään, Unifin palomuurista en tykkää pätkääkään.

Onko käyttämässäsi verkossa yksittäisen serverin/clientin tarve nousemassa niin korkealle ettei gigan linkki riitä, vai onko usean laitteen yhtäaikainen liikenne nousemassa yli gigaan ja sitämyöten verkko nousemassa pullonkaulaksi? Kiinnostaa vaan että pystyisitkö ratkaisemaan verkon hidasteluja esim. trunkkaamalla unifin kytkimet keskenään jolloin toki yksittäinen yhteys on edelleen rajattu gigaan, mutta useampi yhtäaikainen yhteys jaoteltaisiin trunkin kapasiteetin mukaan.
 
Eikös UDMP:ssä ole gigan backplane? Jotain juoruja olen kuullut että hardware revikkojen myötä on saattanut parantua, mutta käsittääkseni rehellistä 10 gigan linkkiä UDMP ei jaksaisi vääntää.

Siinä on 10Ggigan WAN ja LAN portit. En tiedä miten jaksaisi reitittää 10 gigaa kun ei ole kuin 1gb yhteys nettiin. Toki LAN:ssa 10 gigaa toimii hyvin. Ja suurin osa liikenteestä ei edes UDMP:lle asti tule kun menee vaan kytkimen portista toiseen.
Itselläni on viime vuoden kesällä ostettu tuo UDMP, eikä siinä ole mitään ongelmia ollut. Protect ja Network on pyörinyt alusta saakka...
 
v20.7:ssä on nyt Suricata 5 IDS/IPS vakiona(?). Jos nyt laittaisi tuon 21.1 development-branchin kolmanneksi rinnakkaiseksi palomuuriksi ihan oikeaan käyttöön.
Tässä vierähtikin aika pitkä tovi, mutta nyt tuli asennelluksi Proxmox 7.0 ja siihen OPNsense 21.7.4-amd64, mikä juuri päivittyi .5:een.

Tämä purkki käyttää samaa verkkoinfraa (kytkimet, wifi-AP:t, modeemit), joten se on internet-yhteytenä nyt melkein oman pfSensen veroinen, kun lisäsin vielä dual-WANin. Tuo toimii hieman heikommin kuin pfSense eli load-balansointi varsinkin UL-suuntaan ei ole niin suvereenia kuin pfSensessä. Kunhan vielä koku VPN on aseteltu käyttöön, niin pfSense voi kilahtaa, eikä paljoa haittaa.
 
Itse ainakin olen tyytyväinen pfsense+unifi yhdistemään, Unifin palomuurista en tykkää pätkääkään.

Onko käyttämässäsi verkossa yksittäisen serverin/clientin tarve nousemassa niin korkealle ettei gigan linkki riitä, vai onko usean laitteen yhtäaikainen liikenne nousemassa yli gigaan ja sitämyöten verkko nousemassa pullonkaulaksi? Kiinnostaa vaan että pystyisitkö ratkaisemaan verkon hidasteluja esim. trunkkaamalla unifin kytkimet keskenään jolloin toki yksittäinen yhteys on edelleen rajattu gigaan, mutta useampi yhtäaikainen yhteys jaoteltaisiin trunkin kapasiteetin mukaan.

Tuota pfsenseä olen alkanut tutkimaan nyt, pitää vaan löytää rautaa jossa 10Gb LAN puoli (mahdollisesti 2) ja sitten kaksi WAN porttia. Minulla on kahdennettu nettiyhteydet ja molemmat aktiivisesti käytössä.

Osa kytkimistä on jo kytketty kahdella linkillä ja seuraavaksi vedän kuituja kytkinten väliin odotellessa 10Gb kytkimiä.

Fyysisiin palvelinkoneisiin on tulossa 2x10Gb kuitukortit ja noissa pyörii virtuaalikoneita. Tarkoitus on pystyä siirtämään virtuaalipalvelimia koneelta toiselle tarvittaessa.

Eli yksittäisten laitteiden tietoliikenne määrä on paikoitellen isoa. Lisäksi backupit kulkevat eri palotiloihin yöaikaan. Myös verkossa olevien laitteiden määrä lähestyy uhkaavasti 100.
 
Mainostetaan nyt tässä jos sallittua on, jos ei niin saa poistaa. Eli vapautui käytöstä hienosti tee-se-itse palomuuriksi sopiva HP T730 Thinclient Intelin Pro 1000 PT verkkokortilla, jos kiinnostaa niin löytyy myydään osiosta Konepaketit ja valmistietokoneet -alta. Toimi itsellä vuoden päivät OPNsense reitittimenä vaillla minkäänlaisia ongelmia.
 
Jukra, nostaapa laitteen lämpöä tuo IPS:n käyttö WAN jalassa. Mitään se ei sieltä ole nostanut puoleen vuoteen esille mutta.. Lämpö CPU:lla on selkeästi noin 7-10 celsius astetta korkeammalla. Joten joten.. Taidanpa antaa sille pitkää joululomaa. Ei muuten, mutta muurikoneessa on kaksi tuuletinta ja ne pitävät inan enemmän ääntä ja keräävät selvästi enemmän pölyä laitteeseen sisälle, kun IPS:iä pitää ajossa.
 
Nonni, nyt sekin selvis. Kiitos @mikajh . Kokeilenpa vielä tuolla LAN puolella tätä. Lämpö pomppas kyllä het CPU osalta 39 -> 47.
 
OPNsensessä on testisääntö OPNsense-App-detect/test, jolla voi testata helposti, että http://pkg.opnsense.org/test/eicar.com.txt tuottaa blockin tai vähintään alertin, riippuen siitä miten IDS/IPS ja tuo sääntö on konffattu

Testasimpa huvikseni, tein lievästi mielenkiintoisen havainnon.

Kun konffaa wan+lan interfacet IDSää ja avaa tuon osoitteen IPv4:n kautta, tapahtuu se mitä voisi odottaakin: kaksi alertia, lanista läppärin lan-IP destinationina ja wanista vastaavasti reitittimen wan-ip.

Mutta IPv6:llä tulee alert ainoastaan wanista, läppärin IPv6 destinationilla.

Ärsyttävää.
 
Mutta IPv6:llä tulee alert ainoastaan wanista, läppärin IPv6 destinationilla.
Mutta siis IPv6 on pelkää WAN puolta, koska se on julkisia osoitteita. Eli ihan menee kuten pitäiskin, tokihan IPv4 NAT pakkorakojen takia parikymmentä vuotta on totuttu ei julkisesti reitittyviin osoitteisiin, jotka on vain lähiverkkoa. Kun eivät voi olla muuta.
 
Mutta siis IPv6 on pelkää WAN puolta, koska se on julkisia osoitteita. Eli ihan menee kuten pitäiskin, tokihan IPv4 NAT pakkorakojen takia parikymmentä vuotta on totuttu ei julkisesti reitittyviin osoitteisiin, jotka on vain lähiverkkoa. Kun eivät voi olla muuta.

Toki, mutta tämä on tuon IDS:n konffaukselle pyllystä kun pitää olla interfaceissa lan että saa alerteissa oikeat IPv4 lan-osoitteet ja wan että saa IPv6-liikenteenkin syynättyä. Ja sitten alertit tulevat tuplana. Deny-säännöille ei liene merkitystä.
 
Laitetaan nyt tänne jos joku joskus tarvitsee Applen laitteisiin.
Eli mulla on pfSensessä FreeRadius palvelin ja wifissä EAP-TLS eli sertifikaateilla autentikoidaan. Tuli hommattua Apple Watch Series 6 älykello niin tarpeena oli liittää tuo tuohon samaan langattomaan verkkoon. Tuo Apple Watch Series 6 tukee nyt uutena ominaisuutena 5GHz langatonta verkkoa.

Tuo olikin yllättävän helppo, koska mulla oli valmis Apple Configuration profiili eli sama mikä toimii Mac, iPhone, iPad jne. laitteissa.
IPhonessa tuo profiili on jo käytössä, mutta piti AirDropilla tiputtaa se uudestaan (Mac --> iPhone). Tuo sen takia, että profiilin pystyy asentamaan kelloon näin jälkeenpäin.
apple-watch-os5.png

Tuosta kuvasta piti valita Apple Watch niin se asentuu kelloon. Tuo kuva on vanhasta iOS versiosta, kun siitä puuttuu molempiin valinta.

No profiili ilmestyi kelloon ja EAP-TLS wifi toimii.
IMG_0162.PNG

Mulla on AP:ssa Mac filter käytössä niin iOS 14, iPadOS 14 ja watchOS 7 on tullut muutoksia tuohon.

Edit: Lisätietoa noista EAP tyypeistä
Laitetaan nyt tähän ketjuun kun tuli tuo Apple Watch laitettua reilu vuosi sitten. Eli pfSensessä Radius palvelin (EAP-TLS) eli sertifikaateilla autentikoidaan wifiin. Hommasin pari Apple HomePod Mini kaiutinta niin ne kanssa tukevat tuota samoin kuin Apple Watch. HomePod Minissä on sama SOC kuin Apple Watch SE ja Series 5 malleissa niin outoa olisi jos ei olisi toiminut. HomePod Mini tukee myös 5GHz wifi verkkoa eli se itsellä käytössä.

Valmiin radius/wifi profiilitiedoston asentaminen iPadin tai iPhonen kautta niin lähtee toimimaan.

FQlptVnXAHJThBzBfsqNmT1fDjnRRLSCChuUojxopUk.jpg


1638959629838.png
 
Viimeksi muokattu:
Olen nyt kahden vaiheilla ostanko Netgate SG-1100:n vai hankinko pfsenseä varten jonkin muun rautaratkaisun. Tarve olisi hoitaa palomuurin ja reitityksen lisäksi kuormantasaus 100/10M VDSL2-yhteyden ja 200M 4G -yhteyden välillä ja tähän tarpeeseen tuo SG-1100 riittäisi varmasti mainiosti. Jokin oma rautaratkaisu antaisi tietysti mahdollisuuden kokeilla muita palomuureja/reitittimiä ja suorituskyky saattaisi olla muutoinkin parempi. Mitä vaihtoehtoja teillä tulee mieleen, jos yrittäisi toteuttaa jonkin oman virityksen tässä samassa hintaluokassa? Lähtökohtaisesti laitteeseen pitäisi saada jokin 4-porttinen giganen ethernet -kortti eikä laitteen koko saisi olla juuri miniä tai pientä thin clientia suurempi. Löytyykö tällaista rautaa helposti edes SER-laatikoista vai onko vain järkevämpi ostaa tuo pikku Netgate?
 
Olen nyt kahden vaiheilla ostanko Netgate SG-1100:n vai hankinko pfsenseä varten jonkin muun rautaratkaisun. Tarve olisi hoitaa palomuurin ja reitityksen lisäksi kuormantasaus 100/10M VDSL2-yhteyden ja 200M 4G -yhteyden välillä ja tähän tarpeeseen tuo SG-1100 riittäisi varmasti mainiosti. Jokin oma rautaratkaisu antaisi tietysti mahdollisuuden kokeilla muita palomuureja/reitittimiä ja suorituskyky saattaisi olla muutoinkin parempi. Mitä vaihtoehtoja teillä tulee mieleen, jos yrittäisi toteuttaa jonkin oman virityksen tässä samassa hintaluokassa? Lähtökohtaisesti laitteeseen pitäisi saada jokin 4-porttinen giganen ethernet -kortti eikä laitteen koko saisi olla juuri miniä tai pientä thin clientia suurempi. Löytyykö tällaista rautaa helposti edes SER-laatikoista vai onko vain järkevämpi ostaa tuo pikku Netgate?
Katsoisin kotikäyttöön jotain tämäntyylistä purkkia: NRG Systems IPU Systeme und Zubehör ...ja pistäisin proxmoxin, siihen pfsensen ja esim ubuntua piholea varten + jos haluaa niin jotain muutakin säätöä, esim jos haluaa ajaa grafanaa tai home assistanttia samalla raudalla myös.

edit: enkä tasais kuormaa, vaan pistäisin vdsl:ään pingikriittisen liikenteen (pelit ym) ja 4g:hen kaiken kuormabloatin (http, https, altit, videostriimit)
 
Uusista osista hinta nousee helposti lähemmäs 300€. SER laitteista kannattaa tarkistaa sähkön kulutus. Vanha pöytäkone vie helposti 50-70w. 24/7 käytössä tuo on 70-150€ vuodessa.
Intel NUC on itsellä koska sähkön kulutus on alle 10w ja tehoa on ajaa pfSense virtuaalikoneessa. Lisäksi voi sitten isäntä linux koneessa ajella mitä haluaa. Pystytyksessä sitten menee helposti muutama viikkoloppu, ainaki minun taidoilla.
 
Uudeksi Proxmox + jokuSense -alustaksi tuli hommattua käytetty Lenovo ThinkCentre M920q. Pci-riseria vielä odottelen maailmalta, mutta ihan hyvältä toi vaikuttaa, idle-kulutus ilman vielä puuttuvaa 2 x sfp+ -korttia on alle 10 W . Budjetti menee tietty yli SG-1100:stä, mutta käyttömahdollisuudetkin ovat toista luokkaa.
 
Uudeksi Proxmox + jokuSense -alustaksi tuli hommattua käytetty Lenovo ThinkCentre M920q. Pci-riseria vielä odottelen maailmalta, mutta ihan hyvältä toi vaikuttaa, idle-kulutus ilman vielä puuttuvaa 2 x sfp+ -korttia on alle 10 W . Budjetti menee tietty yli SG-1100:stä, mutta käyttömahdollisuudetkin ovat toista luokkaa.
Minkä verkkokortin ostat tuohon?
 
Minkä verkkokortin ostat tuohon?
Se on vähän auki vielä. Tilasin nyt kokeeksi Solarflare S7122:sen ja Mellanox MCX354A:n (QSFP+ mutta adapterilla SFP+:ksi). Lisäksi jossain kätköissä pitäisi olla ainakin yksi Mellanox ConnectX-2 -kortti ja ties mikä HP. Täytyy kokeilla mikä noista pelaa luotettavasti ja pienimmällä sähkönkulutuksella.
 
Pariin SFF-koneeseen (esim. mökkilaneille keräämän useita 4g yhteyksiä yhteen jne) oon laitellu tämmösiä kortteja:


Toimineet varsin OK.
 
Tämä tässä pfsensessä jaksaa ihmetyttää (en tiedä onko muilla sama), että bugeja roikotetaan ties kuinka kauan ilman, että niitä korjataan. En tiedä onko noita kuinka ja paljon, mutta itse en ole sen takia siirtynyt uudempaan (2.5.2), kun siinä on se tuo no-ip dyn dns lakkaa toimimasta. Ei aina jaksaisi kikkailla omia korjauksia, että jotain saisi toimimaan. Ei luulisi olevan vaikeaa tehdä pieniä korjaus patcheja bugeille vai onko? Varsinkin, kun tunnetusti näitä ei päivitetä ihan jatkuvalla syklillä vaan päivityksiä saa odottaa aika kauankin.
 
Ei luulisi olevan vaikeaa tehdä pieniä korjaus patcheja bugeille vai onko?
Halvalla saa hyvää, mutta ei nopeasti. Jos tuota korjausta ei jaksa ottaa käyttöön, niin varmaan vaihtamalla no-ip.com salasana sellaiseen, mikä ei tarvitse URL-enkoodausta auttaa. Itsellä toimii sinne mainiosti.
dy.fi:n vaatimaa tiuhempaa päivitystahtia varten olen patchannut vain tämän (pitäisi vaivautua lisäämään tuo UI:lle ja tarjoamaan mainlineen):

/etc/inc: diff dyndns.class dyndns.class.org252
344c344
< $this->_dnsMaxCacheAgeDays = 6;
 
Viimeksi muokattu:
Ei luulisi olevan vaikeaa tehdä pieniä korjaus patcheja bugeille vai onko? Varsinkin, kun tunnetusti näitä ei päivitetä ihan jatkuvalla syklillä vaan päivityksiä saa odottaa aika kauankin.
Kyse ei niinkäään ole vaikeudesta, vaan valinnasta olemaan julkaisematta päivityksiä jatkuvasti. Jokainen muutos ja päivitys tarkoittaa riskejä, että jotain voi mennä rikki. Tämän takia julkaisuversiota on syytä testata pitkään, ennen sen julkaisemista tuotantoon. pfSensen TOP 2 prioriteetti on vakaus ja jatkuva päivittäminen olisi sen vaarantamista. Lisäksi tuo koko no-ip dyn ominaisuus on sen verran harvojen (yritysten) käytössä, ettei asia välttämättä ole erityisen korkealla devaajien prioriteettilistalla.
 
Halvalla saa hyvää, mutta ei nopeasti. Jos tuota korjausta ei jaksa ottaa käyttöön, niin varmaan vaihtamalla no-ip.com salasana sellaiseen, mikä ei tarvitse URL-enkoodausta auttaa. Itsellä toimii sinne mainiosti.
dy.fi:n vaatimaa tiuhempaa päivitystahtia varten olen patchannut vain tämän (pitäisi vaivautua lisäämään tuo UI:lle ja tarjoamaan mainlineen):

/etc/inc: diff dyndns.class dyndns.class.org252
344c344
< $this->_dnsMaxCacheAgeDays = 6;
Tämä oli hyvä muistutus, että ilmainenhan tämä on loppujen lopuksi.

Kyse ei niinkäään ole vaikeudesta, vaan valinnasta olemaan julkaisematta päivityksiä jatkuvasti. Jokainen muutos ja päivitys tarkoittaa riskejä, että jotain voi mennä rikki. Tämän takia julkaisuversiota on syytä testata pitkään, ennen sen julkaisemista tuotantoon. pfSensen TOP 2 prioriteetti on vakaus ja jatkuva päivittäminen olisi sen vaarantamista. Lisäksi tuo koko no-ip dyn ominaisuus on sen verran harvojen (yritysten) käytössä, ettei asia välttämättä ole erityisen korkealla devaajien prioriteettilistalla.
Päivityksiä ei tarvitse joka viikko suoltaa pihalle, vaan pieniä korjauksia voisi tehdä jollain aikataululla, kun bugeja todetaan. Tuo on hyvä, että pyritään vakauteen ja luotettavuuteen sen sijaan, että uusia päivityksiä lykätään jatkuvasti pihalle. Sekin on selvä, että kaikki asiat on mahdoton ottaa huomioon, kun katsoo mihin kaikkeen pfsensekin taipuu lisäosineen.

Tuokin on varmaan totta, että jos tuollaisten bugien kohdalla ei tarpeeksi kuulu meteliä (lue: on harvojen käytössä kuten sanoit), niin näiden korjausten kohdalla ei ole kiirettä.
 

Statistiikka

Viestiketjuista
257 842
Viestejä
4 485 443
Jäsenet
74 005
Uusin jäsen
S Mike

Hinta.fi

Back
Ylös Bottom