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

jad

Liittynyt
22.10.2016
Viestejä
1 205
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.
Haa, olinkin unohtanut koko piholen. Pitääkin laittaa tuo vielä räpellyslistalle, kunhan nyt ensin saa muuten setupin kuntoon.
Lähteekö vastaukset wan0 ifacen ip:llä?
Näyttäisi lähtevän wan1 ip:llä, mutta kuitenkin wan0 interfacesta. tcpdump:lla kun kuuntelen joko alla olevaa fyysistä interfacea tai wan0:aa, niin wan0:aa pingatessa molemmat näyttää siltä miltä pitäisikin.
Kun pingaan wan1:tä. Niin kuunnellessa fyysistä interfacea, tcpdump näyttää normaalilta:
enp.png

Mutta jos kuuntelenkin wan1:tä, niin haaviin jää pelkät requestit:
wan1.png

Ja replyt löytyykin wan0:aa kuuntelemalla, mutta ip osoite on kuitenkin wan1:n:
wan0.png


En nyt heti keksinyt syytä, että mikä bitti on vinossa, että näin pääsee käymään.
 
Liittynyt
23.10.2016
Viestejä
483
Tuli itse vaihdettua purkkia APU2:sta --> NetGate 2100 MAX.
Harmi että pfSensen / FreeBSD:n kytkinominaisuudet ovat suoraan sanoen paskat, eikä mitään lisäosia tähän löydy. Ajattelin, että ylimääräiset portit olisi nätisti toimineet bridgenä, jossa VLANeja, mutta ei toimi ei.
Todella hyvä purkki, ja paljon näpsäkämpi mitä vanha. Internetinä on 1000 M / 1000 M symmetrinen FTH. ISP:n kuitumuunnin on välissä siltaavana fibre --> ethernet.

Sitten onkin kovaa etsintää 2.5 Gbit/s hallittavan kytkimen hankintaan, jotta saa WIFI Access pointit ja Plexit sun muut rokkaamaan täydellä hyödyllä. Eroa en varmaan edes huomaa, mutta pakko saada :p

Edit: Nyt siis 1000 Mbit/s hallittavat kytkimet (3 kpl) tontilla, mitkä toimivat niin kuin voi odottaa.
 
Liittynyt
16.02.2019
Viestejä
19
Tuli itse vaihdettua purkkia APU2:sta --> NetGate 2100 MAX.
Harmi että pfSensen / FreeBSD:n kytkinominaisuudet ovat suoraan sanoen paskat, eikä mitään lisäosia tähän löydy. Ajattelin, että ylimääräiset portit olisi nätisti toimineet bridgenä, jossa VLANeja, mutta ei toimi ei.
Tarkennatko vähän minkälaista konffausta haaveilit toteuttavasi? Jokaisessa portissa olisi samat vlanit ja jakaisit kuorman tasaisesti eri porttien kesken / käyttäisit jokaista porttia omana uplinkkinään per kytkin?
 
Liittynyt
23.10.2016
Viestejä
483
Vaikea selittää, mutta koetetaan:
Purkissa 5 porttia, 1 WAN, 4 LAN. Kutsutaan niitä LAN1, LAN2, LAN3, LAN4.

Koetin bridgettää kaikki 4 LAN-porttia. Toimii.
Kun lisään VLANit samaan bridgeen, ei toimi.
Lukemani perusteella pfSensessä / opnSensessä / FreeBSD:ssä ei toimi se, että bridge-interfacessa ei toimi VLANit, jossa on untagged ja tagged -portteja. Yksi interface ja yksi VLAN toimii, mutta omassa setupissa interfaceja olisi 4 kpl ja VLANeja 4 kpl.
Tämä kaikki toimii, jos vedän sen yhden interfacen läpi. Jos teen bridgen (eli lisään portit 2-4), ei toimi enää. Testasin tämän HP J9660A -kytkimellä, sekä Hyper-V:n päällä olevalla Wire:llä.

Tämä kaikki sen vuoksi, että olisin voinut hyödyntää purkin 2.5 GBit/s -portteja.
Nyt setup toimii yhden pfSense -interfacen kautta täydelliseti, mutta seuraava hop on 1 GBit /s -kytkin.
Olisin siis halunnut pfSense-purkin kaikki portit käyttöön 2.5 GBit/s ja VLAN-tuella. Kaikki LAN-portit bridgenä.

Edit: Eli kaikki pfSense-purkin LAN-portit (bridge) heittäisivät ulos samoja VLANeja. Untagged ja tagged.

Edit 2: Koetin siis päästä yhdestä kytkimestä eroon välistä, jolloin olisin saanut WIFI-Acces-Point tukariin suoran 2.5GBit/s liitynnän.
 
Viimeksi muokattu:
Liittynyt
17.10.2016
Viestejä
3 803
Vaikea selittää, mutta koetetaan:
Purkissa 5 porttia, 1 WAN, 4 LAN. Kutsutaan niitä LAN1, LAN2, LAN3, LAN4.

Koetin bridgettää kaikki 4 LAN-porttia. Toimii.
Kun lisään VLANit samaan bridgeen, ei toimi.
Lukemani perusteella pfSensessä / opnSensessä / FreeBSD:ssä ei toimi se, että bridge-interfacessa ei toimi VLANit, jossa on untagged ja tagged -portteja. Yksi interface ja yksi VLAN toimii, mutta omassa setupissa interfaceja olisi 4 kpl ja VLANeja 4 kpl.
Tämä kaikki toimii, jos vedän sen yhden interfacen läpi. Jos teen bridgen (eli lisään portit 2-4), ei toimi enää. Testasin tämän HP J9660A -kytkimellä, sekä Hyper-V:n päällä olevalla Wire:llä.

