Hálózatok általános

Sziasztok!

Ma (2024-01-18) délelőtt folyamán az összes éttermi rendszer net-hibát kezdett jelezni az egész országban.

Kezdetben "XML feldolgozási hiba", később "forbidden 403" ... azután "timeout". Pl.: DEMO << nálam ez nem jön be, mobilnetről pedig "Az oldal httpS... SSL megbízhatatlan" hibát ír".

Már napokkal ezelőtt is jelezték ügyfelek az éttermek felé, hogy egyes mobilszolgáltatókon keresztül (Yt) nem érhető el egyik másik étterem weboldala. (Ergo a szerver: webetterem.hu + foodora.hu rendelések "átjátszása")

Ma az alábbi választ kaptuk a Rackforest-től:

“Kollégáimtól azt az információt kaptam, hogy a tűzfal a Google kockázatelemző algoritmusát és AI technológiát alkalmazva hoz döntést róla, hogy egy-egy IP címről érkező forgalmat gyanúsnak talál-e vagy sem, és ez alapján dob fel captchát. “

Eddig a több tucatnyi étterem "déli csúcs" időszaki forgalomkiesése milliós nagyságrendű és továbbra sem tudjuk, mi fog így történni.
Egyikük sem éri el a saját weboldalát se a háttér-admin felületet, sem pedig az XML letöltéseket.
(Amit egy Delphi program végez, "Indy" User-Agent-tel.)

Úgy értesültünk, nem mi vagyunk az egyetlen "szerencsések" az ügyben.

• Van valaki másnak is hasonló tapasztalata?

Adott egy céges hálózat, amin fél évente frissítem a pfSense GW szervert (jelenleg v2.7.2). Minden nagyon jól működik/működött, azonban szembesültem vele, hogy a DHCP kiszolgáló hamarosan átvált az eddigi stabil ISC által feljesztett változatról a KEA félére. Én bolond meg is tettem az átállást, és bizony belefutottam ugyanazokba a hibákba (pl. ez és ez) mint sokan mások, és én is -- mint sokan mások, látva a hibákat -- váltottam gyorsan vissza ISC-re.

Azonban problémák maradtak így is: a "DHCP leases" lista hiányos, a címet kapott gépek/laptopok zöme nem látszik. Továbbá van amit a dhcpd process kezel le, van amit a kea-dhcp. Ami fura, mert elvileg nem ez van használatban.

Ha mást nem, akkor egy korábbi (frissítés előtti) config mentésből újra telepítem és visszaállítom a rendszert, talán nem lesz beragadva a KEA rettenet.

Ha netán valaki már sikeresen megküzdött ezzel a problémával és megosztja javaslatát, annak csak örülni fogok. Ami inkább a kérdésem, hogy mire lehet majd számítani a kea-dhcp háza táján? Mert jelenleg nagyon instabilnak mutatkozik, és olvasva a vele kapcsolatos panaszokat, nem is nagyon iparkodnak a hibák javításán.

  Sziasztok!

Van egy partner cég akiknek hálózatot építettem. Korábban ADSL kapcsolatuk volt. A város szélén laknak, ezért nagyon sokáig tart elintézni, hogy kössenek hozzájuk optikai netet. A részleteket nem ismerem, de azt tudom, hogy a cég saját költségen (is) épített ki nyomvonalat; pénzt és időt nem kímélve egy év alatt sikerült eljutni oda, hogy bekötésre kerüljön az optikai hálózat. A legrosszabb az egészben az, hogy az egy évből az utolsó kb. 4 hónapban a feketeszál már ott volt a telephelyen, de az engedélyeztetés átfutási ideje miatt használhatatlan volt. (Miért kell 4 hónap arra, hogy beüzemeljék?)

A fentieket figyelembe véve igencsak dühítő tapasztalat, hogy a bekötött net sebessége közelében sincs annak, amit a vállaltak. Ez egy 2000/1000 Mbps "gigaerős optikai net 2000" nevű előfizetés. Itt láthatók a vállalt sebességek: https://www.telekom.hu/static-la/sw/file/Internet-hozzaferesi_szolgalta…

A valóságos sebességek a következők:

* a letöltési sebesség szinte soha nem éri el a minimális 300Mbps-t. Átlagban 250 körül van. Az utóbbi napokban gyakran méregettem különböző időpontokban, és különböző sebességmérő szerverekkel. Elvétve láttam már 600Mbps értéket, de legalább 90%-ban 250Mbps alatt van.
* a feltöltési sebesség is ennyi, tehát itt legalább hozzá a minimálisat, de a "normál körülmények között elérhető" 550Mbps-nek a fele sincs meg

