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

kilkki sanoi:
Täällä tuli hankittua Fujitsun S920 ja siihen pari porttinen Intelin kortti.
Asentelin OPNsensen.
Kaikki muuten hyvin, mutta internettiä en saa koneelle saakka.
Itse OPNsense laite saa yhteyden internettiin, ku sain hallinnan kautta päivitettyä softan.

Missähän voisi olla vika?

Mielelläni annan lisätietoja. Ennen en oo tällaisten kanssa paininut, nii tietotaito aika lähellä 0
Napsauta laajentaaksesi...

Valitsitko varmasti oikean portin LAN-verkolle? Eli pääseekö sen portin kautta tuonne OPNsensen hallintapaneeliin?
 
kilkki sanoi:
Täällä tuli hankittua Fujitsun S920 ja siihen pari porttinen Intelin kortti.
Asentelin OPNsensen.
Kaikki muuten hyvin, mutta internettiä en saa koneelle saakka.
Itse OPNsense laite saa yhteyden internettiin, ku sain hallinnan kautta päivitettyä softan.

Missähän voisi olla vika?
Napsauta laajentaaksesi...
Vois olla DNS ongelma teitkö asetukset wizardilla?
Koita toimiiko ping 8.8.8.8 ?
 
kilkki sanoi:
Asetukset wizardilla läpi.
Ei pingaa koneelta 8.8.8.8
Napsauta laajentaaksesi...
Mitä asetuksia wizardilla määritetään? Voiko olla että ulospäin (internettiin) menevä liikenne estetty ja pitäisi sallia erikseen asetuksista, jos olet tiukat säädöt laittanut?
 
Ogeli sanoi:
Outoa jos kuitenkin opnsense päivitys toimii.
Näkyykö dashboardilla ulkoinen ip ja gateway?
ja interfaces-overview-wan pitäis olla kaiikki tiedoot myös dns.
Napsauta laajentaaksesi...

1690724859989.png


Tuolta näyttää dashboard.
 
kilkki sanoi:
Täällä tuli hankittua Fujitsun S920 ja siihen pari porttinen Intelin kortti.
Asentelin OPNsensen.
Kaikki muuten hyvin, mutta internettiä en saa koneelle saakka.
Itse OPNsense laite saa yhteyden internettiin, ku sain hallinnan kautta päivitettyä softan.

Missähän voisi olla vika?

Mielelläni annan lisätietoja. Ennen en oo tällaisten kanssa paininut, nii tietotaito aika lähellä 0
Napsauta laajentaaksesi...

Pari factory ressettiä myöhemmin alkoi homma pelittää.
En tiedä missä loppujen lopuksi vika oli.

Mistäs sitten opiskelemaan lisää konffimista? :)
 
Pörkyle sanoi:
teklager.se

TLSense N5105L6: 6x 2.5Gbit LAN, N5105 CPU,

TLSense N5105: 6x 2.5Gbit LAN, N5105 CPU
teklager.se teklager.se
Napsauta laajentaaksesi...

Nyt on tämä malli ollut käytössä jo parisen viikkoa. Musit ja nvme tuli tilattua suomesta. Tehot ei ole vielä ainkaan kesken loppunut. Emolevy on malliltan CW-N11v1.

Ainoa miinus että prossun kontakti jäähyyn oli aika heikko ja lämmöt ampaisi aina heti 80-90 tienoille kun stress testillä nosti CPU rasituksen 100%. Kotelon ja prossun välissä on pieni kuparinen lämmönlevittäjä palikka ja se kiinnitetty koteloon ruuveilla ja välissä lämpötahnaa. Ruuvit oli löysällä ja samoin prossun lämmönlevittäjään kiinnittävät ruuvit oli myös löysällä. Näitä kirimällä tilanne vain paheni. Koitin pienellä määrä tahnaa prossun päällä ja kävi ilmi ettei prossu saanut kontaktia ollenkaan jäähyyn. Siksi varmaan oli alunperin jätetty kupari palikan ruuvit löysällä ettei tahna pursua välistä ja prossu saa edes jotenkin kotaktia.

Nyt parin vanhan amd boxed coolerin teurastuksen jälkeen sain sopivan paksuiset välilevyt tehtyä kotelon ja kuparipalikan väliin ja nyt pysyy lämmöt aisoissa. Välilevyjen paksuus noin 0.2mm, ohuemmatkin olis ehkä riittäny mutta ei niin ohutta alumiini tai kupari levyä tähän hätään ollut saatavilla. Emo ei juurikaan vääntynyt prossua kiristäessä niin näillä mennään. Paksummilla 0.4mm vääntyi huomattavasti.

Ennen lämmöt nousi 60c tietämille jo ihan lataillessa jotain 150-200Mbps nopeudella ja 100% kuormalla lämmöt nousi sinne 90c. Nyt modien jälkeen on tunnin pyöriny stress testi ja lämmöt vielä alle 70c.
CPUrasitus.png

lämmöt.png

Vielä tarkempi kuva viimesestä testistä
lämmöttunti.png


PS.
Tätä juttua kirjottaessa on testi edelleen pyörinyt ja maksimi lämmöt 67c. Kotelo on kuumempi kuin koskaan eli lämpö siirtyy.
 
Viimeksi muokattu:
TP-Link Deco X80 eli 5G modeemi/reititin/WLAN tukisema. Laitetta ei saa siltaavaan tilaan. Onko mitään rautamuuritoteutusta, jonka voi laittaa järkevästi LAN-puolelle? Jos niin minkälaista?