Tämä kaikki sen vuoksi, että olisin voinut hyödyntää purkin 2.5 GBit/s -portteja.
Nyt setup toimii yhden pfSense -interfacen kautta täydelliseti, mutta seuraava hop on 1 GBit /s -kytkin.
Olisin siis halunnut pfSense-purkin kaikki portit käyttöön 2.5 GBit/s ja VLAN-tuella. Kaikki LAN-portit bridgenä.

Edit: Eli kaikki pfSense-purkin LAN-portit (bridge) heittäisivät ulos samoja VLANeja. Untagged ja tagged.

Edit 2: Koetin siis päästä yhdestä kytkimestä eroon välistä, jolloin olisin saanut WIFI-Acces-Point tukariin suoran 2.5GBit/s liitynnän.
Niin oliko nuo 2,5G portit tuossa APU2:ssa? Ainakin NetGate 2100 MAX on googlen mukaan vain 1G portit.

Hankala sanoa kun ei näe konffista mutta tuossa ilmeisesti on nuo lan portit sisäisen switchin takana joten tämä varmaan vaikuttaa konffiin vrt. että olisi suoraan reitittimen portissa. Muutenkin reitittävien porttien kohdalla bridgejä kannattaa välttää sillä useinmiten suorituskyky tulee ongelmaksi kun liikenne joudutaan ajamaan prossan läpi.
 
Liittynyt
17.10.2016
Viestejä
28
Lukemani perusteella pfSensessä / opnSensessä / FreeBSD:ssä ei toimi se, että bridge-interfacessa ei toimi VLANit, jossa on untagged ja tagged -portteja. Yksi interface ja yksi VLAN toimii, mutta omassa setupissa interfaceja olisi 4 kpl ja VLANeja 4 kpl.
Frisbeen verkkostäkki ei ole itselle tuttu, mutta Linkkaripuolella "softakytkinten" tai bridgejen tapauksessa homma toimii niin, että fyysisen interfacen päälle luodaan VLAN-interface joka liikuttelee tägättyjä paketteja ja natiivi VLAN tai tägäämätön liikenne hoidetaan silloin tuolla fyysisellä interfacella. Tuossa tapauksessa joutuu luomaan jokaista L2-verkkoa varten oman bridgen joihin sitten lisäilee kunkin interfacen päälle liimatun VLAN-interfacen. Täysin mahdollista, että *BSD toteuttaa tämän jotenkin eri tavalla.


Ainakin tämän perusteella menisi juuri noin, eli mainitsemasi setuppi pitäisi kyllä olla mahdollista toteuttaa. Samaan siltaan pitäisi myös pystyä lisäämään samaan aikaan interface sekä kyseisen interfacen VLAN-interfaceja, jolloin liikenne lähtee kyseisestä portista sekä tägin kanssa että ilman.
 
Liittynyt
17.10.2016
Viestejä
28
Haa, olinkin unohtanut koko piholen. Pitääkin laittaa tuo vielä räpellyslistalle, kunhan nyt ensin saa muuten setupin kuntoon.

Näyttäisi lähtevän wan1 ip:llä, mutta kuitenkin wan0 interfacesta. tcpdump:lla kun kuuntelen joko alla olevaa fyysistä interfacea tai wan0:aa, niin wan0:aa pingatessa molemmat näyttää siltä miltä pitäisikin.
Kun pingaan wan1:tä. Niin kuunnellessa fyysistä interfacea, tcpdump näyttää normaalilta:

Mutta jos kuuntelenkin wan1:tä, niin haaviin jää pelkät requestit:

Ja replyt löytyykin wan0:aa kuuntelemalla, mutta ip osoite on kuitenkin wan1:n:


En nyt heti keksinyt syytä, että mikä bitti on vinossa, että näin pääsee käymään.
Selvisikö? Mikä arvo sulla on rp_filterissä? sysctl -a | grep rp_filter
 
Liittynyt
23.10.2016
Viestejä
483
Niin oliko nuo 2,5G portit tuossa APU2:ssa? Ainakin NetGate 2100 MAX on googlen mukaan vain 1G portit.

Hankala sanoa kun ei näe konffista mutta tuossa ilmeisesti on nuo lan portit sisäisen switchin takana joten tämä varmaan vaikuttaa konffiin vrt. että olisi suoraan reitittimen portissa. Muutenkin reitittävien porttien kohdalla bridgejä kannattaa välttää sillä useinmiten suorituskyky tulee ongelmaksi kun liikenne joudutaan ajamaan prossan läpi.
Näin itsekin olen ymmärtänyt pfSensen ja opnSensen forumeilta. TL;DR: vältä bridgejä.

Sekoilin mallinimissä, oikea malli on siis 4100. Ja tosiaan 4 kpl 2.5 GBit/s -ethernetportteja. APU2 oli vanha vehje, ja se on nyt offline tuossa pöydällä.

Frisbeen verkkostäkki ei ole itselle tuttu, mutta Linkkaripuolella "softakytkinten" tai bridgejen tapauksessa homma toimii niin, että fyysisen interfacen päälle luodaan VLAN-interface joka liikuttelee tägättyjä paketteja ja natiivi VLAN tai tägäämätön liikenne hoidetaan silloin tuolla fyysisellä interfacella. Tuossa tapauksessa joutuu luomaan jokaista L2-verkkoa varten oman bridgen joihin sitten lisäilee kunkin interfacen päälle liimatun VLAN-interfacen. Täysin mahdollista, että *BSD toteuttaa tämän jotenkin eri tavalla.


