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

Cloudflarella on nykyään peruskäyttäjille ilmainen Cloudlflare Teams Gateway -DNS palvelu, jossa voi itse valita filtteröintikategoriat. Mukana tulee myös logihistoria, toisin kuin Quad9:llä. Tämä tietysti tarkoittaa, että CF seuraa DNS -hakujasi mutta vastapalveluksena saat statistiikan, filtteröintiasetukset ja nopeat resolverit.

Cloudflare for Teams | Secure Your Applications & Networks | Cloudflare
 
Kiitokset @escalibur huippu vinkeistä! Meni kirjanmerkkeihin sen aikaisemman ohjeen kanssa. :)
Vois viikonloppuna testata tuota.

Mä oon käyttäny tuossa VPN jutussa aliasta, johon on määritetty Telian mobiili verkot. Eli vain noista verkoista pystyy ottamaan VPN yhteyden. Ripestä katsonut nuo.
 
Viimeksi muokattu:
user9999 sanoi:
Kiitokset @escalibur huippu vinkeistä! Meni kirjanmerkkeihin sen aikaisemman ohjeen kanssa. :)
Vois viikonloppuna testata tuota.

Mä oon käyttäny tuossa VPN jutussa aliasta, johon on määritetty Telian mobiili verkot. Eli vain noista verkoista pystyy ottamaan VPN yhteyden. Ripestä katsonut nuo.
Napsauta laajentaaksesi...
Kiitos! Ihan hyvä tapa tuokin rajaus.

Pitää tutustua noihin plugarin yksityiskohtiin paremmin ja tehdä ehkä videoversion noista vinkkeistä. :)
 
Jahas Alienvault_v4 IP-lista blokkaa Thomann.de verkkokaupan.

Lieköhän IP (212.204.75.161) jäänne jostain tms.

1606461263731.png
 
Osaisiko joku vääntää rautalangasta, mitä eroa on noilla IP, DNSBL ja vielä tuolla DNSBL category blokkauksilla ?
Kauhia sillisalaatti ja jos tulee jotain ongelmia (esim. joku falsepositive), niin hiton vaikea keksiä minkä blokkaama se mahtaa olla.
Nyt on taas noi kaikki (myös regex) testissä ja todennäköisesti joutuu taas jotain karsimaan ajan saatossa. :)
 
heebo1974 sanoi:
Osaisiko joku vääntää rautalangasta, mitä eroa on noilla IP, DNSBL ja vielä tuolla DNSBL category blokkauksilla ?
Kauhia sillisalaatti ja jos tulee jotain ongelmia (esim. joku falsepositive), niin hiton vaikea keksiä minkä blokkaama se mahtaa olla.
Nyt on taas noi kaikki (myös regex) testissä ja todennäköisesti joutuu taas jotain karsimaan ajan saatossa. :)
Napsauta laajentaaksesi...

IP-blokkaukset ovat nimensä mukaisia IP-osoitteiden blokkauksia.

DNSBL = DNS block list = domain blokkauksia

Estot näet Reports-tabista pfBlockerNG:n valikossa.
 
escalibur sanoi:
IP-blokkaukset ovat nimensä mukaisia IP-osoitteiden blokkauksia.

DNSBL = DNS block list = domain blokkauksia

Estot näet Reports-tabista pfBlockerNG:n valikossa.
Napsauta laajentaaksesi...
Esim. Nyt ilmeni kummallinen ongelma. Laitoin ruutu+:sta BB:tä pyörimään (joo.. myönnän) ja tietokoneella se pysähtyy, koska käytän ilmeisesti jotain mainosten estoa. Telkkarin smart ominaisuudella ko. striimi toimii. Samoin se toimi puhelimella wifissä. Eli jotain tietokoneversio ruudusta on ilmeisesti jollaintapaa erilainen ja haistelee eri mainosblokkereita tmjs..
 
heebo1974 sanoi:
Esim. Nyt ilmeni kummallinen ongelma. Laitoin ruutu+:sta BB:tä pyörimään (joo.. myönnän) ja tietokoneella se pysähtyy, koska käytän ilmeisesti jotain mainosten estoa. Telkkarin smart ominaisuudella ko. striimi toimii. Samoin se toimi puhelimella wifissä. Eli jotain tietokoneversio ruudusta on ilmeisesti jollaintapaa erilainen ja haistelee eri mainosblokkereita tmjs..
Napsauta laajentaaksesi...
Tuntematta ruutu+ palvelua niin varmaan tarjotaan user agentin perusteella vaan eri tarjoajalta mainoksia ja ne nyt osuu johonkin blockkilistaan
 
kuukie sanoi:
Tuntematta ruutu+ palvelua niin varmaan tarjotaan user agentin perusteella vaan eri tarjoajalta mainoksia ja ne nyt osuu johonkin blockkilistaan
Napsauta laajentaaksesi...
Syyllinen taisi löytyä tuosta listasta: http://winhelp2002.mvps.org/hosts.txt , jonka nyt disabloin.
Tästä päästiin juuri tänän ongelmaan näiden listojen kanssa. Eli vaativat kokoajan "huolenpitoa".
Sen takia mielummin ehkä kuitenkin pysyisin vain oikeasti ns. vaarallisissa osoiteissa. Eli mainoksilla ei niin väliä, mutta kaikki troijjalaiset jne. cryptojackkerssit pitäisi pitää kurissa.