Szeretném kérdezni a következőket:

1. Az erre vonatkozó szabályozás a 3/2011. (XII. 27.) NMHH rendelet, vagy van ennél újabb? Ebben a rendeletben nem láttam olyat, hogy "normál körülmények között elérhető" sebesség. De valahonnan úgy rémlik hogy ez a fogalom rögzített jelentéssel bír, és az esetek 90%-ban hozni kellene ezt a sebességet. Csak nem találok erre hivatkozást sehol sem. Hol keressem?
2. A telekom mit fogad el hivatalos sebességmérésnek? Speedtest-et használtam, de gondolom hogy ezt nem fogadják el. (Még akkor sem, ha a tesztek között kézzel megadott telekomos szerver is akad.) Mit kellene használnom ahhoz, hogy komolyan vegyenek?
3. Mi a módja, hivatalos formája a panasz benyújtásának? A panasz jogosságát hogyan, és mennyi idő alatt szokták ellenőrizni? (Az is 4 hónap? Remélem nem.)

Köszönöm!

Hello,

Adott két VPS. Az egyiken fut egy Windows Server 2022, amit a felhasználóknak el kellene érnie RDP-vel. (Két külön helyről, fix ip-vel nem rendelkeznek). Az RDP elérést nem fogom publikussá tenni ezért gondoltam teszek elé egy tűzfalat, rá egy VPN szervert és mindenki boldog lesz.

Feltelepítettem a pfSense-t (2.7.2) és nekiláttam egy L2TP+IPSEC szervert felhúzni rá. Azóta eltelt két nap és nem sokat léptem előre pedig nem ez az első amit összeraktam. Pont két napos pfSense tapasztalatom van, de elvileg egy csimpánz is összerakja leírások és videók alapján. Picit elkeserítő, hogy kb. mindenhol azt írják, hogy NAT mögött vagy megy vagy nem. Hát nálam nem.

Amúgy nem feltétlenül ragaszkodom a pfSense-hez, de a megoldásnak szoftveresnek kell lennie illetve lehetőleg ne kelljen hozzá 3rd party kliens. Köszönöm előre is a javaslatokat!