Ainakin tämän perusteella menisi juuri noin, eli mainitsemasi setuppi pitäisi kyllä olla mahdollista toteuttaa. Samaan siltaan pitäisi myös pystyä lisäämään samaan aikaan interface sekä kyseisen interfacen VLAN-interfaceja, jolloin liikenne lähtee kyseisestä portista sekä tägin kanssa että ilman.
Kaikkeni koetin, mutta en vaan saa toimimaan. Tuo linkin setup kyllä onnistuu, siinä on yhdessä bridgessä yksi VLAN. Vastaavan saan siis toimimaan, mutta haluaisin bridgettää kaikki 4 kpl LAN-portteja yhdeksi bridgeksi, ja tässä bridgessä olisi 4 kpl VLANeja. Untagattynä kulkisi "perusverkko", jonka tarvisi olla saatavilla heti seuraavissa vehkeissä (WIFI-tukari, 3 kpl managed-kytkimiä). Sen voisi ehkä ajatella niin, että minulla on neljäkerroksinen talo, ja kellarikerroksessa on tuo pfSense. Kaikki toimii hienosti jos kellarikerroksessa on pfSensen perässä yksi managed-kytkin. Jos poistan tuon managed-kytkimen välistä, kytkeytyisi jokainen kerros omaan fyysiseen porttiinsa pfSensessä (bridge). Kaikille kerroksille täytyisi juosta samat VLANit. Kytkimet eivät ole kytkettyjä toisiinsa muuta kuin tuon pfSensen kautta.

Konffeja tai screenshotteja konffista voin kyllä jakaa, ja oikeastaan mitä vaan pystyn testaamaan. Täytyy vaan vähän valita aikaa, kun kooman seurauksena koko perhe on ilman internettiä sen aikaa kunnes saan palautettua edellisen version :)
 
Liittynyt
27.12.2018
Viestejä
2 366
mutta haluaisin bridgettää kaikki 4 kpl LAN-portteja yhdeksi bridgeksi, ja tässä bridgessä olisi 4 kpl VLANeja. Untagattynä kulkisi "perusverkko",
Kuten tuossa jo mainittiin, niin suorituskykymielessä tuosta ei ehkä ole hyötyä, sillä pfSense joutuu liikuttamaan paketteja liikaa softalla vs dedikoitu hallittava kytkin
 

jad

Liittynyt
22.10.2016
Viestejä
1 205
Selvisikö? Mikä arvo sulla on rp_filterissä? sysctl -a | grep rp_filter
rp_filter on kaikissa interfaceissa nolla.

Ongelma sekä selvisi, että ei selvinnyt :)

wan3.network:
Koodi:
[Match]
Name=wan3

[Network]
DHCP=ipv4

[DHCP]
RouteTable=130

[RoutingPolicyRule]
OutgoingInterface=wan3
Table=130
Tämä johtaa tälläiseen lopputulokseen (wan0 ei ole RouteTable määritystä lainkaan):
$ ip route
Koodi:
default via xx.xx.91.1 dev wan0 proto dhcp src xx.xx.91.10 metric 1024
xx.xx.91.0/24 dev wan0 proto kernel scope link src xx.xx.91.10 metric 1024
xx.xx.91.1 dev wan0 proto dhcp scope link src xx.xx.91.10 metric 1024
$ ip route show table 130
Koodi:
default via xx.xx.91.1 dev wan3 proto dhcp src xx.xx.91.84 metric 1024
xx.xx.91.0/24 dev wan3 proto dhcp scope link src xx.xx.91.84 metric 1024
xx.xx.91.1 dev wan3 proto dhcp scope link src xx.xx.91.84 metric 1024
$ ip rule
Koodi:
0:      from all lookup local
5000:   from yy.yy.0.0/20 to yy.yy.0.0/20 lookup 5000 proto static
32757:  from all oif wan3 lookup 130 proto static
32761:  from yy.yy.3.0/24 iif lan3 lookup 130 proto static
32766:  from all lookup main
32767:  from all lookup default
Tässähän käy niin, että Elisa tarjoilee liki peräkkäisiä ip-osoitteita kaikille wan interfaceille ja jokaisessa on sama gateway.

Tällä setupilla pingatessa ulkoa päin wan3 ip:tä xx.xx.91.84, vastaukset lähtee wan0:sta, mutta wan3:n ip:llä.

Kun lisään käsin rulen wan3:n ip-osoitteella:
ip rule add from xx.xx.91.84 table 130
Alkaa paketit kulkemaan oikein wan3:n kautta.

Ongelma on se, että en keksinyt yksinkertaista keinoa jolla saisi tuon ip rulen lisättyä siinä vaiheessa kun Elisan DHCP tarjoilee leasen.
Toki voin ottaa käyttöön networkd-dispatcher:n ja kirjoitella scriptin joka rulen tekee aina kun lease saadaan, mutta siitä joutuu tekemään ikävän monimutkaisen jos huomioi sen, että ip-osoite voi myös vaihtua lennosta. Tosin Elisa kyllä pääsääntöisesti tarjoaa aina saman ip:n leasen uudistuksessa, mutta jos esim. gfast silta on tunnin pari virrattomana ja itse gateway on tämän ajan käynnissä, niin osoitteet todennäköisesti vaihtuvat ja vanha ip rule pitäisi siivota pois uuden alta.

Edit: rulen lisäämisen jälkeen:
$ ip rule
Koodi:
0:      from all lookup local
4999:   from xx.xx.91.84 lookup 130
5000:   from yy.yy.0.0/20 to yy.yy.0.0/20 lookup 5000 proto static
...
 