Surkea vekotin X80 asetuksiltaan mutta niin vakaa ja ottaa hyvin nopeudet verkosta edellisten huawei yms. romujen jälkeen, että laitteen vaihto ei tule kyseeseen.
 
pfSense System Patches versio 2.2.5 julkaistu versioille pfSense Plus 23.05.1 ja pfSense CE 2.7.0.
forum.netgate.com

System Patches package version 2.2.5

A new version of the System Patches package is up, version 2.2.5. This version adds several recommended patches for pfSense Plus software version 23.05.1 and pfSense CE software version 2.7.0. If you added a patch entry manually that is the same as a reco...
forum.netgate.com forum.netgate.com
 
user9999 sanoi:
pfSense System Patches versio 2.2.5 julkaistu versioille pfSense Plus 23.05.1 ja pfSense CE 2.7.0.
forum.netgate.com

System Patches package version 2.2.5

A new version of the System Patches package is up, version 2.2.5. This version adds several recommended patches for pfSense Plus software version 23.05.1 and pfSense CE software version 2.7.0. If you added a patch entry manually that is the same as a reco...
forum.netgate.com forum.netgate.com
Napsauta laajentaaksesi...
Kävin asentamassa tuon ja ajastin uudelleenkäynnistyksen ensi yölle.
 
user9999 sanoi:
pfSense System Patches versio 2.2.5 julkaistu versioille pfSense Plus 23.05.1 ja pfSense CE 2.7.0.
forum.netgate.com

System Patches package version 2.2.5

A new version of the System Patches package is up, version 2.2.5. This version adds several recommended patches for pfSense Plus software version 23.05.1 and pfSense CE software version 2.7.0. If you added a patch entry manually that is the same as a reco...
forum.netgate.com forum.netgate.com
Napsauta laajentaaksesi...
Mistäs tämä asennetaan CEssä?
Näköjään System -> Package Manager -> Available package -listaa kun selaa, niin löytyy System Patches. No, asentaen vaan.
Ei muuten ollut tuossa, ja turhaa bootein. System -valikkoon tulee uus kohta, patches. Nämä pitää asentaa sieltä ja vasta sen jälkeen bootti.
 
Viimeksi muokattu:
Tuli tilattua CWWK:n N100 boxi, tuli ilman tulleja (kuten sivuilla mainostettu) ja tilauksesta 10pv kesti tulla noudettavaksi. Harmitukseksi tuli valittua US töpseli, mutta onneksi muuntajassa näyttää olevan C13 virtajohto, joten pitää kaivaa semmoinen valmiiksi. Amazonista tilattu RAM ja SSD ei ole vieläkään tullut, joten vielä ei saa konetta päälle.

Ensimmäisenä tuli tahnat vaihdettua ja huomasin, että pieni osa toisesta sirusta oli ilman tahnaa.

Vähän empeillyt pfSense ja OPNsense välillä, mutta näillä näkymin kallistun OPNsenseen tämän sekoilun takia.
 
  • Tykkää
Reactions: AkQ
Cacceli sanoi:
Vähän empeillyt pfSense ja OPNsense välillä, mutta näillä näkymin kallistun OPNsenseen tämän sekoilun takia.
Napsauta laajentaaksesi...

Samanlainen pähkäily oli itsellänikin jokunen vuosi sitten kun kunnollinen palomuuri piti saada, ja samoista syistä päädyin OPNsenseen minäkin. Ei ole vielä tullut vastaan yhtään syytä tarkastella päätöstä uudelleen.
 
Cacceli sanoi:
Tuli tilattua CWWK:n N100 boxi, tuli ilman tulleja (kuten sivuilla mainostettu) ja tilauksesta 10pv kesti tulla noudettavaksi. Harmitukseksi tuli valittua US töpseli, mutta onneksi muuntajassa näyttää olevan C13 virtajohto, joten pitää kaivaa semmoinen valmiiksi. Amazonista tilattu RAM ja SSD ei ole vieläkään tullut, joten vielä ei saa konetta päälle.

Ensimmäisenä tuli tahnat vaihdettua ja huomasin, että pieni osa toisesta sirusta oli ilman tahnaa.

Vähän empeillyt pfSense ja OPNsense välillä, mutta näillä näkymin kallistun OPNsenseen tämän sekoilun takia.
Napsauta laajentaaksesi...
Asiallisen oloinen vehje, mutta se ikuisuuskysymys: miten niiden BIOS / FW -päivitysten kanssa?
 
Khauron sanoi:
Asiallisen oloinen vehje, mutta se ikuisuuskysymys: miten niiden BIOS / FW -päivitysten kanssa?
Napsauta laajentaaksesi...

CWWK valmistaa nuo itse ja tarjoaa myös BIOS päivityksiä. Ei sen tarkempaa tietoa.

Kakkamyrskyä odotellessa, kun noissa todetaan jotain. Ei tunnetut valmistajatkaan ole täydellisiä. Tämän lisäksi ollaan softan armoilla.

Edit. ja CWWK on siis Chang Wangin kauppa, toimii internetin perusteella sopimusvalmistajana myös muille.

畅网微控 - 迷你主机&网安工控&NAS存储&工控机&嵌入式主板整机制造厂家

东莞畅网从事网安工控整机、小型迷你电脑、路由器、防火墙、网关、NAS等硬件解决方案，集研发、生产、销售为一体的源头生产厂家,致力于网络安全行业提供个性化的OEM/ODM定制服务。
www.changwang.com
 