Silti hienoa, että joku jaksaa näitä värkkäillä ja auttaa meikäläisiä. Kiitos siitä. :)

EDIT: AAAARGH.. Ilmeisesti se vaihtelee noita mainoksia, koska nyt se taas ei toiminut. :(

EDIT2: Jos haluaisin nyt tehdä noin, eli mainoksien estolla ei niin väliä, mutta kaikki ns. vaaralliset sivustot jos haluan plokata, niin mitkä listoista pitäisi nyt säilyttää ? Vaarallisilla tarkoitan viruksia, bitcoin louhintaa, jne. pasketta. En tarvitse porno/gamblig/date/ns. mitä tahansa joka pahoittaa jonkun mielen blokkeja. Vaan oikeasti kaikki joka voi sotkea konetta tai pölliä henkilötietoja tmjs. Saa olla regexiä tai normilistoja, kunhan ei tarttisi joka päivä ihmetellä miksi joku normi sivusto / videopalvelu ei toimi. Se ei haittaa, jos joku satunnainen pornovideo jää toistamatta. :D
 
Viimeksi muokattu:
Moro, nyt tarvitsin kokeneempien mielipidettä hieman ketjun tilanteesta poiketen.

Tosiaan mulla on kotosalla pienen yrityksen (n. muutama henkilö, mutta n. 10 laitetta) NAS serveri (synology DS718+). Tähän asti olen käyttänyt synologyn openvpn plug-in palvelua ja routerista port forwarding 1194 UDP portilla. Nytten routerin heikon laadun ja tehon takia pitäisi päivittää. Ja haluisin tehdä asiat oikein..

Vaihtoehtoina olen tähän asti miettinyt joko valmiin (lähinnä ubiquiti UDM pro) tai jonkin barebone (shuttle, jimms.fi) ja siihen pfsense. Tarkoitus olisi jakaa oma verkko kahteen osaan sisäverkossa (työ/koti) ja näin estää muu kuin OpenVPN pääsy tiedostoihin. En siis itse kotosalla käytä kyseisen NAS levyasemia. Mitä mieltä täällä ollaan? Oma taito on linux/command line pohjalla ja oma linux serveri tuskin tuottaa ongelmaa. Lähinnä pitäisi olla mahdollisimman vakaa alusta ettei työnteko lopu tietojen saamattomuuteen.

Ajatuksena olisi jossain vaiheessa hankkia myös UPS, sitten tämä uusi routeri, päivittää nykyinen switch ja muutama uusi POE wifi access point.
 
Leoskari sanoi:
Ajatuksena olisi jossain vaiheessa hankkia myös UPS, sitten tämä uusi routeri, ...
Napsauta laajentaaksesi...
Onko ajatuksena myös, että NASiin pitäisi päästä sähkökatkon aikana? Sopiva UPS ei liene ihan halpa, mutta siinä käyttötilanteessa NAS voisi ilmeisesti ajaa virtuaalikoneessa palomuuria ja tehdä parhaassa tapauksessa USB-LTE-donglella itselleen internet-yhteyden.
 
mikajh sanoi:
Onko ajatuksena myös, että NASiin pitäisi päästä sähkökatkon aikana? Sopiva UPS ei liene ihan halpa, mutta siinä käyttötilanteessa NAS voisi ilmeisesti ajaa virtuaalikoneessa palomuuria ja tehdä parhaassa tapauksessa USB-LTE-donglella itselleen internet-yhteyden.
Napsauta laajentaaksesi...
Lähinnä UPS tuo turvaa sähkökatkon varalle ja antaa lan kautta tiedon ajaa NAS hallitusti alas, jolloin pyritään välttämään tietojen menetus levyiltä. Ajatus siitä että NAS toimisi ilman verkkovirtaa UPS varassa on vielä ajatus tasolla (korkeahko hankinnan vuoksi, sekä asun erittäin vakaalla sijainilla, kotitaloon tulee kolme päärunkolinjaa sähköverkosta, jolloin sähkökatos erittäin epätodennöikstä, mutta.....)
 
heebo1974 sanoi:
Syyllinen taisi löytyä tuosta listasta: http://winhelp2002.mvps.org/hosts.txt , jonka nyt disabloin.
Tästä päästiin juuri tänän ongelmaan näiden listojen kanssa. Eli vaativat kokoajan "huolenpitoa".
Sen takia mielummin ehkä kuitenkin pysyisin vain oikeasti ns. vaarallisissa osoiteissa. Eli mainoksilla ei niin väliä, mutta kaikki troijjalaiset jne. cryptojackkerssit pitäisi pitää kurissa.

Silti hienoa, että joku jaksaa näitä värkkäillä ja auttaa meikäläisiä. Kiitos siitä. :)