Jan 16 20:44:47	charon	10167	13[IKE] <con-mobile|38> received retransmit of request with ID 1, but no response to retransmit
Jan 16 20:44:47	charon	10167	13[NET] <con-mobile|38> received packet: from 82.1.2.3[4500] to zzz.yyy.hhh.aaa[4500] (444 bytes)
Jan 16 20:44:32	charon	10167	13[IKE] <con-mobile|38> received retransmit of request with ID 1, but no response to retransmit
Jan 16 20:44:32	charon	10167	13[NET] <con-mobile|38> received packet: from 82.1.2.3[4500] to zzz.yyy.hhh.aaa[4500] (444 bytes)
Jan 16 20:44:25	charon	10167	13[IKE] <con-mobile|38> received retransmit of request with ID 1, but no response to retransmit
Jan 16 20:44:25	charon	10167	13[NET] <con-mobile|38> received packet: from 82.1.2.3[4500] to zzz.yyy.hhh.aaa[4500] (444 bytes)
Jan 16 20:44:22	charon	10167	08[IKE] <con-mobile|38> received retransmit of request with ID 1, but no response to retransmit
Jan 16 20:44:22	charon	10167	08[NET] <con-mobile|38> received packet: from 82.1.2.3[4500] to zzz.yyy.hhh.aaa[4500] (444 bytes)
Jan 16 20:44:21	charon	10167	08[IKE] <con-mobile|38> received retransmit of request with ID 1, but no response to retransmit
Jan 16 20:44:21	charon	10167	08[NET] <con-mobile|38> received packet: from 82.1.2.3[4500] to zzz.yyy.hhh.aaa[4500] (444 bytes)
Jan 16 20:44:20	charon	10167	08[IKE] <con-mobile|38> nothing to initiate
Jan 16 20:44:20	charon	10167	08[IKE] <con-mobile|38> activating new tasks
Jan 16 20:44:20	charon	10167	08[NET] <con-mobile|38> sending packet: from zzz.yyy.hhh.aaa[4500] to 82.1.2.3[4500] (76 bytes)
Jan 16 20:44:20	charon	10167	08[ENC] <con-mobile|38> generating INFORMATIONAL_V1 request 147335877 [ HASH N(INVAL_ID) ]
Jan 16 20:44:20	charon	10167	08[IKE] <con-mobile|38> activating INFORMATIONAL task
Jan 16 20:44:20	charon	10167	08[IKE] <con-mobile|38> activating new tasks
Jan 16 20:44:20	charon	10167	08[IKE] <con-mobile|38> queueing INFORMATIONAL task
Jan 16 20:44:20	charon	10167	08[IKE] <con-mobile|38> no matching CHILD_SA config found for 82.1.2.3/32|/0[udp/l2f] === zzz.yyy.hhh.aaa/32|/0[udp/l2f]
Jan 16 20:44:20	charon	10167	08[CFG] <con-mobile|38> dynamic
Jan 16 20:44:20	charon	10167	08[CFG] <con-mobile|38> proposing traffic selectors for other:
Jan 16 20:44:20	charon	10167	08[CFG] <con-mobile|38> zzz.yyy.hhh.aaa/32|/0
Jan 16 20:44:20	charon	10167	08[CFG] <con-mobile|38> proposing traffic selectors for us:
Jan 16 20:44:20	charon	10167	08[CFG] <con-mobile|38> looking for a child config for zzz.yyy.hhh.aaa/32|/0[udp/l2f] === 82.1.2.3/32|/0[udp/l2f]
Jan 16 20:44:20	charon	10167	08[IKE] <con-mobile|38> changing received traffic selectors 192.168.1.73/32|/0[udp/l2f]=== zzz.yyy.hhh.aaa/32|/0[udp/l2f] due to NAT
Jan 16 20:44:20	charon	10167	08[ENC] <con-mobile|38> parsed QUICK_MODE request 1 [ HASH SA No ID ID NAT-OA NAT-OA ]
Jan 16 20:44:20	charon	10167	08[NET] <con-mobile|38> received packet: from 82.1.2.3[4500] to zzz.yyy.hhh.aaa[4500] (444 bytes)
Jan 16 20:44:20	charon	10167	13[NET] <con-mobile|38> sending packet: from zzz.yyy.hhh.aaa[4500] to 82.1.2.3[4500] (76 bytes)
Jan 16 20:44:20	charon	10167	13[ENC] <con-mobile|38> generating ID_PROT response 0 [ ID HASH ]
Jan 16 20:44:20	charon	10167	13[IKE] <con-mobile|38> DPD not supported by peer, disabled
Jan 16 20:44:20	charon	10167	13[IKE] <con-mobile|38> maximum IKE_SA lifetime 28431s
Jan 16 20:44:20	charon	10167	13[IKE] <con-mobile|38> scheduling rekeying in 25551s
Jan 16 20:44:20	charon	10167	13[IKE] <con-mobile|38> IKE_SA con-mobile[38] state change: CONNECTING => ESTABLISHED
Jan 16 20:44:20	charon	10167	13[IKE] <con-mobile|38> IKE_SA con-mobile[38] established between zzz.yyy.hhh.aaa[zzz.yyy.hhh.aaa]...82.1.2.3[192.168.1.73]
Jan 16 20:44:20	charon	10167	13[CFG] <38> selected peer config "con-mobile"
Jan 16 20:44:20	charon	10167	13[CFG] <38> candidate "con-mobile", match: 1/1/24 (me/other/ike)
Jan 16 20:44:20	charon	10167	13[CFG] <38> looking for pre-shared key peer configs matching zzz.yyy.hhh.aaa...82.1.2.3[192.168.1.73]
Jan 16 20:44:20	charon	10167	13[IKE] <38> remote endpoint changed from 82.1.2.3[500] to 82.1.2.3[4500]
Jan 16 20:44:20	charon	10167	13[IKE] <38> local endpoint changed from zzz.yyy.hhh.aaa[500] to zzz.yyy.hhh.aaa[4500]
Jan 16 20:44:20	charon	10167	13[ENC] <38> parsed ID_PROT request 0 [ ID HASH ]
Jan 16 20:44:20	charon	10167	13[NET] <38> received packet: from 82.1.2.3[4500] to zzz.yyy.hhh.aaa[4500] (76 bytes)
Jan 16 20:44:20	charon	10167	13[NET] <38> sending packet: from zzz.yyy.hhh.aaa[500] to 82.1.2.3[500] (372 bytes)
Jan 16 20:44:20	charon	10167	13[ENC] <38> generating ID_PROT response 0 [ KE No NAT-D NAT-D ]
Jan 16 20:44:20	charon	10167	13[CFG] <38> candidate "con-mobile", match: 1/1/24 (me/other/ike)
Jan 16 20:44:20	charon	10167	13[IKE] <38> remote host is behind NAT
Jan 16 20:44:20	charon	10167	13[ENC] <38> parsed ID_PROT request 0 [ KE No NAT-D NAT-D ]
Jan 16 20:44:20	charon	10167	13[NET] <38> received packet: from 82.1.2.3[500] to zzz.yyy.hhh.aaa[500] (388 bytes)
Jan 16 20:44:20	charon	10167	13[NET] <38> sending packet: from zzz.yyy.hhh.aaa[500] to 82.1.2.3[500] (160 bytes)
Jan 16 20:44:20	charon	10167	13[ENC] <38> generating ID_PROT response 0 [ SA V V V V ]
Jan 16 20:44:20	charon	10167	13[IKE] <38> sending NAT-T (RFC 3947) vendor ID
Jan 16 20:44:20	charon	10167	13[IKE] <38> sending FRAGMENTATION vendor ID
Jan 16 20:44:20	charon	10167	13[IKE] <38> sending DPD vendor ID
Jan 16 20:44:20	charon	10167	13[IKE] <38> sending XAuth vendor ID
Jan 16 20:44:20	charon	10167	13[CFG] <38> selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
Jan 16 20:44:20	charon	10167	13[CFG] <38> configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
Jan 16 20:44:20	charon	10167	13[CFG] <38> received proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/ECP_384, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/ECP_256, IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MaODP_1024
Jan 16 20:44:20	charon	10167	13[CFG] <38> proposal matches
Jan 16 20:44:20	charon	10167	13[CFG] <38> selecting proposal:
Jan 16 20:44:20	charon	10167	13[CFG] <38> no acceptable ENCRYPTION_ALGORITHM found
Jan 16 20:44:20	charon	10167	13[CFG] <38> selecting proposal:
Jan 16 20:44:20	charon	10167	13[CFG] <38> no acceptable KEY_EXCHANGE_METHOD found
Jan 16 20:44:20	charon	10167	13[CFG] <38> selecting proposal:
Jan 16 20:44:20	charon	10167	13[IKE] <38> IKE_SA (unnamed)[38] state change: CREATED => CONNECTING
Jan 16 20:44:20	charon	10167	13[IKE] <38> 82.1.2.3 is initiating a Main Mode IKE_SA
Jan 16 20:44:20	charon	10167	13[ENC] <38> received unknown vendor ID: e3:a5:96:6a:76:37:9f:e7:07:22:82:31:e5:ce:86:52
Jan 16 20:44:20	charon	10167	13[ENC] <38> received unknown vendor ID: 26:24:4d:38:ed:db:61:b3:17:2a:36:e3:d0:cf:b8:19
Jan 16 20:44:20	charon	10167	13[ENC] <38> received unknown vendor ID: fb:1d:e3:cd:f3:41:b7:ea:16:b7:e5:be:08:55:f1:20
Jan 16 20:44:20	charon	10167	13[IKE] <38> received FRAGMENTATION vendor ID
Jan 16 20:44:20	charon	10167	13[IKE] <38> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Jan 16 20:44:20	charon	10167	13[IKE] <38> received NAT-T (RFC 3947) vendor ID
Jan 16 20:44:20	charon	10167	13[IKE] <38> received MS NT5 ISAKMPOAKLEY vendor ID
Jan 16 20:44:20	charon	10167	13[ENC] <38> received unknown vendor ID: 01:52:8b:bb:c0:06:96:12:18:49:ab:9a:1c:5b:2a:51:00:00:00:01
Jan 16 20:44:20	charon	10167	13[IKE] <38> remote endpoint changed from 0.0.0.0 to 82.1.2.3[500]
Jan 16 20:44:20	charon	10167	13[IKE] <38> local endpoint changed from 0.0.0.0[500] to zzz.yyy.hhh.aaa[500]
Jan 16 20:44:20	charon	10167	13[CFG] <38> found matching ike config: 0.0.0.0/0, ::/0...0.0.0.0/0, ::/0 with prio 24
Jan 16 20:44:20	charon	10167	13[CFG] <38> candidate: 0.0.0.0/0, ::/0...0.0.0.0/0, ::/0, prio 24
Jan 16 20:44:20	charon	10167	13[CFG] <38> looking for an IKEv1 config for zzz.yyy.hhh.aaa...82.1.2.3
Jan 16 20:44:20	charon	10167	13[ENC] <38> parsed ID_PROT request 0 [ SA V V V V V V V V ]
Jan 16 20:44:20	charon	10167	13[NET] <38> received packet: from 82.1.2.3[500] to zzz.yyy.hhh.aaa[500] (408 bytes)