Viimeksi muokattu:
Cacceli sanoi:
Vähän empeillyt pfSense ja OPNsense välillä, mutta näillä näkymin kallistun OPNsenseen tämän sekoilun takia.
Napsauta laajentaaksesi...
Barbarossa sanoi:
Samanlainen pähkäily oli itsellänikin jokunen vuosi sitten kun kunnollinen palomuuri piti saada, ja samoista syistä päädyin OPNsenseen minäkin. Ei ole vielä tullut vastaan yhtään syytä tarkastella päätöstä uudelleen.
Napsauta laajentaaksesi...



Waybackmachine:llahan tuon Netgate/pfsensen pohjattoman ääliömäisyyden näkee edelleen. Taustaa kerrottuna myös täällä.
OPNsense all the way. Ei koskaan pfsense. Ei tuollaisten henkilöiden varaan voi luottaa omaa palomuuria.
 
Toptopnin boksi tuli ostettua.
Opsensen laitan tuohon, mutta kannattaako tuo laittaa virtuaalisena vai suoraan raudan päälle?
Mahdollisesti jotain pientä adblockeria haluisin kans ajella lisäksi.
Mitkä ovat niin sanotusti plussat ja miinukset?

Boksin speksit:
Intel N5105
16GB DDR4,
256gb nvme + mahdollista laittaa sata kovo toiseksi
4x i226v 2.5G
 
Suoraan raudalle imho.

Opnsenseen saa vaikka plugareina sitten adguardia jne. Tosin en ole kyllä kokeillut miten toimii. Ja on siellä vakionakin advlock listoihin pohjautuvaa blokkausta
 
Käytän pfSenseä NTP palvelimena sisäverkon laitteille. On muutamia laitteita, joissa ei pysty määrittämään NTP palvelinta esim. iOS, iPadOS ja Philips Hue.
Tuon pystyi ratkaisemaan aika helposti eli DNS Resolver ja sieltä Host Overrides. Nyt hakevat ajan pfSense koneelta.
Philips Hue hakee aikaa Kiinasta :hmm:

1692463050172.png

1692463393967.png
 
user9999 sanoi:
Käytän pfSenseä NTP palvelimena sisäverkon laitteille. On muutamia laitteita, joissa ei pysty määrittämään NTP palvelinta esim. iOS, iPadOS ja Philips Hue.
Tuon pystyi ratkaisemaan aika helposti eli DNS Resolver ja sieltä Host Overrides. Nyt hakevat ajan pfSense koneelta.
Philips Hue hakee aikaa Kiinasta :hmm:
Napsauta laajentaaksesi...

Itse olen kotona erilliselle IoT-laitteiden verkolle laittanut palomuuriasetuksen, jolla routteri "kaappaa" laitteiden DNS- ja NTP-kyselyt. Tässä ohjeet: pfSense® software Configuration Recipes — Redirecting Client DNS Requests | pfSense Documentation
 
Telialta tulee gigainen taloyhtiölaajakaista. Nyt mulla on tuollainen i5-5200U-pohjainen Qotomin kiinanihme, jossa pyörii opnSense, ja se onkin hyvin jaksellut, mutta tässä oon ajellut Zenarmoria viime aikoina ja tykännyt siitä oikeinkin paljon. Vähän ajatuksella "koska miksi ei". Ei vaan tunnu jaksavan tuo prossu Zenarmoria yhdistettynä näihin nopeuksiin enää täyttä kaistaa. Varmaan olisi aika päivitellä reitittävää rautaa. Varmaan tuollainen joku N100/N200/N305 olisi passeli?

Kieltämättä vähän ihmetyttää, että miten ei i5-5200U jaksa, mutta onhan siinä kaksi jo aika vanhaa ydintä. :)
 
Sampo_91 sanoi:
Telialta tulee gigainen taloyhtiölaajakaista. Nyt mulla on tuollainen i5-5200U-pohjainen Qotomin kiinanihme, jossa pyörii opnSense, ja se onkin hyvin jaksellut, mutta tässä oon ajellut Zenarmoria viime aikoina ja tykännyt siitä oikeinkin paljon. Vähän ajatuksella "koska miksi ei". Ei vaan tunnu jaksavan tuo prossu Zenarmoria yhdistettynä näihin nopeuksiin enää täyttä kaistaa. Varmaan olisi aika päivitellä reitittävää rautaa. Varmaan tuollainen joku N100/N200/N305 olisi passeli?

Kieltämättä vähän ihmetyttää, että miten ei i5-5200U jaksa, mutta onhan siinä kaksi jo aika vanhaa ydintä. :)
Napsauta laajentaaksesi...
Ettei vaan kyse ole jostain muusta (raudan verkkokortista tai huonoista ajureista koko käyttiksessä tms)? Oman Shuttlen 8 vuotta vanha Celeron on toiminut ongelmitta 1000/400 kuituliittymällä, softana tosin oli pfSense. Vahvasti epäilen ettei tuo i5 riitä gigaselle, mutta ehkä se on se "hinta" mitä tuo valitsemasi palomuuri vaatii. :)
 
Sampo_91 sanoi:
Ei vaan tunnu jaksavan tuo prossu Zenarmoria yhdistettynä näihin nopeuksiin enää täyttä kaistaa
Napsauta laajentaaksesi...
Kyllähän tuo Zenarmor ja vastaavat käyttävät helposti dekadia enemmän resursseja kuin peruspalomuuraus. Ahdistaako muistin vähyyskin, vai pelkkä cpu?