EDIT: AAAARGH.. Ilmeisesti se vaihtelee noita mainoksia, koska nyt se taas ei toiminut. :(

EDIT2: Jos haluaisin nyt tehdä noin, eli mainoksien estolla ei niin väliä, mutta kaikki ns. vaaralliset sivustot jos haluan plokata, niin mitkä listoista pitäisi nyt säilyttää ? Vaarallisilla tarkoitan viruksia, bitcoin louhintaa, jne. pasketta. En tarvitse porno/gamblig/date/ns. mitä tahansa joka pahoittaa jonkun mielen blokkeja. Vaan oikeasti kaikki joka voi sotkea konetta tai pölliä henkilötietoja tmjs. Saa olla regexiä tai normilistoja, kunhan ei tarttisi joka päivä ihmetellä miksi joku normi sivusto / videopalvelu ei toimi. Se ei haittaa, jos joku satunnainen pornovideo jää toistamatta. :D
Napsauta laajentaaksesi...

Ruutu.fi vaatii, että laittaa osoitteen .fwmrm.net DNSBL Whitelistille. Muuten ei toimi.
 
A Lake Elk sanoi:
Ruutu.fi vaatii, että laittaa osoitteen .fwmrm.net DNSBL Whitelistille. Muuten ei toimi.
Napsauta laajentaaksesi...
Kiitokset, tuo näyttäisi toimivan. Minulla oli fwmrm.net # Viafree kyllä TLD exclusion listalla, mutta siellä se ei näköjään auttanut.
Onko tietoa muiden vastaavien palveluiden whitelistauksista ? Esim. Netflix, yle areena jne. Pika testauksella ne kyllä näyttäisi toimivan ilmankin.
 
heebo1974 sanoi:
Kiitokset, tuo näyttäisi toimivan. Minulla oli fwmrm.net # Viafree kyllä TLD exclusion listalla, mutta siellä se ei näköjään auttanut.
Onko tietoa muiden vastaavien palveluiden whitelistauksista ? Esim. Netflix, yle areena jne. Pika testauksella ne kyllä näyttäisi toimivan ilmankin.
Napsauta laajentaaksesi...

En oo noita muita käyttäny ku tuota Ruutua, niin en osaa niistä sanoa...
 
Mulla on pfSense hoitamassa sekä DHCP- ja DNS-palvelin tehtäviä, niin että "DNS Resolverissä" on päällä täppä kohdassa "DHCP Registration - Register DHCP leases in the DNS Resolver", jotta voin ottaa yhteyden jokaiseen laitteeseen niiden omalla FQDN-nimellä.

Ongelmana on toi pfBlockerNG:n "Unbound python mode" joka aiheuttaa seuraavanlaisen virheen:
The following input errors were detected:
  • DNSBL Python mode is not compatable with the DNS Resolver 'DHCP Registration option'!
  • In order to utilize the DNSBL Python feature, first disable the DNS Resolver DHCP Registration option
Napsauta laajentaaksesi...
Onko tuohon ratkaisua, ilman että:
  1. joudun pistämään koneille kiinteät IP:t ja asettamaan käsin nimet tuonne DNS Resolveriin
  2. tai siirtämään sisäverkon DNS-palvelimen pois pfSensestä ja käyttämään pfSenseä "upstream" DNS resolverinä?
 
A Lake Elk sanoi:
Mulla on pfSense hoitamassa sekä DHCP- ja DNS-palvelin tehtäviä, niin että "DNS Resolverissä" on päällä täppä kohdassa "DHCP Registration - Register DHCP leases in the DNS Resolver", jotta voin ottaa yhteyden jokaiseen laitteeseen niiden omalla FQDN-nimellä.

Ongelmana on toi pfBlockerNG:n "Unbound python mode" joka aiheuttaa seuraavanlaisen virheen:

Onko tuohon ratkaisua, ilman että:
  1. joudun pistämään koneille kiinteät IP:t ja asettamaan käsin nimet tuonne DNS Resolveriin
  2. tai siirtämään sisäverkon DNS-palvelimen pois pfSensestä ja käyttämään pfSenseä "upstream" DNS resolverinä?
Napsauta laajentaaksesi...
Jos haluat käyttää tuota DHCP Registrationia, kannattaa suosiolla jättää Unbound python moden käytämättä ja käyttää pelkkää unboundia. Kyse on kuitenkin BETA-ominaisuudesta.


ps. pfBlockerNG:sta ilmestyi 3.0.0_2-versio. History for net/pfSense-pkg-pfBlockerNG-devel - pfsense/FreeBSD-ports · GitHub
 
Viimeksi muokattu:
Virittelin IOT laitteille oman VLAN verkon pfsense+avahi yhdistelmällä. (Tällä hetkellä verkossa vain Philips HUE)

Kuuluuko tämän toimia niin, että iphonen HUE app ei löydä IOT verkossa olevaa Hue Bridgeä, vaikka tietokoneella saan samasta verkosta Bridgen vastaamaan pingiin?
Mikäli vaihdan puhelimen IOT verkkoon, puhelin löytää bridgen ja saan siihen yhdistettyä. Yhdistämisen jälkeen ohjaus toimii puhelimen apin kautta myös toisesta verkosta.

Tarkoitus siirtää kaikki mahdollinen IOT laitteisto Home Assistantiin, kunhan saan aikaiseksi.

EDIT:
Poistin Avahin käytöstä ja HUE:n ohjaus toimii silti toisesta verkosta.
Palomuurissa LAN verkosta on pääsy IOT verkkoon, mutta IOT verkosta on blokattu pääsy LAN verkkoon. :tdown:
Voiko siis olla, että HUE ei vaadi varsinaisesti minkäänlaista kommunikointia, vaan ottaa kaikki käskyt mukisematta vastaan? (vai onkohan asetuksissa jotain häikkää)
 
Viimeksi muokattu:
pfBlockerNG-devel 3.0.0_3 julkaistu.
github.com

History for net/pfSense-pkg-pfBlockerNG-devel - pfsense/FreeBSD-ports

FreeBSD ports tree with pfSense changes. Contribute to pfsense/FreeBSD-ports development by creating an account on GitHub.
github.com github.com

Edit: Sama homma kuin tuon 3.0.0_2 päivityksen kanssa niin unbound (DNS resolver) palvelu jäi päivityksen jälkeen alas. Manuaalisesti piti käynnistää.
 
Viimeksi muokattu:
A Lake Elk sanoi:
Meni sisään jotenki hitaanpuoleisesti ja tuli sama probleema ku päivitettäessä versioon 3.0.0_1 eli lakkas reitittämästä, mutta korjaantu heti ku teki Interfacelle Release -> Renew.
Napsauta laajentaaksesi...
Jostain syystä Unbound palvelu sammuu päivityksen jälkeen ja pitää käynnistää uudelleen. Sama vika myös edellisessä päivityksessä, aiemmin ei ole ollut ongelmia. Päivitys tosiaan tuntuu kestävän kauan aiempaan verrattuna.
 
VoNpo sanoi:
Virittelin IOT laitteille oman VLAN verkon pfsense+avahi yhdistelmällä. (Tällä hetkellä verkossa vain Philips HUE)

Kuuluuko tämän toimia niin, että iphonen HUE app ei löydä IOT verkossa olevaa Hue Bridgeä, vaikka tietokoneella saan samasta verkosta Bridgen vastaamaan pingiin?
Mikäli vaihdan puhelimen IOT verkkoon, puhelin löytää bridgen ja saan siihen yhdistettyä. Yhdistämisen jälkeen ohjaus toimii puhelimen apin kautta myös toisesta verkosta.

Tarkoitus siirtää kaikki mahdollinen IOT laitteisto Home Assistantiin, kunhan saan aikaiseksi.

EDIT:
Poistin Avahin käytöstä ja HUE:n ohjaus toimii silti toisesta verkosta.
Palomuurissa LAN verkosta on pääsy IOT verkkoon, mutta IOT verkosta on blokattu pääsy LAN verkkoon. :tdown:
Voiko siis olla, että HUE ei vaadi varsinaisesti minkäänlaista kommunikointia, vaan ottaa kaikki käskyt mukisematta vastaan? (vai onkohan asetuksissa jotain häikkää)
Napsauta laajentaaksesi...

Mikäli otat Lan aliverkosta yhteyden Iot aliverkkoon niin palomuuri sallii vastauksen Iot-verkosta Lan-verkkoon, mutta Iot-verkosta ei voi aloittaa yhteyttä Lan-verkkoon, koska palomuuri estää sen. Kuulostaa siis siltä, että toimii oikein.
 
Saanko jotenkin whitelistattua yhden laitteen/IP:n, että pfblockegNG ei vaikuttaisi siihen?

Edit: Rautalangan käyttö on suotavaa :)
 