Liittynyt
17.10.2016
Viestejä
28
Kaikkeni koetin, mutta en vaan saa toimimaan. Tuo linkin setup kyllä onnistuu, siinä on yhdessä bridgessä yksi VLAN. Vastaavan saan siis toimimaan, mutta haluaisin bridgettää kaikki 4 kpl LAN-portteja yhdeksi bridgeksi, ja tässä bridgessä olisi 4 kpl VLANeja. Untagattynä kulkisi "perusverkko", jonka tarvisi olla saatavilla heti seuraavissa vehkeissä (WIFI-tukari, 3 kpl managed-kytkimiä). Sen voisi ehkä ajatella niin, että minulla on neljäkerroksinen talo, ja kellarikerroksessa on tuo pfSense. Kaikki toimii hienosti jos kellarikerroksessa on pfSensen perässä yksi managed-kytkin. Jos poistan tuon managed-kytkimen välistä, kytkeytyisi jokainen kerros omaan fyysiseen porttiinsa pfSensessä (bridge). Kaikille kerroksille täytyisi juosta samat VLANit. Kytkimet eivät ole kytkettyjä toisiinsa muuta kuin tuon pfSensen kautta.

Konffeja tai screenshotteja konffista voin kyllä jakaa, ja oikeastaan mitä vaan pystyn testaamaan. Täytyy vaan vähän valita aikaa, kun kooman seurauksena koko perhe on ilman internettiä sen aikaa kunnes saan palautettua edellisen version :)
Yhdellä bridgellä tuo ei onnistu, mutta suorituskykyperspektiivistä sillä ei ole mitään merkitystä. Koska bridget ovat ns. softakytkimiä, tai tässä kontekstissa kytkinportteja, paketit pyöräytetään aina CPU:n kautta. Tässä pseudokonfia millä tuo onnistuu:

Fyysiset interfacet:
- eth0
- eth1
- eth2
- eth3

VLAN-interfacet:
- eth0-vlan10
- eth0-vlan11
- eth0-vlan12
- eth0-vlan13

- eth1-vlan10
... jne, kaikille vlaneille minkä liikennettä portista liikutellaan.

Bridget:
- br-mgmt (tägäämätön liikenne tukareille yms.)
- br-vlan10
- br-vlan11
... jne.

br-mgmt:ssä sillataan eth0-3, jolloin "perusverkko" toimii suoraan tägäämättömille paketeille
br-vlan10 sillataan eth0-vlan10, eth1-vlan10... Jos haluat jonkin interfaceista juttelemaan vlan10 L2 verkkoon ilman tägejä, voit lisätä sen tähän bridgeen suoraan, vaikkapa eth3.


Jos haluaa enemmän kytkinmäisen konfiguraation niin bridget voi vaihtaa openvswitchiin. Pitäisi olla FreeBSD:llä tuettu, en tiedä saako pfSenseen kuinka helposti asennettua ja onko hallintakälissä tukea sille.
 
Viimeksi muokattu:
Liittynyt
17.10.2016
Viestejä
28
rp_filter on kaikissa interfaceissa nolla.

Ongelma sekä selvisi, että ei selvinnyt :)

wan3.network:
Koodi:
[Match]
Name=wan3

[Network]
DHCP=ipv4

[DHCP]
RouteTable=130

[RoutingPolicyRule]
OutgoingInterface=wan3
Table=130
Tämä johtaa tälläiseen lopputulokseen (wan0 ei ole RouteTable määritystä lainkaan):
$ ip route
Koodi:
default via xx.xx.91.1 dev wan0 proto dhcp src xx.xx.91.10 metric 1024
xx.xx.91.0/24 dev wan0 proto kernel scope link src xx.xx.91.10 metric 1024
xx.xx.91.1 dev wan0 proto dhcp scope link src xx.xx.91.10 metric 1024
$ ip route show table 130
Koodi:
default via xx.xx.91.1 dev wan3 proto dhcp src xx.xx.91.84 metric 1024
xx.xx.91.0/24 dev wan3 proto dhcp scope link src xx.xx.91.84 metric 1024
xx.xx.91.1 dev wan3 proto dhcp scope link src xx.xx.91.84 metric 1024
$ ip rule
Koodi:
0:      from all lookup local
5000:   from yy.yy.0.0/20 to yy.yy.0.0/20 lookup 5000 proto static
32757:  from all oif wan3 lookup 130 proto static
32761:  from yy.yy.3.0/24 iif lan3 lookup 130 proto static
32766:  from all lookup main
32767:  from all lookup default
Tässähän käy niin, että Elisa tarjoilee liki peräkkäisiä ip-osoitteita kaikille wan interfaceille ja jokaisessa on sama gateway.

Tällä setupilla pingatessa ulkoa päin wan3 ip:tä xx.xx.91.84, vastaukset lähtee wan0:sta, mutta wan3:n ip:llä.

Kun lisään käsin rulen wan3:n ip-osoitteella:
ip rule add from xx.xx.91.84 table 130
Alkaa paketit kulkemaan oikein wan3:n kautta.

Ongelma on se, että en keksinyt yksinkertaista keinoa jolla saisi tuon ip rulen lisättyä siinä vaiheessa kun Elisan DHCP tarjoilee leasen.
Toki voin ottaa käyttöön networkd-dispatcher:n ja kirjoitella scriptin joka rulen tekee aina kun lease saadaan, mutta siitä joutuu tekemään ikävän monimutkaisen jos huomioi sen, että ip-osoite voi myös vaihtua lennosta. Tosin Elisa kyllä pääsääntöisesti tarjoaa aina saman ip:n leasen uudistuksessa, mutta jos esim. gfast silta on tunnin pari virrattomana ja itse gateway on tämän ajan käynnissä, niin osoitteet todennäköisesti vaihtuvat ja vanha ip rule pitäisi siivota pois uuden alta.

