Sziasztok!
A cegcsoportunk minden leanyvallalatanal felmondja az internetes szerzodeset es NaaS szolgaltatasra vallt (https://www.gtt.net/) ismeri/hasznalja valaki ezt a szolgaltatot? mit lehet roluk tudni? Magyarorszagon ki a partneruk? Nalatok mennyire jellemzo amugy a globalis partner? Vagy inkabb mindig az aktualis helyi szolgaltatobol valasztanak?
Egykori Vidanet. Amióta a Magyar Telekom csoport tag Kalásznet vette át, egyre szarabb.
Jelenleg (Győr) se internet, se TV. Úgy egy órája. Az ÜFSZ elérhetetlen.
Bármit csinálok mindig a default 10.0.3.0/24 tartományt használja.
Az /etc/default/lxc-net ezt tartalmazza:
USE_LXC_BRIDGE="true"
LXC_BRIDGE = "lxcbr0"
LXC_ADDR = "10.0.9.1"
LXC_NETMASK = "255.255.255.0"
LXC_NETWORK = "10.0.9.0/24"
LXC_DHCP_RANGE = "10.0.9.2,10.0.9.254"
LXC_DHCP_MAX = "253"
LXC_DHCP_CONFILE=""
# Honor system's dnsmasq configuration
#LXC_DHCP_CONFILE=/etc/dnsmasq.confFelhúzott interface-ek:
7: lxcbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 10:66:6a:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 10.0.3.1/24 brd 10.0.3.255 scope global lxcbr0
valid_lft forever preferred_lft forever
inet6 fc42:5009:ba4b:5ab0::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::1266:6aff:fe00:0/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
8: vethL8LXk8@if2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master lxcbr0 state UP group default qlen 1000
link/ether fe:db:32:22:c3:15 brd ff:ff:ff:ff:ff:ff link-netnsid 0
Valakinek valami ötlet?
Megoldás:
Az /etc/default/lxc-net file-ban az egyenlőség jeleknél nem lehet space!
sziasztok,
Használtam NASt (synology) 2db 5tb wd reddel. Kinőttem, megszüntettem.
Szeretnék újat, nem PCt, célhardvert.
2 HDDvel, raid 1, kb 6-8tb
Mit ajánlotok?
köszi
Sziasztok!
Segítsetek kérlek, nem jövök rá mit rontok el. Az összeállítás:
Központi switch: ZyXel XGS1930-28
LAG2: 27/28 port - LACP - a másik oldalon egy Linux szerver, sima bond
LAG3: 23/24 port - LACP - a másik oldalon az régi iroda Netgear GS724Tv4 switch port 25/26
Mindkét LAG esetén: src-dst-mac a hash type
LACP system priority: 32768
Régi iroda switch: Netgear GS724Tv4
LAG1 - 25/26 port - LACP - Admin mode: Enable; STP Mode: Enable; Link Trap: Enable; LACP Priority: 128; Timeout: Long
LAG2 - 23/24 port - LACP - Admin mode: Enable; STP Mode: Enable; Link Trap: Enable; LACP priority: 32768; Timeout: Short
LACP System Priority: 32768
A LAG1 megy a központi ZyXel switch-be, a LAG2 a következő, FS eszközbe a 9/10 portba
Harmadik switch: FS IES3110-8TF-R
Port 7/8: LACP Enabled; Key: 102; Role: Active; Timeout: Fast; Prio: 32768
Port 9/10: LACP Enabled; Key: auto; Role: Active; Timeout: Fast; Prio: 32768
Nos. Amíg a ZyXel és a Netgear vannak ketten addig minden oké. Gyönyörűen összebeszélnek, felépül a link, hibátlan a működés. Abban a pillanatban hogy rákötöm a harmadik switch-et, a központi ZyXel switch loop protect-je letiltja a Netgear felé menő portokat. Mit nem veszek észre, hol a hiba?
Az Ai-t megkérdeztem, adott tippeket (STP, prioritások, stb), de szeretném érteni amit csinálok, nem vakon állítgatni.
Nagyon köszi!
Sziasztok,
főként GYAKORLATI tapasztalatokra vagyok kiváncsi. Az RTFM-et már elolvastam, az ebédemet meg már a ChatGPT főzte.
(Lásd pl. https://www.rfwireless-world.com/articles/sms-over-lte)
Ha van egy ipari (Quectel EC20 chipet tartalmazó) 4G/LTE képes IoT modemem, és egy szoftver mezei AT parancsokkal SMS-t akar vele küldeni, akkor ténylegesen elmegy-e az üzenet, ha a terepen kizárólag 4G (B20-as csatorna, 800MHz) lefedettség van, tehát nem tud visszaváltani 2G-re? (A modemnek meg kellene oldania azt, hogy az SMS-kompatibilis AT parancsokkal küldött üzenet kimenjen SIP/IP felett, IMS módban.)
Ha nem, akkor mi az a helyettesítő eszköz (USB csatolós modem), amivel ez lehetséges lehet?
Nyilván az a workflow szoftver-kompatibilitás okokból nem járható, hogy a terepen lévő LTE eszköz mobilneten szól egy másik eszköznek, ami meg elküldi helyette a tényleges SMS-t. (relay)
A terepen egy olyan IoT eszköz van, aminek USB interfésze van, és egy ttyUSB porton előre definiált AT parancsokkal dolgozik. Ebből kell főzni.
A szolgáltató jelenleg a Yettel, de más szolgáltató viszonylatában is érdekel.
Jó ez a nap. A CloudFlare után a GitHub hasalt el az imént (este 22:00). Nem lehet clone-ozni/pullozni repót.
Sziasztok!
Beüzemeltem az újonnan telepített FreePBX v17-es telefonközpontunkat és az alábbiakat tapasztalom.
Az internet szolgáltatónk doboza után egy Cisco RV042-es típusú router üzemel.
A jelenlegi vonalunk felépítése: Optika -> Szolgáltató doboza -> Cisco RV042 -> Tűzfal -> Switch -> belső hálózat, benne a telefonszerverrel.
A telefonszerveren erősen dolgozik a fail2ban, fél nap alatt cc 500 levelet kaptam tőle, hogy kitiltott idegen regisztrálni akarókat.
Gondoltam, tehermentesítem a rendszerünket ezektől a kérésektől és már a Cisco routerben kitiltom őket.
A telefonszolgáltatónk az Ephone, a sip szerver címe sip.ephone.hu, ennek IP címe 82.150.61.51.
A router Tűzfal Access Rules fülén az alábbi bejegyzéseket tettem:
| Priority | Enable | Action | Service | Source  Interface | Source | Destination |
| 1 | Yes | Allow | SIP [5060~5064] | ANY | 82.150.61.51 ~ 82.150.61.51 | 10.0.9.8 ~ 10.0.9.8 |
| 2 | No | Deny | SIP [5060~5064] | ANY | Any | Any |
| Yes | Allow | All Traffic [1] | LAN | Any | Any | |
| Yes | Deny | All Traffic [1] | WAN1 | Any | Any | |
| Yes | Deny | All Traffic [1] | WAN2 | Any | Any |
(Az utolsó 3 alap, nem módosítható tétel)
Azt tapasztalom, hogy ha az első két tétel mindegyike engedélyezve van, akkor működnek a hívások mindkét irányban, megszűnnek a fail2ban értesítések, de ha lejár a SIP regisztrációs trönk timeout-ja, akkor nem tudja a regisztrációt megújítani, a kérés timeout-ra fut.
Ha a 2. sort (Deny) letiltom (vagy törlöm), akkor ez a gond nincs, de természetesen jönnek a regisztrációs próbálkozások.
Mit kellene beállítanom ahhoz, hogy működjön a szabály?
Gábor
Update: Megoldódott a probléma, sibike hozzászólása rávilágított az elkövetett hibára: A "Source Interface"-nek ANY-t állítottam be, amibe beletartozott a belső interface is, így nem engedte kifelé se a forgalmat.
Most átírtam úgy, hogy a Deny szabály csak a WAN1-re vonatkozoon és most működik.
Több osztrák (.at TLD) domain esetében beleütköztem abba a problémába, hogy a BIND 9 azt mondja rekurzív feloldás esetén, hogy SERVFAIL, viszont a nagyobb szolgáltatók rekurzív DNS szerverei (Google, CloudFlare, stb.) szerint feloldható a zóna.
Lássuk példának a "morenet.at" domaint. A "at" zónában benne vannak az NS rekordok, glue rekorddal, IP címmel:
dig @ns1.univie.ac.at. morenet.at
;; AUTHORITY SECTION:
morenet.at. 10800 IN NS ns1.morenet.at.
morenet.at. 10800 IN NS ns2.morenet.at.
morenet.at. 10800 IN NS ns3.morenet.at.
;; ADDITIONAL SECTION:
ns1.morenet.at. 10800 IN AAAA 2a01:4f8:0:a101::a:1
ns2.morenet.at. 10800 IN AAAA 2a01:4f8:d0a:2004::2
ns3.morenet.at. 10800 IN AAAA 2001:67c:192c::add:a3
ns1.morenet.at. 10800 IN A 213.239.242.238
ns2.morenet.at. 10800 IN A 213.133.105.6
ns3.morenet.at. 10800 IN A 193.47.99.3Viszont, ha a zóna fent hivatkozott szervereit nézzük, akkor nincs bennük sem "NS" rekord, sem a hozzá tartozó "A" rekord:
dig @213.239.242.238 morenet.at ns
morenet.at. 3600 IN SOA hydrogen.ns.hetzner.com. dns.hetzner.com. 2025110803 86400 10800 3600000 3600illetve
dig @213.239.242.238 ns1.morenet.at a
morenet.at. 3600 IN SOA hydrogen.ns.hetzner.com. dns.hetzner.com. 2025110803 86400 10800 3600000 3600Ha a saját rekurzív DNS szerveremmel csinálok egy lekérdezést, akkor ezt kapom:
dig ns1.morenet.at a +trace
; <<>> DiG 9.20.11-4-Debian <<>> ns1.morenet.at a +trace
;; global options: +cmd
. 518177 IN NS i.root-servers.net.
. 518177 IN NS g.root-servers.net.
. 518177 IN NS a.root-servers.net.
. 518177 IN NS k.root-servers.net.
. 518177 IN NS j.root-servers.net.
. 518177 IN NS d.root-servers.net.
. 518177 IN NS e.root-servers.net.
. 518177 IN NS m.root-servers.net.
. 518177 IN NS f.root-servers.net.
. 518177 IN NS c.root-servers.net.
. 518177 IN NS h.root-servers.net.
. 518177 IN NS b.root-servers.net.
. 518177 IN NS l.root-servers.net.
. 518177 IN RRSIG NS 8 0 518400 20251123050000 20251110040000 61809 . 6jL4QcWAw7hj6jLdO3Jk1pLz6R1usptIWhrwQpiHj1g3VhdrCpraptj4 ZMfnIRTt58FnDTAprh/3HCxWo/8Rmx9gXkJhpUF3bYv5jf/wDR+ywmnf /74csd2Z7kHQBoHCogor+FvBqg4/HoSpPl6mbXCoon9OfU4VKLj+2513 esHSN0j+oowt+xhoh/ncHrerLuY7d1zzsyPlIiiLtKoPHkNk+rC4+Ysv uiBXr/zvE5haKpdPCYVXja2GNWTlBnd5doqyjIM95c1K/hJF02kuNYit H3dYSzQw9XulWmItfvWQ7Ub5SMXKa+ivAWT9qrXu1KdwffkXi5r7l1Kz Rfgokw==
;; Received 1125 bytes from 172.28.0.1#53(172.28.0.1) in 0 ms
at. 172800 IN NS d.ns.at.
at. 172800 IN NS j.ns.at.
at. 172800 IN NS n.ns.at.
at. 172800 IN NS r.ns.at.
at. 172800 IN NS u.ns.at.
at. 172800 IN NS ns1.univie.ac.at.
at. 172800 IN NS ns2.univie.ac.at.
at. 86400 IN DS 1253 13 2 BA17C1BACB3FB49F7760AD1F7E71E17AB39EE0DF3E9D3BF23FD3D70D 6CF1719E
at. 86400 IN DS 60960 13 2 A00073DD75C499465FE829381CE3F5488FC353D06E68C7F90A04D26A 0D71A694
at. 86400 IN RRSIG DS 8 1 86400 20251123050000 20251110040000 61809 . lvjwZzrt8zGMMCwN2cNMHjuACWzvXbMXLjmI0CFa81JFo9ICIH+WZE7h PG+AV52zpyy5SAxKao9gN2uwT2vOqnrwwz2Exd04dOuLlKo0myRfD0Cc UP4CsRef9aZhxrKebwSSxRSxcfSXsktnD4tqe3aZzTDSmU2MyNLIBRlV kvZJJyY9bwV7Cr+bikDip0fH1voGCndkvOhfFMO3hDROzlP9eYFfmd/W TXETrCW0BSG6hh968O4pQYTITUVEVeb/85FcdFfLiOI4Q0UNS6s7ozRS oNflUgmSmPN+MtzkjE/3vcl8ynV5oYOEe0o/pTB0++fI1cF6P+EwjWgb IQgdTg==
;; Received 863 bytes from 2001:7fd::1#53(k.root-servers.net) in 0 ms
morenet.at. 10800 IN NS ns3.morenet.at.
morenet.at. 10800 IN NS ns1.morenet.at.
morenet.at. 10800 IN NS ns2.morenet.at.
fjscbioio98ccv4od6ka4d7oh5bgrn00.at. 10800 IN NSEC3 1 1 0 - FJTB0TH9158RT0NA9RGUQ165JJ6UAN8G NS SOA RRSIG DNSKEY NSEC3PARAM
fjscbioio98ccv4od6ka4d7oh5bgrn00.at. 10800 IN RRSIG NSEC3 13 2 10800 20251118230500 20251105130119 23696 at. OGDQzRWgK3bRFRqY2WuwSJfE38HqJJHTiRIwvq66r2dVK2xUqiAtjav4 WEBufTw8cZGanWtZ62xQAVoZG9IstQ==
ob8ge1mkf36alv3j3vemb23uejbhn0nb.at. 10800 IN NSEC3 1 1 0 - OBA8A2LNS2QQEEKRD7SH5F6BD559A3QJ NS DS RRSIG
ob8ge1mkf36alv3j3vemb23uejbhn0nb.at. 10800 IN RRSIG NSEC3 13 2 10800 20251119161047 20251106000120 23696 at. QuYPXfpBeBQY2YSklw4q2CeOpc3iASb9TlMIrCV6rKAwGVwjmAJiX+8P MdCusUrvffdaSIfogp1uW8wm4dByxg==
couldn't get address for 'ns3.morenet.at': not found
couldn't get address for 'ns1.morenet.at': not found
couldn't get address for 'ns2.morenet.at': not found
dig: couldn't get address for 'ns3.morenet.at': no moreAkkor ez most bug vagy feature?
Van két domainom ugyanattól a szolgáltatótól. Nincs fix IP. A régit ( https://asajah.hu ) vagy 15 éve regeltem, ott még A recordnak meg tudtam adni DynDns-t. Az újat kb 6 éve, oda már csak fix IP-t engedett. Lett belőle C name https://www.esp8266.org A https://esp8266.org pár napja nem jön be, csak a www. Tudom hogy nem szabályos. Van rá valami megoldás?