VoNpo sanoi:
Virittelin IOT laitteille oman VLAN verkon pfsense+avahi yhdistelmällä. (Tällä hetkellä verkossa vain Philips HUE)

Kuuluuko tämän toimia niin, että iphonen HUE app ei löydä IOT verkossa olevaa Hue Bridgeä, vaikka tietokoneella saan samasta verkosta Bridgen vastaamaan pingiin?
Mikäli vaihdan puhelimen IOT verkkoon, puhelin löytää bridgen ja saan siihen yhdistettyä. Yhdistämisen jälkeen ohjaus toimii puhelimen apin kautta myös toisesta verkosta.

Tarkoitus siirtää kaikki mahdollinen IOT laitteisto Home Assistantiin, kunhan saan aikaiseksi.

EDIT:
Poistin Avahin käytöstä ja HUE:n ohjaus toimii silti toisesta verkosta.
Palomuurissa LAN verkosta on pääsy IOT verkkoon, mutta IOT verkosta on blokattu pääsy LAN verkkoon. :tdown:
Voiko siis olla, että HUE ei vaadi varsinaisesti minkäänlaista kommunikointia, vaan ottaa kaikki käskyt mukisematta vastaan? (vai onkohan asetuksissa jotain häikkää)
Napsauta laajentaaksesi...