Edit: rulen lisäämisen jälkeen:
$ ip rule
Koodi:
0:      from all lookup local
4999:   from xx.xx.91.84 lookup 130
5000:   from yy.yy.0.0/20 to yy.yy.0.0/20 lookup 5000 proto static
...
Jeps, tuo vaatii tosiaan Routing Policyn. Dynaamisten IP:eiden tapauksessa tämän voi hoitaa lisäämällä ip-/nftablesiin säännön, joka lisää fwmarkin paketteihin jotka saapuvat wan-interfaceihin sekä [RoutingPolicyRule] -kentän networkd:n konfiin, joka sitten markin perusteella leipoo paluupaketit menemään oikeaan tauluun takaisin lähettäessä. En ole itse nähnyt tarvetta tälle, koska reititin ei palvele VPN:n lisäksi ulospäin mitään ja VPN yhdistetään aina "pää" interfaceen joka reititetään local-taulussa.

Eli jotain tähän suuntaan:

wan3.network:
Koodi:
[RoutingPolicyRule]
FirewallMark=130
Table=130
nftables
Koodi:
nft add rule ip mangle PREROUTING iifname wan3 meta mark set 130
nft add rule ip mangle PREROUTING meta mark set ct mark
 
Viimeksi muokattu:
Liittynyt
23.10.2016
Viestejä
483
Okei. Kiitos. Taidanpa jättää tämän hautumaan, ja kokeilla uudestaan joskus tulevaisuudessa kun on taas motivaatiota.
Tällä hetkellä kaikki toimii hienosti, ja juuri managed-kytkimen läpi. Kytkin on 1 GBit/s, joten ehkä pienen nopeushyödyn voisi saada jos sen tiputtaisi pois ja ajaisi pfSense-purkin 2.5 GBit/s -porteilla. Vaikkakin paketit menevät CPU:n kautta.
 
Liittynyt
17.10.2016
Viestejä
28
Okei. Kiitos. Taidanpa jättää tämän hautumaan, ja kokeilla uudestaan joskus tulevaisuudessa kun on taas motivaatiota.
Tällä hetkellä kaikki toimii hienosti, ja juuri managed-kytkimen läpi. Kytkin on 1 GBit/s, joten ehkä pienen nopeushyödyn voisi saada jos sen tiputtaisi pois ja ajaisi pfSense-purkin 2.5 GBit/s -porteilla. Vaikkakin paketit menevät CPU:n kautta.
Mikä tahansa nykypäivän rauta jaksaa jyrsiä tuon 2.5Gbps jos liikenne on suodattamatonta L2-liikennettä, onnistuu vaikka Raspilla. Pullonkaulaa alkaa muodostua vasta monimutkaisilla muurisääntöseteillä ja silloinkin vain isommilla nopeuksilla ja tilattomilla muureilla. Perus setupeissa on aina käytössä tilallinen hallinta yhteyksille (established, related) jolloin auki olevien yhteyksien liikenne menee ns. ohituskaistaa pitkin pihalle eikä käy koko muurisäännöstöä läpi.
 

jad

Liittynyt
22.10.2016
Viestejä
1 205
Jeps, tuo vaatii tosiaan Routing Policyn. Dynaamisten IP:eiden tapauksessa tämän voi hoitaa lisäämällä ip-/nftablesiin säännön, joka lisää fwmarkin paketteihin jotka saapuvat wan-interfaceihin sekä [RoutingPolicyRule] -kentän networkd:n konfiin, joka sitten markin perusteella leipoo paluupaketit menemään oikeaan tauluun takaisin lähettäessä. En ole itse nähnyt tarvetta tälle, koska reititin ei palvele VPN:n lisäksi ulospäin mitään ja VPN yhdistetään aina "pää" interfaceen joka reititetään local-taulussa.
Itseasiassa tuota fwmarkia jo aiemmin pikaisesti testasin, mutta näin iptablesiin tottuneena en onnistunut arpomaan oikeita loitsuja nftableille. Nyt kun tuon nftablesin kanssa on ehtinyt vähän temuta, niin alkaa jo olemaan parempi ymmärrys ja onhan tuo loppupeleissä melkoinen edistysaskel perinteiseen iptables hässäkkän, jolla nykyisen palomuuri/gateway koneen olen conffinut.
En minäkään ole vielä lainkaan varma siitä, onko tälle ikinä mitään tarvetta, mutta onpahan toiminnassa jos jotain tarvetta keksin. Sen verran tapoihini jumittunut kuitenkin olen, että en kovin mielelläni palomuurikoneeseen mitään ylimääriäisiä palveluita asentele.

Kiitos taas kun tuuppasit oikeaan suuntaan, lopulta näin se lähti toimimaan:
Koodi:
nft add table ip mangle
nft 'add chain ip mangle input { type filter hook input priority 0; }'
nft 'add chain ip mangle output { type route hook output priority 0; }'
nft add rule ip mangle input iifname wan3 ct mark set 130
nft add rule ip mangle output meta mark set ct mark
$ nft list table mangle
Koodi:
table ip mangle {
        chain input {
                type filter hook input priority filter; policy accept;
                iifname "wan3" ct mark set 0x00000082
        }

        chain output {
                type route hook output priority filter; policy accept;
                meta mark set ct mark
        }
}
Huomionarvoista tässä on se, että set ct mark pitää pistää route- ketjuun output hookila, prerouting filter oli väärä paikka tälle. wan3 markin olisi voinut laittaa myös prerouting filtteriin, mutta päädyin nyt käyttämään inputtia.
 

user9999

Platinum-jäsen
Liittynyt
17.10.2016
Viestejä
2 986
Tuli hommattua kiinalainen pommi HUNSN RJ35. :D



1695504759184.png

1695504772073.png

Prosessori: Intel i3-N305 eli Alder Lake-N sarjaa ja kaikki E-ytimiä.
Muisti: Crucial RAM 8GB DDR5 4800MHz (CT8G48C40S5)

Levy: Crucial P3 500GB M.2 PCIe Gen3 NVMe
Verkkokortit: 4 x 2.5GbE I226-V

