Hálózatok egyéb

Tisztelt kollégák!

Egyszerűen nem jövök rá mit rontok el. Adott egy DELL R250 szerver, benne egy X540-AT2 Intel 2x 10GbE hálózati vezérlővel. Debian 13 Trixie alap, Proxmox 9, naprakész csomagok. Ezt szeretném egy ZyXel XGS1930 switch-el LACP-vel összekapcsolni. Az SFP modulok gyári ZyXel-ek, jó drágák, nem utángyártott 3rd-party alkatrész. A konfiguráció a Debian oldalán a következő (teljesen alap, ahogy a nagy könyvben meg van írva):

auto bond0
iface bond0 inet manual
       bond-slaves ens1f0 ens1f1
       bond-miimon 100
       bond-mode 802.3ad
       bond-xmit-hash-policy layer2+3

auto vmbr0
iface vmbr0 inet manual
       bridge-ports bond0
       bridge-stp off
       bridge-fd 0
       bridge-vlan-aware yes
       bridge-vids 5 24 100 711 712 721 722 723 724

auto vmbr0.24
iface vmbr0.24 inet static
       address 192.168.24.111/24
       gateway 192.168.24.254

auto vmbr0.100
iface vmbr0.100 inet static
       address 172.20.72.232/24

A switch oldalán LAG group létrehozva, portok hozzárendelve, az egyes portokon ugyanazok a VLAN-ok engedélyezve. LACP engedélyezve. Itt ezekből lehet választani: src-mac, dst-mac, src-dst-mac, src-ip, dst-ip, src-dst-ip (most src-dst-mac értéken van). Próbáltam a Linux oldalán layer2 és layer3+4 hash policy-val is, de nem jártam sikerrel.

A link nem áll össze. ha magára hagyom legalább 10-15 percet, egyszer csak "féllábon" összeáll. A Debian oldalán azt mondja mindkettő link UP, de a switch az egyik portra azt írja ilyenkor hogy DOWN, és a "Synchronized Ports" is csak a másikat tartalmazza. Ekkor így néznek ki a dolgok:

ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host noprefixroute 
      valid_lft forever preferred_lft forever
4: ens1f0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000
   link/ether b4:96:91:1a:a2:ec brd ff:ff:ff:ff:ff:ff
   altname enp1s0f0
   altname enxb496911aa2ec
5: ens1f1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP group default qlen 1000
   link/ether b4:96:91:1a:a2:ec brd ff:ff:ff:ff:ff:ff permaddr b4:96:91:1a:a2:ee
   altname enp1s0f1
   altname enxb496911aa2ee
6: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
   link/ether b4:96:91:1a:a2:ec brd ff:ff:ff:ff:ff:ff
7: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
   link/ether b4:96:91:1a:a2:ec brd ff:ff:ff:ff:ff:ff
   inet6 fe80::b696:91ff:fe1a:a2ec/64 scope link proto kernel_ll 
      valid_lft forever preferred_lft forever
8: vmbr0.24@vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
   link/ether b4:96:91:1a:a2:ec brd ff:ff:ff:ff:ff:ff
   inet 192.168.24.111/24 scope global vmbr0.24
      valid_lft forever preferred_lft forever
   inet6 fe80::b696:91ff:fe1a:a2ec/64 scope link proto kernel_ll 
      valid_lft forever preferred_lft forever
9: vmbr0.100@vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
   link/ether b4:96:91:1a:a2:ec brd ff:ff:ff:ff:ff:ff
   inet 172.20.72.232/24 scope global vmbr0.100
      valid_lft forever preferred_lft forever
   inet6 fe80::b696:91ff:fe1a:a2ec/64 scope link proto kernel_ll 
      valid_lft forever preferred_lft forever
11: tap100i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc fq_codel master vmbr0 state UNKNOWN group default qlen 1000
   link/ether b6:d6:be:23:c2:93 brd ff:ff:ff:ff:ff:ff

cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v6.14.11-4-pve
Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2+3 (2)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Peer Notification Delay (ms): 0
802.3ad info
LACP active: on
LACP rate: slow
Min links: 0
Aggregator selection policy (ad_select): stable
System priority: 65535
System MAC address: b4:96:91:1a:a2:ec
Active Aggregator Info:
       Aggregator ID: 1
       Number of ports: 1
       Actor Key: 15
       Partner Key: 2
       Partner Mac Address: d8:ec:e5:a0:06:ad
Slave Interface: ens1f0
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 4
Permanent HW addr: b4:96:91:1a:a2:ec
Slave queue ID: 0
Aggregator ID: 1
Actor Churn State: none
Partner Churn State: none
Actor Churned Count: 0
Partner Churned Count: 4
details actor lacp pdu:
   system priority: 65535
   system mac address: b4:96:91:1a:a2:ec
   port key: 15
   port priority: 255
   port number: 1
   port state: 61