sra2010 sanoi:
Mikäli otat Lan aliverkosta yhteyden Iot aliverkkoon niin palomuuri sallii vastauksen Iot-verkosta Lan-verkkoon, mutta Iot-verkosta ei voi aloittaa yhteyttä Lan-verkkoon, koska palomuuri estää sen. Kuulostaa siis siltä, että toimii oikein.
Napsauta laajentaaksesi...

Onko tietokone myös langattomasti vai johdolla?
Mulla oli vähän vastaavaa ongelmaa ChromeCastin kanssa ja jonkun aikaa meni ennenkuin tajusin että Unifi controllerissa on asetus (Block LAN to WLAN Multicast and Broadcast Data) joka estää tuon Avahin toiminnan WLANiin.
Mm. tästä oli apua itselle pfsense and Rules For IoT Devices with mDNS
 
Tietokone on johdolla kiinni.
Unifi myös käytössä ja löysin tuon asetuksen, asetus on pois päältä (ilman ruksia) molemmissa wifi verkossa.
 
Viimeksi muokattu:
escalibur sanoi:
PiHolen käyttämä Regex-lista.
Koodi: 
^ad([sxv]?[0-9]*|system)[_.-]([^.[:space:]]+\.){1,}|[_.-]ad([sxv]?[0-9]*|system)[_.-]
Napsauta laajentaaksesi...

Isot kiitokset @escalibur ohjeesta ja testauksesta. Oman testauksen perusteella oheinen rivi Regex-listalla estää ruutu+ palvelun videoiden toiston selaimella. Itsellä myös tämän pfBlockerNG v3 version Regex-lista testikäytössä. Ajattelin laittaa infoksi, kun muillakin näytti olevan ongelmia ruudun kanssa. Poistamalla rivin ruutu+ toimii ilman allaolevaa lisäystä.

A Lake Elk sanoi:
Ruutu.fi vaatii, että laittaa osoitteen .fwmrm.net DNSBL Whitelistille. Muuten ei toimi.
Napsauta laajentaaksesi...

Tämän avulla voi pitää Regex-listan ohjeen mukaisena.
 
Viimeksi muokattu:
Olen aiemmin ohittanut DNSBL:n yhdellä spesifisellä klientilla näiden ohjeiden mukaisesti. Tuon 3.0.0_3 konffaamisen jälkeen dnsbl view:ssä oleva include rivi katoaa DNS resolverin uudelleenkäynnistyksessä. Onko käsitystä saako tuon saman toteutettua jollain muulla tavalla 3.0.0_3 versiossa vai voiko tuo johtua jostain muusta asetuksesta jonka olen laittanut päälle?
 
Rascal sanoi:
Olen aiemmin ohittanut DNSBL:n yhdellä spesifisellä klientilla näiden ohjeiden mukaisesti. Tuon 3.0.0_3 konffaamisen jälkeen dnsbl view:ssä oleva include rivi katoaa DNS resolverin uudelleenkäynnistyksessä. Onko käsitystä saako tuon saman toteutettua jollain muulla tavalla 3.0.0_3 versiossa vai voiko tuo johtua jostain muusta asetuksesta jonka olen laittanut päälle?
Napsauta laajentaaksesi...
Netgate omalla foorumilla DNSBL:n ohituksesta asiaa. bypassing-dnsbl-for-specific-ips
 
multitimo sanoi:
Netgate omalla foorumilla DNSBL:n ohituksesta asiaa. bypassing-dnsbl-for-specific-ips
Napsauta laajentaaksesi...
Tuo on siis juuri tapa jolla se toimi aiemmin mikä ei toimi minulla enää. Ilmeisesti se include rivi katoaa koska /var/unbound/pfb_dnsbl.*conf ei matchaa mihinkään fileen.
Ohitin sen tarjoamalla klientille mahdollisuutta käyttää ulkoista DNS palvelinta ja muut klientit pakotan edelleen käyttämään sisäistä. Pitää tutkia asiaa paremmalla ajalla.
 
Oma SER dualLan rauta levisi. Pitkään on näkynyt raudan interface tasolla virheitä input liikenteessä. Lopulta VGE1 kortti näytti että siinä se vika on. Kättelee enää. 100Mbps/Full nopeudella, vaikka mitä sille virpoisi. Koitin Opnsenseäkin jotta jos olisi ollut vain pfSensen ajuri tms korruptoitunut. Harmillista, olis ollut hyvä kampe, pitänee nyt katsoa jotain muuta rautaa tilalle. Tuossa jo funtsin että jos laittaisi tällaisen :
www.tietokonepalveluhietaniemi.fi

Dell OptiPlex 7040 MFF / i5-6500T / 128Gt SSD / 8Gt DDR4 / Win 10 Pro / B-grade