Paketin virrankulutus on noin 12W idlessä kun kaksi verkkokorttia käytössä. Kaikki bios jutut on oletuksena ja täytyy katsoa vielä mitä säätöjä on prosessoriin. Lämmöt näyttää pysyvän hyvällä tasolla vaikka on fanless.
 
Viimeksi muokattu:
Liittynyt
24.12.2016
Viestejä
573
Mikä tahansa nykypäivän rauta jaksaa jyrsiä tuon 2.5Gbps jos liikenne on suodattamatonta L2-liikennettä, onnistuu vaikka Raspilla. Pullonkaulaa alkaa muodostua vasta monimutkaisilla muurisääntöseteillä ja silloinkin vain isommilla nopeuksilla ja tilattomilla muureilla. Perus setupeissa on aina käytössä tilallinen hallinta yhteyksille (established, related) jolloin auki olevien yhteyksien liikenne menee ns. ohituskaistaa pitkin pihalle eikä käy koko muurisäännöstöä läpi.
Eikö tuo kuitenkin ole jo L3, kun eri vlan välillä reititetään ja luultavasti niistä verkoista on tarkoitus päästä myös ulkoverkkoon? Tuohon Khauronin asiaan viitaten.
 
Liittynyt
19.10.2016
Viestejä
1 678
No nyt on halpaa pfSense-rautaa :)




(Postikulut Suomeen 9,90€)
Laitoin yhden tilaukseen. Katsotaan tuleeko ikinä ja miten giganen saturoi tuon. Mutta tulisi ensisijaisesti varaboksiksi odottamaan varsinaisen raudan lahoa, siihen passaa oikein hyvin.
 

escalibur

"Random Tech Channel" @ YouTube
Liittynyt
17.10.2016
Viestejä
9 032
Laitoin yhden tilaukseen. Katsotaan tuleeko ikinä ja miten giganen saturoi tuon. Mutta tulisi ensisijaisesti varaboksiksi odottamaan varsinaisen raudan lahoa, siihen passaa oikein hyvin.
Muista vaan hommata toisen verkkokortin ja PCI-E riserin tuohon. Tuo voi olla varsin pätevä laite juurikin varalaitteena tms.
 
Liittynyt
19.10.2016
Viestejä
5 777
No nyt on halpaa pfSense-rautaa :)


(Postikulut Suomeen 9,90€)
Taisi mennä nopeasti: "You cannot place an order, because we have insufficient number of products you are trying to order."
 
Liittynyt
19.10.2016
Viestejä
1 678

Vähän kalliimpaa löytyy vielä.
 

escalibur

"Random Tech Channel" @ YouTube
Liittynyt
17.10.2016
Viestejä
9 032
Liittynyt
17.10.2016
Viestejä
487
Sophokselta v20 EAP, jossa pitäisi olla IPv6 DHCP-PD.
 

AkQ

Liittynyt
13.12.2016
Viestejä
249
No nyt on halpaa pfSense-rautaa :)




(Postikulut Suomeen 9,90€)
tarkoitat varmastikkin OPNsense? vai onko sulla jokin muu syy pelkästään, vain ja ainoastaan pfsense-hehkutukselle? ;)
 

escalibur

"Random Tech Channel" @ YouTube
Liittynyt
17.10.2016
Viestejä
9 032
tarkoitat varmastikkin OPNsense? vai onko sulla jokin muu syy pelkästään, vain ja ainoastaan pfsense-hehkutukselle? ;)
Ainakaan toistaiseksi mulla ei ole minkälaista kokemusta OPNsensestä. Tämän vuoksi itse keskityn pfSenseen.
 
Liittynyt
28.03.2017
Viestejä
1 496
Aika vähän duunissa maastossa OPNsenseä on näkynyt, pfSenseä lähinnä jos ei ole Ciscoa infrat ollut alusta loppuun. Tuon takia itsekin kotona päätin aikoinaan valita pfSensen, saa kokemusta ja jippoja jos osuu tuulettimeen työpaikoilla.

Homelab harrastajille OPNsense varmaan se fiksuin ja loogisin vaihtoehto, itsekin siihen todennäköisesti päätyisin tällä hetkellä, jos lähtisin puhtaalta pöydältä kotiverkkoa kasaamaan. Turha pfSensen valinneita silti on alkaa sormella osoittamaan, toimiva ja vakaa muurikäyttis sekin vaikka ylläpitävä firma onkin ollut mulkun maineessa.
 
Liittynyt
15.10.2022
Viestejä
625
Pyydän hiukan apua, koska näin syvällä muuriasioissa ei ole tullut vielä oltua.

Oma vaatimukseni reitittimeltä / muurilta on 10gb valmiudet tulevaisuutta varten, 3 wanin käyttö kuitu/RJ45 pitkin, 2 näistä kuormanjaolla ja kolmas varayhteytenä molempien pääyhteyksien pettäessä. NextDNS käytössä, tällä hetkellä käyttäen DNS-over-HTTPS, tavalla tai toisella siis NextDNS saatava toimimaan (kaikki sisäverkon DNS-kyselyt pakotetusti NextDNS:lle). Noiden lisäksi normaalit kuviot, 4 VLAN:a, jokaiselle oma SSID:nsä. Suorituskyky tietenkin oltava kunnossa. Verkon sisällä pitää mDNS toimia, esimerkkinä vaikkapa tulostin tai Android TV joiden haku verkosta perustuu mDNS:n.

Nyt setup toteutettuna TP-Linkin Omada -sarjan kamoilla, rauta erittäin hyvää mutta softa kuraa ja perusasiat täysin hukassa. Esimerkkinä IPv6 palomuuria ei reitittimessä ole ollenkaan, vaan päästää oletuksena kaiken liikenteen läpi?!. Tykkäisin ajatuksesta, että kaikki olisi jatkossakin keskitetysti hallinnassa, ja Ubiquitin Unifi toki vastaisi valtaosaan näistä huudoista. Siinä tosin vain Dual-WAN -tuki tällä hetkellä, mutta muuten homman saisi toimimaan. Tiedän, että ominaisuuksiltaan ei puhuta edes samalla hehtaarilla olevista tuotteista, mutta toisaalta mikä lisäarvo omiin vaatimuksiini nähden sitten xxSensestä minulle olisi?