details partner lacp pdu:
   system priority: 32768
   system mac address: d8:ec:e5:a0:06:ad
   oper key: 2
   port priority: 1
   port number: 27
   port state: 63
Slave Interface: ens1f1
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 22
Permanent HW addr: b4:96:91:1a:a2:ee
Slave queue ID: 0
Aggregator ID: 2
Actor Churn State: monitoring
Partner Churn State: monitoring
Actor Churned Count: 22
Partner Churned Count: 22
details actor lacp pdu:
   system priority: 65535
   system mac address: b4:96:91:1a:a2:ec
   port key: 15
   port priority: 255
   port number: 2
   port state: 69
details partner lacp pdu:
   system priority: 65535
   system mac address: 00:00:00:00:00:00
   oper key: 1
   port priority: 255
   port number: 1
   port state: 1

A switch-en a "System Priority" értéke 32768, ezt látom eltérésnek, ez okozhat gondot?

Mit rontok el? Köszönöm az útmutatást előre is!

Most próbáltam belépni a Teams-be. Aszongya a Firefox:

Did Not Connect: Potential Security Issue
...
Error code: SEC_ERROR_INVALID_TIME

Vicces a dologban, hogy az OutLook-ba ba ugyanonnan, vagyis az office.com-ról indulva be tudok lépni. Meg a SharePoint-ba is.  :)

Merőben elméleti kérdés:

mondjuk van 1 doboz, több ilyenolyan vpn kapcsolattal, de nem akarom mindig mindet élőn tartani. viszont, ha jön egy adott kérés a dobozon keresztül, akkor 1-ik másikat fel kéne húzni mondjuk. Vagy valami egész hasonló feladat: valamilyen felbukkanó forgalom esetén csinálni valami dolgot.

Eleddig arra jutottam, hogy:

• logozom az adott forgalmat (iptables/nftables/pf),
• azt nézegetem valahogy,
• meglátom, csinálok, amit akarok.

Nem baj, ha OS agnosztikus a dolog, azért emlegetem a pf-t is.

Tudunk-e ennél civilizáltabb pl. protokollszintű/ netán általános (transproxy) megoldást? Mindezt lehetőleg gyorsan, közel 0 késleltetés mellett?

Üdv,

Létezik Magyarországon olyan cég/szakember, aki érthet a cloudflare-hez? Mert én nem találtam. Van egy cég akinek erre specifikált oldala van, de "házon belül egyeztettünk, és nem tudunk segíteni..". Nem értem minek hirdetik magukat akkor. Szóval a segítségeteket szeretném kérni, hogy találjak egy megfelelő szakembert, aki cloudflare beállításában profi. Több domain van, mindegyik PRO csomagban van.

Köszönöm!

Kedves Fórum!

Abba a fura helyzetbe kerültem, hogy a Bp közepén, a XI. kerületben nem tudok normális netre előfizetni, mert

- Az egyik szolgáltató (Telekom) épp húzza be az optikai netet, még nem rendelhető hónapokig

- A másik szolgáltató (One) meg úgy döntött, hogy hogy nincs elég infrastruktúrája a környéken, nem ad el újabb előfizetést.

Mobilnetet beállítottam, de nem nagyon meg 30 Mbps fölé. (4G-s külső modem.) Nekem vidéken

Nosza, gondoltam, akkor áthidaló megoldásként kipróbálom a Starlink-et. (Amikor meglesz a rendes net, majd leveszem, és használom máshol backup kapcsolatnak, az altatós, csak használat esetén fizetős konstrukcióban.) Meg is jött a kit. A tetőre nyomnám fel, van ott egy régi fém rúd, még abból a korból, amikor TV antennákat raktak a tetőre, arra pont fel lehetne fogatni.

A kérdés, hogy mit kezdjek a villámvédelemmel. Nagyjából a 3 emeletes épület legmagasabb pontján lennénk, szóval gondolom ezzel foglalkozni kell.

Ha jól értem, a hivatalos tanács az, hogy vihar esetén húzzam szét. Esetemben nem hiszem, hogy ez megbízhatóan működne... (mi van, ha nem vagyok a környéken sem pl.) Inkább valami fix megoldást szeretnék.

Elvileg egyetlen speckó PoE kábel megy fel a routertől az antennához, ahhoz kellene valami. De mi?