Kuorma on tietysti paljon säännöstöstä riippuva, eli kevyemmällä setillä jaksaa

PS: Mienkäs nämä vertautuu tavoitteisiin vs resursseihin Zenarmor (Sensei): Hardware Requirements — OPNsense documentation
 
mikajh sanoi:
Kyllähän tuo Zenarmor ja vastaavat käyttävät helposti dekadia enemmän resursseja kuin peruspalomuuraus. Ahdistaako muistin vähyyskin, vai pelkkä cpu?

Kuorma on tietysti paljon säännöstöstä riippuva, eli kevyemmällä setillä jaksaa

PS: Mienkäs nämä vertautuu tavoitteisiin vs resursseihin Zenarmor (Sensei): Hardware Requirements — OPNsense documentation
Napsauta laajentaaksesi...
Sen mitä tuosta Zenarmorista luin, niin taitaa tuo pääprosessi käyttää heikosti useampaa ydintä, jos ollenkaan. Lokakuussa pitäisi tulla tähän helpotusta, joten maltetaan rautapäivitysten kanssa sinne asti. :) Tieto kaivettu täältä: Zenarmor throughput with N100 / i226v

Muistia on 16 gigaa, kun mulla pyöri tuossa ennen useampi VM. Nykyään tosiaan ihan baremetal-muuri. Muistinkäyttö pyöri noin kuudessa gigassa silloin, kun tuo oli käytössä.
 
Kontribuutataampa omalla setupilla:

Supermicro M11SDV-8C-LN4F (EPYC 3251 SoC)
64GB DDR4 REG-ECC
2x DC-S4610 7.68TB SSD (ZFS peili)
Intel X520-DA2

Uplink: DNA 1000/200
"Runko"kytkimenä Juniper EX3300


Käyttiksenä Debian. Verkko konfiguroitu networkd:llä. Käytössä kaikki operaattorilta saatavat ipv4-osoitteet (6kpl), joista natataan kama pihalle lähdeverkon perusteella. Natiivi v6 prefix delegationilla. Muuraus nftablesilla. Verkkohommien lisäksi pannulla pyörii erinäisiä monitorointikilkkeitä LXC-konteissa (Grafana, Prometheus, ELK, Elastiflow). Levytilaa on reilusti backuppeja sekä Juniperilta 1:1 sample ratella tulevaa netflow-dataa varten. Kaikki liikenne myös mirroroidaan Juniperilta toiseen X520:n porttiin jonka takana Suricata hoitaa raakapakettianalyysiä.
 

Liitteet

  • suppo.jpeg
    suppo.jpeg
    230,6 KB · Luettu: 108
ponky sanoi:
Kontribuutataampa omalla setupilla:

Supermicro M11SDV-8C-LN4F (EPYC 3251 SoC)
64GB DDR4 REG-ECC
2x DC-S4610 7.68TB SSD (ZFS peili)
Intel X520-DA2

Uplink: DNA 1000/200
"Runko"kytkimenä Juniper EX3300


Käyttiksenä Debian. Verkko konfiguroitu networkd:llä. Käytössä kaikki operaattorilta saatavat ipv4-osoitteet (6kpl), joista natataan kama pihalle lähdeverkon perusteella. Natiivi v6 prefix delegationilla. Muuraus nftablesilla. Verkkohommien lisäksi pannulla pyörii erinäisiä monitorointikilkkeitä LXC-konteissa (Grafana, Prometheus, ELK, Elastiflow). Levytilaa on reilusti backuppeja sekä Juniperilta 1:1 sample ratella tulevaa netflow-dataa varten. Kaikki liikenne myös mirroroidaan Juniperilta toiseen X520:n porttiin jonka takana Suricata hoitaa raakapakettianalyysiä.
Napsauta laajentaaksesi...
Miksi noin monimutkainen setup?
Saat kuusi julkista IP-osoitetta operaattorilta ja reitität niiden mukaan; jokaisella on oma gateway? Et pysty reitittämään verkko <-> verkko ilman kikkoja?
Tuohan menisi yhdellä julkisella ja (pfSensen) HAProxyllä sama setup?
Monitoroinnissa ihan jees setup, mutta TLS 1.3 tappaa sinun setit näkemällä Man-In-The-Middle. Teetkö huvin vuoksi vai jotain ihan oikeaa?
 
Khauron sanoi:
Miksi noin monimutkainen setup?
Saat kuusi julkista IP-osoitetta operaattorilta ja reitität niiden mukaan; jokaisella on oma gateway? Et pysty reitittämään verkko <-> verkko ilman kikkoja?
Tuohan menisi yhdellä julkisella ja (pfSensen) HAProxyllä sama setup?
Napsauta laajentaaksesi...
Laitteen takana on 5 eri sisäverkkoa, jokainen natataan ulos eri IP:stä v4 puolella. IoT & muut blackboxit ovat omassa verkossaan, vieraille oma jne. Tämä lähinnä yksityisyyssyistä. Verkkojen välillä liikenne liikkuu jos muurissa näin sallitaan.
Khauron sanoi:
Monitoroinnissa ihan jees setup, mutta TLS 1.3 tappaa sinun setit näkemällä Man-In-The-Middle.
Napsauta laajentaaksesi...
Ei tuo monitorointi MitM:iä tee. Sinne mirroroidaan liikenne raakana sekä netflowina, joiden perusteella saa visualisoitua ja analysoitua kaiken mitä verkon sisällä liikkuu.
Khauron sanoi:
Teetkö huvin vuoksi vai jotain ihan oikeaa?
Napsauta laajentaaksesi...
Huvin ja harrastuneisuuden vuoksi. Samoja hommia tulee töissäkin tehtyä. Onhan tuo kotikäytössä jossain määrin överi setuppi, mutta toisaalta nukun yöni paremmin jos näen helposti parilla klikkauksella mihin mikäkin laite huutelee.
 