Tehokas ja monipuoliseen käyttöön soveltuva erittäin pienikokoinen yritystason pöytäkone 6. sukupolven Intel Core i5-prosessorilla ja nopealla SSD-levyllä. Täydellinen ratkaistu pieneen tilaan, esimerkiksi mediakoneeksi television viereen, TV-tason alle kätköön tai tilaa säästäväksi ratkaisuksi...
www.tietokonepalveluhietaniemi.fi

Ja lisäisi vaan jonkin USB3 tms lisäverkkokortin tuohon.

Edit: typo ja huomio, jumankekka on saanut vanhaa gigabit interfaceilla olevaa kuluttaja rautaa boottailla viikottain, joskus useamminkin. Onneks pari varapurkkia löytyi nurkista, muistin alkuunsa ettei olisi ollut yhtäkään enää missään.. kaksi löysin.
 
dot1q sanoi:
Oma SER dualLan rauta levisi. Pitkään on näkynyt raudan interface tasolla virheitä input liikenteessä. Lopulta VGE1 kortti näytti että siinä se vika on. Kättelee enää. 100Mbps/Full nopeudella, vaikka mitä sille virpoisi. Koitin Opnsenseäkin jotta jos olisi ollut vain pfSensen ajuri tms korruptoitunut. Harmillista, olis ollut hyvä kampe, pitänee nyt katsoa jotain muuta rautaa tilalle. Tuossa jo funtsin että jos laittaisi tällaisen :
www.tietokonepalveluhietaniemi.fi

Dell OptiPlex 7040 MFF / i5-6500T / 128Gt SSD / 8Gt DDR4 / Win 10 Pro / B-grade

Tehokas ja monipuoliseen käyttöön soveltuva erittäin pienikokoinen yritystason pöytäkone 6. sukupolven Intel Core i5-prosessorilla ja nopealla SSD-levyllä. Täydellinen ratkaistu pieneen tilaan, esimerkiksi mediakoneeksi television viereen, TV-tason alle kätköön tai tilaa säästäväksi ratkaisuksi...
www.tietokonepalveluhietaniemi.fi

Ja lisäisi vaan jonkin USB3 tms lisäverkkokortin tuohon.

Edit: typo ja huomio, jumankekka on saanut vanhaa gigabit interfaceilla olevaa kuluttaja rautaa boottailla viikottain, joskus useamminkin. Onneks pari varapurkkia löytyi nurkista, muistin alkuunsa ettei olisi ollut yhtäkään enää missään.. kaksi löysin.
Napsauta laajentaaksesi...

USB3-verkkokortin kanssa en lähtisi leikkimään, eivät välttämättä toimi yhteen PFSensen tai raudan kanssa. Halvemmalla saat esimerkiksi saman minkä itse hankin joku aika sitten:

HP ProDesk 400 G3 SFF i5-6500/4/120SSD/WIN10P | Grenius

Tuohon vaan 2- tai 4-porttinen verkkokortti kiinni, tehot ainakin riittää.
 
Mulla on kanssa tuollainen USB3-verkkokortti. PfSense tunnistaa sen ihan ok, mutta ei se toimi. En ainakaan saanut DHCP:tä toimimaan tuon USB-verkkokortin läpi.
Edit: Tuo USB3-verkkokortti muistaakseni toimi jonkin pfSense version kanssa, mutta ei enää uusimmalla versiolla.
 
Viimeksi muokattu:
Gobi sanoi:
USB3-verkkokortin kanssa en lähtisi leikkimään, eivät välttämättä toimi yhteen PFSensen tai raudan kanssa.
Napsauta laajentaaksesi...
Noinhan se on. Mutta pelkkä usb-ethernet, joka ei tarvitse moodinvaihtoja (toisin kuin joku nettitikku tai mobiilitukiasema usd-korttislotin takia) voi silti toimia huomattavasti helpommin ja luotettavammin.

Jos interface puuttuu, joka on vielä liitetty VLAN:iin, niin pfSense alkaa bootissa kyselemään mites VLANit nyt kuuluu olla eikä boottaa. Tuo on se ehkä harmillisin seuraus, mikä epäluotettavasta on/off-verkko"kortista" aiheutuu
 
dot1q sanoi:
Mites tällaiset verkkokortit?

M.2 paikkaan menevät verkkokortit? Näyttäisi olevan intel 210 pohjainen ja Lnx tuki 2.6 alken.. Tahtoisin tuon MFF kokoluokan purkin mielellään. SFF on kömpelömmän kokoinen.
Napsauta laajentaaksesi...
Tuokin riippuu ihan FreeBSD:n ajurituesta. Olettaisin että toiminta voi olla lottoamista, joten varmin tapa saada toimivan ratkaisun on käyttää perinteistä Intelin piiriin perustuvaa verkkokorttia. Nuo USB-adapterit ja vastaavat melko poikkeuksetta perustuvat RealTekin verkkopiiriin joiden tuki Unix/Linux-maailmassa on mitä on. (RealTekin verkkopiirit käyttävät softaemulointia siinä missä Intelin verkkokortit käyttävät oikeaa rautaa.)

Tästä voi tarkistella "sinne päin"-liittyvää ajuritukea eri piirien osalta: Comparison of open-source wireless drivers - Wikipedia
 