Miert van az, hogy egy csomo nevesebb oldal (is) 2 napra sem kepes megjegyezni, hogy mar beleegyeztunk minden tetves cookie-ba? Megcsak nem is azt kene megjegyezni, hogy nem egyeztunk bele (az se megy, szoval mindegy).

Rendelkezik valahol a GDPR nevetsegesen rovid hataridokrol? Mely pontokban?

Ha nem rendelkezik, miert nem lehet beirni, hogy a user 2 evre beleegyezett / nem egyezett bele az adatgyujtesbe?

Egyszeruen a sokadik oldalon igyekszem kerulni a tartalomfogyasztast emiatt, es a "csak ha muszaj" rendszeresseggel nezek mar rajuk. De ha van ok erre a torvenyben es valaki megmutatja, elnezobb leszek veluk, de addig nekem ok csak UX antitalentum balfaszok.

valami nem oke

Azt írja a RHEL9 doksi, hogy: "Attackers can use zone transfers to update DNS servers with false information."

Namost, ez nekem gyanús, mert addig oké, hogy ha valaki tud AXFR-t (vagy akár IXFR-t), akkor megtudhat olyanokat is, amit nem feltétlen akarunk hogy megtudjon. Ez oké.

De... hogyan lehet AXFR-rel hamis információt juttatni a DNS szervernek? Mármint értem én hogy lehúzok egy zónát, átírom amit akarok, és valahogy bekamuzom hogy én vagyok az egyetlen igazi DNS szervere a zónának, de ebben az esetben nem magát az AXFR-t látom az igazi problémának.