ponky sanoi:
Käyttiksenä Debian. Verkko konfiguroitu networkd:llä. Käytössä kaikki operaattorilta saatavat ipv4-osoitteet (6kpl), joista natataan kama pihalle lähdeverkon perusteella. Natiivi v6 prefix delegationilla. Muuraus nftablesilla.
Napsauta laajentaaksesi...
Itse suunnitellut vähän saman kaltaista setuppia. Onko nuo 6 kpl ipv4 osoitteita macvlan interfaceja vai ihan fyysisiä portteja ? Jos suinkaan viitsit pistää esimerkkiconffeja jakoon, niin olisin kiitollinen. Etenkin gatewayn säätäminen kohdilleen sen jälkeen kun DHCP:llä on ISP:ltä saatu kaikki 6kpl osoitteita on asia jota olen pähkäillyt kun tuota omaa setuppiani olen suunnitellut.
 
Vähän kyllä itteäkin houkutellu ajatus heittää pfSense mäkeen. Tilalla laittaa perus Linux ja säätää networkd:n kaltasella kilkkeellä kaikki kuosiin. Isompana motivaattorina ehkä tuo APU2, joka ei BSD:n kanssa jaksa kunnolla saturoida gigasta kuituyhteyttä. Tunkkausintoa jarruttaa toki se, että pitäs olla toinen laite, jota voisi rauhassa säätää ja kerralla lennosta vaihtaa koko muuri. Rollback mahdollisuus vain tunkemalla verkkokaapelit takasin vanhaan muuriin.
 
jad sanoi:
Itse suunnitellut vähän saman kaltaista setuppia. Onko nuo 6 kpl ipv4 osoitteita macvlan interfaceja vai ihan fyysisiä portteja ? Jos suinkaan viitsit pistää esimerkkiconffeja jakoon, niin olisin kiitollinen. Etenkin gatewayn säätäminen kohdilleen sen jälkeen kun DHCP:llä on ISP:ltä saatu kaikki 6kpl osoitteita on asia jota olen pähkäillyt kun tuota omaa setuppiani olen suunnitellut.
Napsauta laajentaaksesi...
Jep, macvlaneja juurikin. DNA:lta ei speksin mukaan pitäisi tulla kuin 5 osoitetta, mutta täällä päin kaupunkia on ilmeisesti jokin split-dhcp konfiguraatio, jossa osoitteita jaellaan satunnaisesti kahdelta eri palvelimelta eri aliverkoista ja tuo quotan tarkistus ei siitä syystä toimi oikein (mutu).

Kaikki verkot (sisäiset sekä uplink) ovat saman interfacen takana omissa VLAN:eissaan. Operaattorin suuntaan uivan VLAN-interfacen takana on sitten nuo macvlanit. Konffi näyttää about tältä:

/etc/systemd/network/enp6s0f0.network
Koodi: 
[Match]
Name=enp6s0f0

[Network]
IPForward=yes
VLAN=enp6s0f0.10
VLAN=enp6s0f0.32
VLAN=enp6s0f0.36
VLAN=enp6s0f0.37
VLAN=enp6s0f0.38
VLAN=enp6s0f0.39

LinkLocalAddressing=no
LLDP=no
EmitLLDP=no
IPv6AcceptRA=no
IPv6SendRA=no

[RoutingPolicyRule]
Table=5000
Priority=5000
From=10.13.32.0/21
To=10.13.32.0/21
/etc/systemd/network/enp6s0f0.10.netdev (Uplink VLAN)
Koodi: 
[NetDev]
Name=enp6s0f0.10
Kind=vlan

[VLAN]
Id=10

/etc/systemd/network/enp6s0f0.10.network
Koodi: 
[Match]
Name=enp6s0f0.10
Type=vlan

[Network]
DHCP=yes
IPv6AcceptRA=yes
IPv6PrivacyExtensions=prefer-public
MACVLAN=wan32
MACVLAN=wan36
MACVLAN=wan37
MACVLAN=wan38
MACVLAN=wan39

[DHCP]
UseDNS=no
#FallbackLeaseLifetimeSec=86400

[DHCPv6]
PrefixDelegationHint=::/56

/etc/systemd/network/wan32.netdev (VLAN32-verkon NAT-interface)
Koodi: 
[NetDev]
Name=wan32
Kind=macvlan

[MACVLAN]
Mode=bridge

/etc/systemd/network/wan32.network
Koodi: 
[Match]
Name=wan32

[Network]
DHCP=ipv4
IPv6AcceptRA=no

[DHCP]
RouteTable=32
UseDNS=no
#FallbackLeaseLifetimeSec=86400

/etc/systemd/network/enp6s0f0.32.network (VLAN32-verkon sisäpuolen konffi)
Koodi: 
[Match]
Name=enp6s0f0.32
Type=vlan

[Network]
Address=10.13.32.1/24
DHCPServer=yes
#ConfigureWithoutCarrier=yes
IPv6SendRA=yes
DHCPv6PrefixDelegation=yes
IPv6AcceptRA=no