Amit látok (pl. https://www.amazon.de/-/en/Starlink-Lightning-Protection-IEEE802-3AT-PT… ) az eléggé aranyárban van.

Ki milyen megoldást javasolna erre?

Köszönettel

"Issues accessing Registry, Hub, Scout, DBC, DHI - We are seeing issues accessing and using our services across many of our products. See dockerstatus.com⁠ for updates."

https://www.dockerstatus.com/

Minden szolgáltatásuk "Full Service Disruption" állapotban van:

Incident Status: Full Service Disruption

Components: Docker Hub Registry, Docker Authentication, Docker Hub Web Services, Docker Billing, Docker Hub Automated Builds, Docker Hub Security Scanning, Docker Scout, Docker Build Cloud, Testcontainers Cloud, Docker Cloud, Docker Hardened Images

Locations: Docker Web Services

Pár napja téma, hogy hogyan helyezhetem el a kamerámat a saját értékeim megvédése céljából

Kettő példa jutott eszembe, ami nagyon is életszerű.

1- kutya is van a portán belül, amit kívülről bedobott méreggel megölnek. Van kamera és lebukik a tróger.

2- betörnek Bözsi nénihez, felvette az udvarra néző kamera, így le is bukott a betörő.

Van itt olyan személyiségi jog, ami a jogszabályok szerint sérült?

Sziasztok

Van egy PfSense tűzfalam, azon fut egy squid és squid guard. A Squid Guardal szeretném megoldani, hogy bizonyos ip-címeken tiltson weboldalakat, és ha valaki ezt megnyitja, akkor egy a tiltást közlő oldalra irányítsa át. A squid-ban be van kapcsolva a transparent mode és az SSL bump. Pfsens-en tanusítvány létre lett hozva, és a tanusítvány fent van az adott gépeken. Valamint a tiltás közlő oldal is ezt a tanusítványt használja.

Némelyik oldallal ez működik is, de a többségnél ERR_SSL_PROTOCOL_ERROR-t ír. pl. facebook.com, gmail.com stb. Van megoldás rá, hogy ezeknél az oldalaknál is megjelenjen a tiltást közlő oldal, és az Én beállításaimban van a hiba, vagy hiába kínlódok vele, szépen nem lehet megoldani, mert nem fogja engedni átirányítani magát?

Sziasztok!

Zentyal 7.0-t frissítettünk 7.1-re majd a 7.1-et 8.0-ra és felmerült némi kellemetlenség, hogy iszonyatosan lassú a webes felület.

A /var/log/zentyal/error.log, ami egy általa indított nginx annyit ír, hogy timeout-ra futott az Unix socket-en, amit proxy-zik.

A /var/log/zentyal/zentyal.log sok érdemit nem mond, miközben várakozik a kliens, semmi infó. Néha egy-egy alkalommal egy pillanat alatt bentvan az admin gui, de máskor hosszú másodpercekig vár, majd villanásra betölt, tehát nem az van, hogy lassan jön a response, ha egyszer megindul, akkor pörög. Ugyanez a cURL is, az is a head-ereket lehúzza, de aztán időtlen időkig vár a tartalomra, akár egy sima login oldalra is.

Amit eddig megnéztem és nem vezetett előrébb
 - Redis, firewall, DNS, samba-ad-dc kikapcsolása ideiglenesen, nem oldotta meg
- zs firewall, dns stop és start, nem segített
- DNS-bejegyzések átnézése, nem segített, elvileg jók, a nslookup és host is jól adja vissza a külső és belső címeket

A log időnként ezt írja ki, ha a DNS-t próbálja módosítani
2025/07/02 10:58:49 ERROR> GlobalImpl.pm:728 EBox::GlobalImpl::saveAllModules - The following modules failed while saving their changes, their state is unknown: dns  at The following modules failed while saving their changes, their state is unknown: dns  at /usr/share/perl5/EBox/GlobalImpl.pm line 728
EBox::GlobalImpl::saveAllModules('EBox::GlobalImpl=HASH(0x563a9bd9aa10)', 'progress', 'EBox::ProgressIndicator=HASH(0x563a9bc63dd8)') called at /usr/share/perl5/EBox/Global.pm line 95
EBox::Global::AUTOLOAD('EBox::Global=HASH(0x563a9bc52050)', 'progress', 'EBox::ProgressIndicator=HASH(0x563a9bc63dd8)') called at /usr/share/zentyal/global-action line 32
eval {...} at /usr/share/zentyal/global-action line 30

A Google-keresés, AI-k nem adtak használható választ, annyit árul el a Zentyal a /var/log/zentyal/uwsgi.log-ban, hogy néha 30--40 másodpercig is vár egy kérés, aztán vagy kifut a nginx timeout, vagy nem, vagy kifut a böngészőié, vagy nem.

Van esetleg valami ötletetek, mit lehetne elkövetni, hol kéne keresni a hibát, vagy hogy lehetne újrakonfigoltatni vele a DNS-t?

Köszi előre is!

Megoldás:

Az én esetemben a /var/lib/samba/CA mappában lévő index.txt okozta a problémát. Lejárt a CA és meg kellett újítani, csak így mégtovább hízott az itt lévő, lejárt, visszavont cert-ek száma.

Az r betűvel jelzett revoke-olt sorokat kivettem, illetve azokat, amik szerinte valid-ak voltak, de a fölötte lévő CA már neméppen.

Így begyorsult a webfelület és megy rendesen minden.

Köszi mindenkinek a segítséget!