user9999 sanoi:
Mulla on kanssa tuollainen USB3-verkkokortti. PfSense tunnistaa sen ihan ok, mutta ei se toimi. En ainakaan saanut DHCP:tä toimimaan tuon USB-verkkokortin läpi.
Edit: Tuo USB3-verkkokortti muistaakseni toimi jonkin pfSense version kanssa, mutta ei enää uusimmalla versiolla.
Napsauta laajentaaksesi...
DHCP:n toiminta ei kyllä oikein voi johtua verkkokortista. Eihän se ole protokollissa mitenkään osallinen, vain tyhmä Layer 1 -tason datamuunnin
 
Paremman ajurituen USB3-verkkokorteille saanee Linux-maailmassa kuin FreeBSD:ssä, joten yksi vaihtoehto on ajaa PfSenseä virtuaalikoneessa esim. Proxmoxin päällä.

Itse ajelin muutaman viikon onnistuneesti PfSenseä virtuaalikoneessa Intelin 8gen NUCilla WAN-portti kytkettynä tähän Ugreenin USB3-verkkokorttiin. Tuo USB-verkkokortti ei siis ollut passthroughna vm:lle vaan linkattuna Proxmoxissa omaan IP-osoitteettomaan bridgeen, johon PfSensen WAN-interface kytkettynä. PfSensessä DHCP päällä ja hyvin toimi.

Mitään ongelmia ei ollut, mutta palasin kuitenkin käyttämään APU2C4 rautaa koska koin periaatteellisesti hankalaksi sen että yksi virtuaalikone on oltava käynnissä ennenkuin yksikään muu laite verkossa toimii (et pääse DHCP:llä verkkoon käynnistämään ko. virtuaalikonetta mikäli se sattuisi olemaan sammuksissa jostain syystä...).
Saattaa olla että palaan vielä virtualisoidun PfSensen käyttäjäksi mikäli päivitän yhteyden 500M -> 1G ja APUsta loppuu tehot tai mikäli haluan lisää julkisia IP-osoitteita. Virtualisoidussa ympäristössä julkisia IP-osoitteita on helppo napsia DHCP:llä lisää kun virtuaalisia interfaceja voi lisäillä mielinmäärin. :smile:
 
mikajh sanoi:
DHCP:n toiminta ei kyllä oikein voi johtua verkkokortista. Eihän se ole protokollissa mitenkään osallinen, vain tyhmä Layer 1 -tason datamuunnin
Napsauta laajentaaksesi...
Kokeilin uudestaan niin ei anna IP:tä ja aika mykkä on tuo USB3-verkkokortti. Ei toimi myöskään jos koneeseen määrittää kiinteän IP:n.

Untitled.png


Edit: Tuo USB3-verkkokortti on siis D-Link DUB-1312.
 
user9999 sanoi:
Kokeilin uudestaan niin ei anna IP:tä ja aika mykkä on tuo USB3-verkkokortti. Ei toimi myöskään jos koneeseen määrittää kiinteän IP:n.
Edit: Tuo USB3-verkkokortti on siis D-Link DUB-1312.
Napsauta laajentaaksesi...
Tuo nyt ei paljoa kerro, paitsi että if on mielestään lähettänyt 3 pakettia onnistuneesti.
Onko tuossa 192.168.2.0/24 subnetissa mitään muuta laitetta kuin nyt .1 eli onko sitä ylipäätään olemassa?
 
Te ketkä olette useampaa palomuuri softaa/valmistajaa käyttänyt, niin onko logiikka suunnilleen sama kaikissa? Itse olen ainoastaan käyttänyt pfsenseä ja omasta mielestä tämä logiikka (Huom omasta mielestä) ei ole kaikista selkein. Esimerkkinä, jos luon verkon ja haluaisin pitää sen verkon erillään muista verkoista ja päästää suoraan ulos (internettiin), niin tuo pitää kikkailla aliaksilla ja kääntrisillä muuri säännöillä, kun ei saa suoraan sääntöä, että sallitaan tänä verkko wan:iin.

Pidän hyvin mahdollisena, että en vain osannut (tästä on varmaan vuosi aikaa, kun noita viimeksi tein). Tuli nyt taas tällainen mieleen, kun rupesi tätä ketjua lukemaan.
 
Rascal sanoi:
Tuo on siis juuri tapa jolla se toimi aiemmin mikä ei toimi minulla enää. Ilmeisesti se include rivi katoaa koska /var/unbound/pfb_dnsbl.*conf ei matchaa mihinkään fileen.
Ohitin sen tarjoamalla klientille mahdollisuutta käyttää ulkoista DNS palvelinta ja muut klientit pakotan edelleen käyttämään sisäistä. Pitää tutkia asiaa paremmalla ajalla.
Napsauta laajentaaksesi...
Ei varmaan hirveän monella ole view:t käytössä mutta jos joku muut ihmetteli samaa niin tuo oli allekirjoittaneen virhe. Release noteseissa sanotaan selkeästi että view:t eivät ole tuettu Python Modessa.