PfSense / OPNsense voisi sinällään kiinnostaa, jo ihan osaamisenkin syventämisen näkökulmasta. Kytkimet ja tukiasemat voisin pitää kunnollisen reitittävän muurin kaverina vaikka sitten Omada-taustaisina, tai miksei sitten ne vaikka erikseen Ubiquitilta kuten monet tekevät.
 
Liittynyt
22.10.2016
Viestejä
6 946
@Enhancer, Ei kyllä kannata laittaa useampaa tonnia reitittimeen vaan siksi että se mahdollisesti tulevaisuudessa tulevan 10G netin pystyy hanskaamaan. 10G vaatii jo oikeasti aika järeää rautaa, eikä mikään kuluttajalaite tuohon kykene, vaikka 10G kykenevä sfp portti voikin olla.

Jos nuo omada tukarit on sulle ok, niin käytä niitä ja laita jokin tulevampi xxxSense reititin. Moneen omadaan saa myös openwrt:n sisään joka mahdollistaa orkkisfirmistä laajemmat säädöt.
 
Liittynyt
15.10.2022
Viestejä
625
@Enhancer, Ei kyllä kannata laittaa useampaa tonnia reitittimeen vaan siksi että se mahdollisesti tulevaisuudessa tulevan 10G netin pystyy hanskaamaan. 10G vaatii jo oikeasti aika järeää rautaa, eikä mikään kuluttajalaite tuohon kykene, vaikka 10G kykenevä sfp portti voikin olla.

Jos nuo omada tukarit on sulle ok, niin käytä niitä ja laita jokin tulevampi xxxSense reititin. Moneen omadaan saa myös openwrt:n sisään joka mahdollistaa orkkisfirmistä laajemmat säädöt.
Tonneja ei. Netgate 6100 katsoin noin esimerkiksi. Konkretisoikaa, mikä käyttökelpoinen ominaisuus xSensestä löytyy, mitä Ubiquitin reitittimistä ei löydy?
 
Liittynyt
28.03.2017
Viestejä
1 496
Ubiquiti tekee hyviä kytkimiä ja tukareita joita itselläkin on käytössä, mutta muuria/reititintä en sieltä ottaisi.

 
Liittynyt
24.12.2016
Viestejä
573
Tonneja ei. Netgate 6100 katsoin noin esimerkiksi. Konkretisoikaa, mikä käyttökelpoinen ominaisuus xSensestä löytyy, mitä Ubiquitin reitittimistä ei löydy?
Xsenseä voi ajaa omalla raudalla ja mahdollisuus asentaa tarvitsemiaan lisäosia. Itsellä käytössä muistaakseni mini-itx kone, jossa 2x1G verkkokortti, tulevaisuudessa voi vaihtaa 10G, mikäli tarvetta ilmenee. Varmuuskopiointi ja palautus on myös kätevä ja toiselle raudalle siirtokin onnistui, kun määritteli interface/vlan asetukset kohdalleen.
 
Liittynyt
15.10.2022
Viestejä
625
Ubiquiti tekee hyviä kytkimiä ja tukareita joita itselläkin on käytössä, mutta muuria/reititintä en sieltä ottaisi.

Tämä on yleinen, monessakin paikassa vastaan tuleva mielipide, kiitos siitä. :)

Yritän hahmottaa, että mitä menetän, koska Ubiquitissa saa saman kuin Omadassakin. Vaivattomuutta, keskitetyn hallinnan jne. En nyt muista ulkoa olenko juuri tuon pätkän katsonut, mutta ainakin vastaavia.
Edit: 2 vuotta vanha video, aika isoja päivityksiä ja uutta rautaakin tullut tuon jälkeen.
 
Liittynyt
26.02.2019
Viestejä
2 429
Ubiquiti tekee hyviä kytkimiä ja tukareita joita itselläkin on käytössä, mutta muuria/reititintä en sieltä ottaisi.

Olisiko laiskalle muutama nosto videosta, että miksi ei toimi esim. palomuurina? Just nyt ei jaksa katsoa tuota videota, että miksi se on huono. Ei sillä, että itse tuota edes harkitsisin, mutta ihan yleisestä mielenkiinnosta.
 
Liittynyt
22.10.2016
Viestejä
6 946
Tämä on yleinen, monessakin paikassa vastaan tuleva mielipide, kiitos siitä. :)

Yritän hahmottaa, että mitä menetän, koska Ubiquitissa saa saman kuin Omadassakin. Vaivattomuutta, keskitetyn hallinnan jne. En nyt muista ulkoa olenko juuri tuon pätkän katsonut, mutta ainakin vastaavia.
Edit: 2 vuotta vanha video, aika isoja päivityksiä ja uutta rautaakin tullut tuon jälkeen.
Tottakai voit hommata ubiquitin tai omadan reitittimen, ja jos olet jo sen kanssa sinut, niin ihan suositeltava vaihtoehto.

Tosin 10G liittymään kykenevää laitetta ei kumpikaan taida valmistaa, mutta ei mun mielestä muutenkaan raudan hankkiminem jonkun tulevaisuuden tarpeen perusteella ole kovin järkevää, vaan kanmattaa hankkia se vastaava rauta silloin tulevaisuudessa, kun se on halvempaa ja hiotumpaa.
 
Liittynyt
14.12.2016
Viestejä
163
Lounea lupailee sitä 40gbps nettiä tälle vuodelle.
Osaakos kukaan arvailla millasta rautaa tommosta varten pitäs routeriks olla?
 