[DHCPServer]
PoolSize=200
DNS=10.13.32.1
NTP=10.13.32.1

[DHCPPrefixDelegation]
SubnetId=32

[Route]
Table=5000
Destination=10.13.32.0/24

Tuo sama sitten copy pastena muille verkoille näin suurin piirtein. Tuo eri IP:eistä pihalle reititys tapahtuu konffeissa olevilla reititystauluilla. v6 on macvlaneilta disabloitu, koska prefix delegationia käyttäessä riittää, että yksi interface saa napattua itselleen /56-blokin joka sitten silputaan /64 paloiksi joita sisäverkon interfacet tarjoilevat laitteille RA:lla. Tuo [DHCPPrefixDelegation]:in alla oleva SubnetId asettaa julkisen prefixin perään verkon numeron ID:nä, esim tapauksessa jossa operaattori tarjoaa 2001:ffff:dead:beef:2300:/56 niin sisäverkon puolella /64 osoitteita aletaan tarjoamaan (verkon 32 tapauksessa) 2001:ffff:dead:beef:2332::/64 lohkosta.
 
Viimeksi muokattu:
networkd:n käynnistyksen jälkeen reitityssäännöt näyttävät verkon 32 osalta tältä:

# ip route show table 32
Koodi: 
default via <dna:n gw> dev wan32 proto dhcp src <32-verkon nat-ip> metric 1024
<gw:n subnet /19> dev wan32 proto dhcp scope link src <32-verkon nat-ip> metric 1024
<dna:n gw> dev wan32 proto dhcp scope link src <32-verkon nat-ip> metric 1024

# ip rule ls | grep enp6s0f0.32
Koodi: 
32762: from 10.13.32.0/24 iif enp6s0f0.32 lookup 32 proto static
 
Huhhuh, onpas kova setup.
Menikö asennukseen kauan aikaa, ja oletettavasti Linux pysyy erittäin hyvin hanskassa? Ja tietysti IP-protokolla.

Itse jaksoin kotona ajaa Suricataa vähän aikaa pfSensessä, mutta sitten kyllästyin. Sain kyllä lopuksi säännöt sun muut melko hyvään kuosiin, mutta sitten totesin ettei ole hyötä Vs. mennyt aika.
 
Khauron sanoi:
Huhhuh, onpas kova setup.
Menikö asennukseen kauan aikaa, ja oletettavasti Linux pysyy erittäin hyvin hanskassa? Ja tietysti IP-protokolla.

Itse jaksoin kotona ajaa Suricataa vähän aikaa pfSensessä, mutta sitten kyllästyin. Sain kyllä lopuksi säännöt sun muut melko hyvään kuosiin, mutta sitten totesin ettei ole hyötä Vs. mennyt aika.
Napsauta laajentaaksesi...
En osaa arvioida paljonko tuohon on vuosien varrella käytetty aikaa. Aikaisempi iteraatio koostui useammasta palikasta; dhcpcd vastasi ulkoverkon suuntaan tapahtuvista IP-asioista, sisäverkko hoitui KEA:lla ja radvd:llä. Noin vuosi sitten siirsin kaiken networkd:n päälle. Konffimisessa ja testaamisessa meni ehkä puolisen päivää. Tämän jälkeen ei ole tarvinut konffeihin kajota.

Monitorointi onkin sitten oma saagansa.

Suricata on aluksi työläs kieltämättä. Perus ET-rulesetillä pääsee kuitenkin jo pitkälle. Olisikohan tuo n. viiden vuoden aikana kolme maltsuhavaintoa ottanut haaviin, kaksi saastunutta Windowsia ja yhden Androidin. Kaikki tietysti vieraiden laitteita :smoke:
 
ponky sanoi:
Jep, macvlaneja juurikin. DNA:lta ei speksin mukaan pitäisi tulla kuin 5 osoitetta, mutta täällä päin kaupunkia on ilmeisesti jokin split-dhcp konfiguraatio, jossa osoitteita jaellaan satunnaisesti kahdelta eri palvelimelta eri aliverkoista ja tuo quotan tarkistus ei siitä syystä toimi oikein (mutu).

Kaikki verkot (sisäiset sekä uplink) ovat saman interfacen takana omissa VLAN:eissaan. Operaattorin suuntaan uivan VLAN-interfacen takana on sitten nuo macvlanit. Konffi näyttää about tältä:
Napsauta laajentaaksesi...
Sain eilen asenneltua testirautaan Debian bookwormin ja tämän päivän aikana vähän ihmettelin tuota networkd:tä ja pääsinkin jo melkein samaan lopputulokseen. Testaillessa sain Elisaltakin 6 kpl ip-osoitteita, vaikka viisi pitäisi olla. Tosin sain jo hetkeksi homman siihenkin tilaan, että Elisa ei antanut yhtään ip:tä :D

Omassa setupissa on kaksi fyysistä interfacea, wan ja lan, niin siltä osin conffi vähän eroaa. RoutingPolicyRule ja Route jäi vielä vaiheeseen, mutta ilmeisemminkin siis jokainen lan vlan ja macvlan interface käyttää aina 1:1 samaa routing tablea (5000,5001,jne) ja näin reititys pysyy kuosissa.

Iso kiitos conffien jakamisesta, helpottaa kummasti Googlettelua kun tietää mitä termejä etsiä :)