Vagy... mit értek félre?

Sziasztok,

van az a jelenségem, hogy a Windows 10 egyszer csak elkezdte használni a DoH-ot (DNS over HTTPs) ami nagyon érdekes csakhát az vele a baj, hogy a belső hálózaton a kliens kérdezgesse csak a neki kijelölt (belső DNS szervereket). Ne nyúlkáljon ki nekem ki tudja, hogy hová?

Nem is tudom ez pontosan hogyan működik vagy hogyan kellene szabályozni.

Ami probléma akadt az nem biztos, hogy innen fakad de még rátesz erre egy lapáttal. Ugynis van egy cég akinek a domain neve például: ceg.hu.  Ide akar beVPN-ezni a kliens majd a hálózat tagjaként a subnet.ceg.hu-ban elérni a hostokat. Ehhez a VPN kiépülése után a kapott belső DNS szervereket kellene szólongatnia. De! A cég domain kiszolgálójában van egy A record ami *.ceg.hu és a www.ceg.hu IP-jét adja vissza. Ezáltal amikor elindul a kliens gép és volt egy hivatkozás vagy egyéb ok miatt de fel akarja oldani a server.subnet.ceg.hu címet. Amint kijut a netre megkérdezi a DNS-eket amik a *.ceg.hu-s értéket adják vissza mert nincs ilyen bejegyzés a külső DNS-ben. Ezt be is cache-eli TTL szerint. A kliens kapcsolódik a VPN-hez és már hiába más a DNS kiszolgáló mivel be van cache-elve a server.subnet.ceg.hu ezért azt kapja és ez nem jó!

Kérdés, hogyan lehetne a VPN kapcsolat felépülésével a locális DNS cache ürítését kikényszeríteni? (#ipconfig /flushdns)

Hogyan lehet VPN kapcsolat során a DHCP azaz nem manuális beállítások esetén a DoH-ot letiltani!?

-thx-

Hali,

Nekem nem megy, mas is tapasztalja?

Sziasztok!

A lakásban a fali végpontokhoz menő kábelek egy szekrényben végződnek szabadon lógva. Cat5e tömör kábelek. Két kérdésem lenne:

1. Tömör kábelhez való RJ45 dugót krimpelhetek rá? Ha nem, akkor mit javasoltok?
https://www.hqelektronika.hu/hu/rj45-utp-dugo-8p-8c-modular-cat6-csat-t…

2. Egyenesre vagy keresztre kell krimpelnem a kábelt?

Köszi előre is!