Liittynyt
17.10.2016
Viestejä
487
Lounea lupailee sitä 40gbps nettiä tälle vuodelle.
Osaakos kukaan arvailla millasta rautaa tommosta varten pitäs routeriks olla?

Näköjään PCI-e 3.0 ja 8x paikka riittää dual-kortille. Saako tuosta läpi 40Gbit/sec niin se lienee eri juttu.
 
Liittynyt
14.12.2016
Viestejä
163

Näköjään PCI-e 3.0 ja 8x paikka riittää dual-kortille. Saako tuosta läpi 40Gbit/sec niin se lienee eri juttu.
itseäni mietityttää mikä se rajapinta asiakkaan suuntaan on tuossa liittymässä... mulla on noita qsfp28 moduleita.
 
Liittynyt
01.02.2019
Viestejä
361

Näköjään PCI-e 3.0 ja 8x paikka riittää dual-kortille. Saako tuosta läpi 40Gbit/sec niin se lienee eri juttu.
PCI-e 3.0 ja 8x taitaa meinata 64 Gb/s, eli pahasti jää vajaaksi 40G jos se pitäisi saada kahteen suuntaan ja kahteen piuhaan. Jos se 40G pitää ihan oikeasti saada läpi, niin joku tällainen pääsee jo lähelle: CCR2216-1G-12XS-2XQ. Tämän ketjun kannalta mielenkiintoisempi tuote voisi olla CCR2004-1G-2XS-PCIe jossa kortille on laitettu 2 x 25G SFP28 porttia ja arm-siru, mutta joku pullonkaula tuossakin on kun mittaustulokset ovat noin "huonot".
 
Liittynyt
24.12.2016
Viestejä
573
Tuossa on nopeampi väylä käytössä, PCI-e 4.0x16, pitäisi riittää 40G käyttöön ja ehkä nopeammallekin. Kommenteissä näytti joku sanovan, että toimii FreeBsd:n kanssa "

Models :2x 100G QSFP28, PCIe 4.0 x 16
Works as expected, provides good throughput, and drivers worked with FreeBSD out of the box.
"
Ei jää netin nopeus palomuuri valinnan takia vajaaksi, Pfsensen kanssa tulevaisuus turvattu :)
 
Liittynyt
15.10.2022
Viestejä
625
Dedikoitu rauta on toki aina parempi, mutta onko kenelläkään kokemusta virtuaalikoneessa sensen pyörittämisestä?

Tajusin juuri, että M1 -prossuinen Mac Mini tuli hommattua Amazonista kun halvalla sai, ja siihen tarkoitus laittaa joka tapauksessa pyörimään pilvipalveluiden varmuuskopioinnit ja Home Assistant virtuaalikoneeseen.

Thunderbolt 4 (40Gbps) -portteja on 2, joiden perään saa tarvittaessa tietysti vaikka ulkoista väylää, mutta joka tapauksessa dongleilla X-määrän verkkoportteja aina 10Gbps tasolle asti. Tuoko nuo donglet latenssia tai jotain muuta muuttujaa liikaa?
 
Liittynyt
17.10.2016
Viestejä
487
Dedikoitu rauta on toki aina parempi, mutta onko kenelläkään kokemusta virtuaalikoneessa sensen pyörittämisestä?
Hyper-Vssä pyörii. 10 Gbit virtuaaliset verkkokortit ja ulospäin giganen portti. Bootti halttas uusimmalla versiolla, mutta sitten lähti toimimaan, kun uhkasi heittää Vmwaren kehiin.
 
Liittynyt
15.10.2022
Viestejä
625
Hyper-Vssä pyörii. 10 Gbit virtuaaliset verkkokortit ja ulospäin giganen portti. Bootti halttas uusimmalla versiolla, mutta sitten lähti toimimaan, kun uhkasi heittää Vmwaren kehiin.
Eipä tuossa kokeilemalla korkealta putoa. Taidan aloittaa sillä, että laitan tuohon masiinaan vain yhden Thunderbolt -> 10GbE donglen, ja otan WAN:t kytkimiltä omia VLAN pitkin. En ole koskaan aiemmin tuota noin toteuttanut, vaan aina tuonut WAN:t reitittimen korvamerkittyihin portteihin. Ei ideaali, mutta riittää toistaiseksi mainiosti kun sisäverkossakaan harvoin yli 3-4Gbps nopeuksille on tarvetta.
 
Liittynyt
19.10.2016
Viestejä
1 678
No nyt on halpaa pfSense-rautaa :)




(Postikulut Suomeen 9,90€)
Tämä kone saapui eilen, emolevyllä mini PCIe-liitin, johon pitäisi adapteri löytää. Näyttäisivät kaikki vaativan 12V lisävirtaa siellä varsinaisen PCIe-liittimen päässä, sitä on hintsusti emolla tarjota. Mutta eiköhän tuon saa toimimaan, löysin emolle hyvän manuaalin, jossa selvitys kaikista liittimistä ja mahdollisista virranottopaikoista.
 
Liittynyt
17.10.2016
Viestejä
336
Tilasin Toptonin N100 purkin, ihan asiallisen olonen laite. Aika paljon lämpeni sinä aikana kun ArchLinuxin asensin, pitää varmaan tarkistaa että kaikki virransäästöasetukset on jiirissä. Vielä kunnolla kalibroimaton virrankulutusmittari sanoi että 10W idlenä.

Sitten vaan opettelmaan networkd:n ja nftablesin konffausta.
 
Toggle Sidebar

Uusimmat viestit

Statistiikka

Viestiketjut
233 577
Viestejä
4 108 584
Jäsenet
69 789
Uusin jäsen
piqulee

Hinta.fi

Ylös Bottom