Jos olen oikein ymmärtänyt, niin networkd-resolved:a ei saa tekemään nimipalvelinkyselyjä kaikille määritellyille nimipalvelimille samanaikaisesti, eli jos ensimmäinen nimipalvelin on syystä tai toisesta alhaalla, syntyy tästä parin sekunnin viive ennen kuin kyselyä yritetään seuraavalta nimipalvelimelta. Tästä syystä ajattelinkin jättää resolved:n pois käytöstä ja virittää dnsmasq:n tilalle.

Saas nähdä miten äijän käy...
 
jad sanoi:
Sain eilen asenneltua testirautaan Debian bookwormin ja tämän päivän aikana vähän ihmettelin tuota networkd:tä ja pääsinkin jo melkein samaan lopputulokseen. Testaillessa sain Elisaltakin 6 kpl ip-osoitteita, vaikka viisi pitäisi olla. Tosin sain jo hetkeksi homman siihenkin tilaan, että Elisa ei antanut yhtään ip:tä :D
Napsauta laajentaaksesi...
Jos pudottelet interfaceja pois ilman DHCP RELEASEa niin quota saattaa täyttyä operaattorin puolelta ja lisää osoitteita ei tipu ennen kuin aiemmat leaset ovat vanhentuneet.
jad sanoi:
Omassa setupissa on kaksi fyysistä interfacea, wan ja lan, niin siltä osin conffi vähän eroaa. RoutingPolicyRule ja Route jäi vielä vaiheeseen, mutta ilmeisemminkin siis jokainen lan vlan ja macvlan interface käyttää aina 1:1 samaa routing tablea (5000,5001,jne) ja näin reititys pysyy kuosissa.
Napsauta laajentaaksesi...
Tätä olisikin voinut tarkentaa oman konffin osalta. Fyysisen interfacen konffissa on määriteltynä tuo 5000-taulu, mikä hoitaa sisäisen reitityksen kahteen suuntaan. From= ja To= lisäävät rulen samasta /21 lohkosta, joka sisältää nuo kaikki sisäverkon /24 lohkot. Tämän jälkeen jokaisen verkon VLAN-interface lisää noustessaan samaan tauluun säännön, joka ohjaa kyseisen interfacen takana olevaan verkkoon menevän liikenteen oikeaan paikkaan. Tuo 5000 taulu luodaan fyysisen interfacen noustessa siksi, ettei liikennettä pääse missään vaiheessa valumaan ulos esimerkiksi uplinkkiä pitkin (taulussa ei tässä kohtaa ole GW:tä mihinkään suuntaan vaan se tulee vasta VLAN-interfacen noustessa).
jad sanoi:
Iso kiitos conffien jakamisesta, helpottaa kummasti Googlettelua kun tietää mitä termejä etsiä :)
Napsauta laajentaaksesi...
Eipä mitään! Hienoa jos noista oli apua.
jad sanoi:
Jos olen oikein ymmärtänyt, niin networkd-resolved:a ei saa tekemään nimipalvelinkyselyjä kaikille määritellyille nimipalvelimille samanaikaisesti, eli jos ensimmäinen nimipalvelin on syystä tai toisesta alhaalla, syntyy tästä parin sekunnin viive ennen kuin kyselyä yritetään seuraavalta nimipalvelimelta. Tästä syystä ajattelinkin jättää resolved:n pois käytöstä ja virittää dnsmasq:n tilalle.
Napsauta laajentaaksesi...
resolvedin konfiin voi asettaa timeoutiksi vaikka yhden sekunnin jolloin failover-vaihto toimii hyvinkin nopeasti. DNS:n speksiin ei kuulu yksittäisten queryjen roiskiminen kaikille serverille. Round-robinia ei taida resolvedille saada konffattua.

edit:

Tarkennuksena vielä tauluihin. 5000 taulu luodaan varmuuden vuoksi isommalla prioriteetillä kuin ulospäin reititettävän liikenteen taulut. wan<n> interfacet luovat omat taulunsa ilman Priority-asetusta, jolloin niiden priorityksi tulee jotain 32k+. Tässä vielä koko sääntölista:


# ip rule ls
Koodi: 
0:    from all lookup local
5000:    from 10.13.32.0/21 to 10.13.32.0/21 lookup 5000 proto static
32763:    from 10.13.39.0/24 iif enp6s0f0.39 lookup 39 proto static
32764:    from 10.13.36.0/24 iif enp6s0f0.36 lookup 36 proto static
32765:    from 10.13.38.0/24 iif enp6s0f0.38 lookup 38 proto static
32766:    from all lookup main
32767:    from all lookup default
eli jos paketti on tulossa sisältä ja menossa sisälle niin mennään taulun 5000 kautta. Jos tulossa sisältä mutta menossa internettiin niin silloin wan<n> interfacen kautta luotuun tauluun.
 