The DNS Resolver Unbound "Views" feaure it not currently compatable with DNSBL Python mode. The "Views" feature will be incorporated into the new Python Mode in future.
Napsauta laajentaaksesi...
 
Minä tein vanhasta koneesta rautapalomuurin kone oli joskus ollut pelikäytössä 90 luvun alussa. Niitä on muitakin hyviä ja tähän hetkeen sopivia laitteita, kuten raspberry tai vastaava rauta. Itse rakennan mieluiten, maksaa "hunajaa" ostaa joku valmis laite esim Suomesta, onhan noissa nyky laitteissa jo modeemissakin palomuuri. Eri juttu, jos olisi pelkkä Registered Jack- 45 seinästä. Joutuisi käyttämään CAT-6e piuhaa rautamuurille siitä ohjata se koneelle ja omaan verkkoon.
 
VoNpo sanoi:
Virittelin IOT laitteille oman VLAN verkon pfsense+avahi yhdistelmällä. (Tällä hetkellä verkossa vain Philips HUE)

Kuuluuko tämän toimia niin, että iphonen HUE app ei löydä IOT verkossa olevaa Hue Bridgeä, vaikka tietokoneella saan samasta verkosta Bridgen vastaamaan pingiin?
Mikäli vaihdan puhelimen IOT verkkoon, puhelin löytää bridgen ja saan siihen yhdistettyä. Yhdistämisen jälkeen ohjaus toimii puhelimen apin kautta myös toisesta verkosta.

Tarkoitus siirtää kaikki mahdollinen IOT laitteisto Home Assistantiin, kunhan saan aikaiseksi.

EDIT:
Poistin Avahin käytöstä ja HUE:n ohjaus toimii silti toisesta verkosta.
Palomuurissa LAN verkosta on pääsy IOT verkkoon, mutta IOT verkosta on blokattu pääsy LAN verkkoon. :tdown:
Voiko siis olla, että HUE ei vaadi varsinaisesti minkäänlaista kommunikointia, vaan ottaa kaikki käskyt mukisematta vastaan? (vai onkohan asetuksissa jotain häikkää)
Napsauta laajentaaksesi...

Omaa viestiä lainaten. Jonkinlaista edistystä IOT verkon kanssa.
HUE Bridge ja lamput ovat IOT verkossa ja ohjaus toimii LAN verkosta. Painin aiemmin HUE Bridgen löytymättömyyden kanssa ja sain jonkinlaisen ratkaisun aikaiseksi.
Bridge ilmeisesti käyttää SSDP protokollaa ilmoittaakseen olemassa olostaan. Lisäsin IOT verkon palomuuriin pääsyn Bridgen IP:stä (vain portti 1900) LAN net:tiin.
Osaako joku viisaampi sanoa onko tuohon parempaa ratkaisua? Kuinka paljon LAN verkon "turvallisuus" kärsii tästä?

EDIT:
Mitä tekee IGMP snooping? Sitä monessa tutoriaalissa käytetään. Kyseinen asetus löytyy kytkimestä ja se antaakin HUEn käytössä olevalle portille erikoisen IP osoitteen.
 
Viimeksi muokattu:
VoNpo sanoi:
Omaa viestiä lainaten. Jonkinlaista edistystä IOT verkon kanssa.
HUE Bridge ja lamput ovat IOT verkossa ja ohjaus toimii LAN verkosta. Painin aiemmin HUE Bridgen löytymättömyyden kanssa ja sain jonkinlaisen ratkaisun aikaiseksi.
Bridge ilmeisesti käyttää SSDP protokollaa ilmoittaakseen olemassa olostaan. Lisäsin IOT verkon palomuuriin pääsyn Bridgen IP:stä (vain portti 1900) LAN net:tiin.
Osaako joku viisaampi sanoa onko tuohon parempaa ratkaisua? Kuinka paljon LAN verkon "turvallisuus" kärsii tästä?

EDIT:
Mitä tekee IGMP snooping? Sitä monessa tutoriaalissa käytetään. Kyseinen asetus löytyy kytkimestä ja se antaakin HUEn käytössä olevalle portille erikoisen IP osoitteen.
Napsauta laajentaaksesi...

Muistaakseni liittyy multicast liikenteen välittämiseen vain laitteille jotka ovat jonkin multicast ryhmän jäseniä jolloin ei välitetä turhaan multicast liikennettä portteihin jotka eivät sitä tarvitse. Mielestäni ei pitäisi vaikuttaa mitenkään ip osoitteeseen joka laitteelle annetaan.

en.wikipedia.org

IGMP snooping - Wikipedia

en.wikipedia.org en.wikipedia.org
 
Kirjaudu tai rekisteröidy kirjoittaaksesi tänne.

Uutiset

Uutisia lyhyesti

Uusimmat viestit

Statistiikka

Viestiketjuista
260 438
Viestejä
4 521 454
Jäsenet
74 624
Uusin jäsen
SeAino

Hinta.fi

Back
Ylös Bottom