Viimeksi muokattu:
ponky sanoi:
Jos pudottelet interfaceja pois ilman DHCP RELEASEa niin quota saattaa täyttyä operaattorin puolelta ja lisää osoitteita ei tipu ennen kuin aiemmat leaset ovat vanhentuneet.
Napsauta laajentaaksesi...
Joo, juuri näin kävi kun vaihtelin wan1 interfacen mac osoitetta siinä toivossa, että olisin saanut sille jonkun muun kuin ihan wan0:n vieressä olevan ip-osoiteen ja sitämyöden eri gatewayn, niin olisi nähnyt helpommin että meneekö paketit oikeata reittiä.
ponky sanoi:
resolvedin konfiin voi asettaa timeoutiksi vaikka yhden sekunnin jolloin failover-vaihto toimii hyvinkin nopeasti. DNS:n speksiin ei kuulu yksittäisten queryjen roiskiminen kaikille serverille. Round-robinia ei taida resolvedille saada konffattua.
Napsauta laajentaaksesi...
Joo, onhan tuo vähän DNS:n väärinkäyttöä huudella samaa queryä monelle serverille kerralla. Joskus kun Elisalla oli Cloudflare DNS:n kanssa useampaan otteeseen reititysongelmia, niin tunkkasin nykyisen dnsmasq:iin käyttöön all-servers option päälle. Vaikka olisihan tuon toki korjannut nmipalvelinten järjestystäkin vaihtamalla, mutta tuo all-servers tuntui siihen hetkeen univeraalimmalta ratkaisulta. Tuo sekunninkin timeout näkyy perus web surffailussa yllättävän paljon koska nykytrendinä on ladata vaikka mitä ihmeellistä js-kirjastoa ja muuta pasketta 3. osapuolten palvelimilta.
 
Ehmetti sentään kun pitää näin vanhana pieruna vielä opetella kaikenlaista uutta, kun ei näiden verkkohommien kanssa ole tarvinnut töissäkään enää moneen vuoteen pelehtiä. Puolet on jo unohtunut ja toinen puoli on korvattu uudemmilla paremmilla ratkaisuilla. Jotain ehkä kertoo sekin, että nykyinen käytössä oleva gw-kone pörrää Debian Lennyllä :D

ponky sanoi:
resolvedin konfiin voi asettaa timeoutiksi vaikka yhden sekunnin jolloin failover-vaihto toimii hyvinkin nopeasti. DNS:n speksiin ei kuulu yksittäisten queryjen roiskiminen kaikille serverille. Round-robinia ei taida resolvedille saada konffattua.
Napsauta laajentaaksesi...
Päädyin lopulta hylkäämään dnsmasq:n käytön ja conffin tuon resolved:n käyttöön. Pientä hidastetta meinasi syntyä siitä, että tuohan on alunperin suunniteltu toimimaan vain lokaalina ja siinä oli pitkään kovakoodattuna ainoastan local intefacen kuuntelu.
Tulipahan taas muistutus, että kun lueskelee dokumentaatiota, niin kannattaa ensimmäisenä tarkistaa, että ei lue 5 vuotta vanhaa versiota.

Muuten setuppi näyttää toimivan, nattaus eri vlaneista toimii ja paketit kulkee, mutta mitenkäs sinä @ponky olet tuon itse host koneen liikennöinnin hoitanut ? Oletko dedikoinut yhden wan interfacen käyttämään oletusreititystä, vai säätänyt jotain muuta ?

Selkeesti minulla nyt joku sääntö vielä puuttuu, sillä nyt kun käytössä on wan0 - wan2 ja wan0 käyttää oletus reititystaulua, niin itse hostilta liikennöinti ulospäin toimii, mutta esim. jos pingaa ulkoa päin wan1 tai wan2 ip-osoitteita, niin tcpdumpin mukaan vastaukset kyllä lähtee johonkin, mutta eivät ikinä päädy pingaavalle koneelle. wan0 ip:n pingailu toimii ongelmitta.
 
jad sanoi:
Päädyin lopulta hylkäämään dnsmasq:n käytön ja conffin tuon resolved:n käyttöön. Pientä hidastetta meinasi syntyä siitä, että tuohan on alunperin suunniteltu toimimaan vain lokaalina ja siinä oli pitkään kovakoodattuna ainoastan local intefacen kuuntelu.
Napsauta laajentaaksesi...
Hyvä kun mainitsit, aloin epäilemään itseäni. Eihän se systemd-resolved mullakaan koko verkon nimikyselyistä suoraan vastaa vaan siinä on pihole välissä. Pihole pyörii reitittimellä kontissa jolla on pääsy tuohon resolvedin stub-resolveriin joka sitten hoitaa kyselyt upstreamista DoT:lla.
jad sanoi:
Muuten setuppi näyttää toimivan, nattaus eri vlaneista toimii ja paketit kulkee, mutta mitenkäs sinä @ponky olet tuon itse host koneen liikennöinnin hoitanut ? Oletko dedikoinut yhden wan interfacen käyttämään oletusreititystä, vai säätänyt jotain muuta ?
Napsauta laajentaaksesi...
Macvlan-interfacejen edessä oleva VLAN-interfacen kautta menee alustan yhteydet. Saa yhden julkisista osoitteista ja gw menee main-tauluun.
jad sanoi:
Selkeesti minulla nyt joku sääntö vielä puuttuu, sillä nyt kun käytössä on wan0 - wan2 ja wan0 käyttää oletus reititystaulua, niin itse hostilta liikennöinti ulospäin toimii, mutta esim. jos pingaa ulkoa päin wan1 tai wan2 ip-osoitteita, niin tcpdumpin mukaan vastaukset kyllä lähtee johonkin, mutta eivät ikinä päädy pingaavalle koneelle. wan0 ip:n pingailu toimii ongelmitta.
Napsauta laajentaaksesi...
Lähteekö vastaukset wan0 ifacen ip:llä?
 
Kirjaudu tai rekisteröidy kirjoittaaksesi tänne.

Uutiset

Uutisia lyhyesti

Uusimmat viestit

Statistiikka

Viestiketjuista
262 755
Viestejä
4 564 875
Jäsenet
75 016
Uusin jäsen
repXileS

Hinta.fi

Back
Ylös Bottom