Hálózatok általános

Vajh rákapnak-e mások is erre a modellre? Kitolunk egy olyan ingyenes automatikus frissítést, ami téglásítja a termékeket, és egyben felajánljuk, hog előfizetési díj ellenében végülis lehet tovább használni az eszközöket...

Videó fanoknak:

https://www.youtube.com/watch?v=KNuZ3BjT7IU

Inkább olvasóknak:

https://consumerrights.wiki/Futurehome_Smarthub_Mandatory_Subscription_…

https://consumerrights.wiki/Belkin_Wemo_discontinuation_of_service

A problémám az lenne, hogy a KEA dhcp ddns service, eldobja dns szerver frissítését.

Az adott végpont, nincs is még benne a dns-ben, de mégis eldobja a hozzáadást, de azt nem találom meg hogy mi miatt.

Túrtam a netet, de szinte semmi hiba megoldás nincs fent.

A legfrissebb 2.6-os van fent, előtte ubuntu repoban lépő 2.0.2-es volt fent, azzal ment minden, de frissíteni akartam és közben elfelejtettem backupot csinálni.

A telepítő meg felül csapta a működő konfigot. 

Ez lenne a syslog hiba üzenet:

Jul 15 06:59:58 szo1vcdhcp1 kea-dhcp-ddns[6071]: ERROR DHCP_DDNS_NO_FWD_MATCH_ERROR Request ID 000001854548457BEBF758508CD742003CBF84AD0434F5969AA491381483D03521925E: the configured list of forward DDNS domains does not contain a match for: Type: 0 (CHG_ADD)
Jul 15 06:59:58 szo1vcdhcp1 kea-dhcp-ddns[6071]: Forward Change: yes
Jul 15 06:59:58 szo1vcdhcp1 kea-dhcp-ddns[6071]: Reverse Change: yes
Jul 15 06:59:58 szo1vcdhcp1 kea-dhcp-ddns[6071]: FQDN: [valami.teszt.lan.]
Jul 15 06:59:58 szo1vcdhcp1 kea-dhcp-ddns[6071]: IP Address: [1.1.1.2]
Jul 15 06:59:58 szo1vcdhcp1 kea-dhcp-ddns[6071]: DHCID: [000001854548457BEBF758508CD742003CBF84AD0434F5969AA491381483D03521925E]
Jul 15 06:59:58 szo1vcdhcp1 kea-dhcp-ddns[6071]: Lease Expires On: 20250715062851
Jul 15 06:59:58 szo1vcdhcp1 kea-dhcp-ddns[6071]: Lease Length: 5333
Jul 15 06:59:58 szo1vcdhcp1 kea-dhcp-ddns[6071]: Conflict Resolution Mode: check-with-dhcid
Jul 15 06:59:58 szo1vcdhcp1 kea-dhcp-ddns[6071]:   The request has been discarded.

Ez a ddns konfig:
 

{
"DhcpDdns":
{
  "ip-address": "127.0.0.1",
  "port": 53001,
  "control-socket": {
      "socket-type": "unix",
      "socket-name": "kea-ddns-ctrl-socket"
  },

  <?include "/etc/kea/tsig-keys.json"?>

  "forward-ddns" : {
      "ddns-domains" : [
          {
               "name": "teszt.lan",
               "key-name": "dns-key",
               "dns-servers": [
                   { "ip-address": "2.2.2.2" }
               ]
          }
      ]
  },
 

Ez pedig a dhcp4 konfig, ddns része:

     "dhcp-ddns": {
        "enable-updates": true,
        "server-ip" : "127.0.0.1",
        "server-port" : 53001,
        "sender-ip" : "127.0.0.1",
        "sender-port" : 3433,
        "max-queue-size" : 2048,
        "ncr-protocol" : "UDP",
        "ncr-format" : "JSON"
     },

     "ddns-send-updates": true,
     "ddns-qualifying-suffix": "teszt.lan",
     "ddns-override-client-update": false,
     "ddns-override-no-update": true,
     "ddns-generated-prefix": "dynamic",
     "ddns-update-on-renew": true,
 

Megoldas:
 a test.lan utan hianyzott a pont
 

A rovid tortenet annyi, hogy uj laptopomat eppen akkor helyeztem uzembe amikor kulfoldon (Anglia) voltam. Ott at is raktam a sim kartyat a regibol es szepen fel is csatlakozott.

Aztan hazajottem, es a modem nem mukodott az itthoni halozaton. Sim kartyat visszarakva a regi laptopba siman mukodik. Mar leirtam a modemet, de mivel sok idore kellett volna megvalni a laptoptol es mivel par nap mulva megint utaztam ezert offoltam.

Aztan amikor landoltam az USAban elso hasznalatkor szepen csatlakozott a mobilnet.

Az utnak vege, remenykedtem benne, hogy itthon majd megint mukdoni fog de sajnos semmi. ModemManager logjabol ennyi tellik:

<pre>
Jul 02 08:45:09 teller ModemManager[2882]: <msg> [modem1] simple connect started...
Jul 02 08:45:09 teller ModemManager[2882]: <msg> [modem1] simple connect state (6/10): register
Jul 02 08:45:09 teller ModemManager[2882]: <msg> [modem1] 3GPP packet service state changed (unknown -> detached)
Jul 02 08:45:09 teller ModemManager[2882]: <msg> [modem1] 3GPP packet service state changed (detached -> unknown)
...
<ugyenz percenkent>
...
Jul 02 08:46:11 teller ModemManager[2882]: <msg> [modem1] 3GPP packet service state changed (unknown -> detached)
Jul 02 08:46:11 teller ModemManager[2882]: <msg> [modem1] 3GPP packet service state changed (detached -> unknown)
Jul 02 08:46:11 teller ModemManager[2882]: <wrn> [modem1] registration in network failed: Network timeout
</pre>

Probaltam manualis halozatvalasztast, nem mukodott ugy sem, probaltam az APN beallitasokat a telekom leirasa alapjan beallitani (https://www.telekom.hu/lakossagi/ugyintezes/gyakori-kerdesek/4255/hogya…) a NetworkManager helyett, de ez se mukdott.

Ugyfelszolgalat allitja, hogy az o oldalukon semmi baj nincs es a tarsosztaly mar megnezte sokszor, es arra a konkluziora jutottak, hogy a hiba az en keszulekemben van. De nem tudnak IMEI alapjan logot nezni, hogy megis mi tortenik, mert ez tars sim es ossze van csomagolva az elsodleges szammal.

Szoval vettem egy sima feltoltos Yettel kartyat, amit bedugva es felconfolva megy minden szepen, tud csatlakozni stb.

En arra gyanakszom, hogy az elso feljelentkezesnel tortenik valami regisztracio, config push vagy valami hasonlo es roamingban ez valahogy furcsan viselkedik es ilyet eredmenyez.

Lassan 2 hete megy az odavissza a telekommal de meg mindig nem jarunk sokkal kozelebb a megoldashoz.

Van valami otlet, debug stb. amit meg tudnek probalni?

Ma 15 óra körül a Vidanet hálózata letérdelt - legalábbis Győr környékén. A visszajelzések szerint se TV, se internet nincs. Jelenleg is tart a kiesés.

Az F! rajongók örülhettek, pont a rajt előtt ment el az adás ...

Sziasztok!

Van esetleg valakinél tapasztalat két SONiC OSS switch közt MCLAG létrehozásában? A github doksi ebben a témában eléggé száraz/hiányos számomra...

köszönöm

Sziasztok,

egy régi p2p implementáció kivezetésén dolgozok StrongSwan/IPSec alapon, azonban random sokszorozódnak az SA -k, amellett, hogy maga a kapcsolat stabil mindket iranyban. 
Előzetesen:

• az auto=start tudom, hogy nem javallott mindkét oldalon, de az auto=add esetén egy elvesztett kapcsolat nem minden esetben tudott ujraépülni
• az FQDN alapu cimzeshez hozzatartozik, hogy akar a DNS -ben, akar a hosts fajlban megfeleloen szerepel.

Ime a ket oldal ipsec.conf -ja:

conn si
    keyexchange=ikev2
    ike=aes256-sha256-modp2048!
    esp=aes256-sha256!
    ikelifetime=8h
    keylife=1h


    left=ips-si.domain.hu
    leftauth=psk
    leftid=@ips-si.domain.hu
    leftsubnet=192.168.20.0/24

    right=ips-gd.domain.hu
    rightid=@ips-gd.domain.hu
    rightsubnet=10.20.0.0/16
    rightauth=psk

    auto=start
    closeaction=restart
    dpdaction=restart

conn gd
    keyexchange=ikev2
    ike=aes256-sha256-modp2048!
    esp=aes256-sha256!
    ikelifetime=8h
    keylife=1h


    left=ips-gd.domain.hu
    leftauth=psk
    leftid=@ips-gd.domain.hu
    leftsubnet=10.20.0.0/16

    right=ips-si.domain.hu
    rightid=@ips-si.domain.hu
    rightsubnet=192.168.20.0/24
    rightauth=psk

    auto=start
    closeaction=restart
    dpdaction=restart

mindekozben az ipsec statusall vonatkozo blokkja pedig sokszorozza az SA -kat:

Security Associations (24 up, 0 connecting):
          si[40]: ESTABLISHED 6 hours ago, 2a01:4ff:c012:2000::153[ips-gd.domain.hu]...2a01:4ff:c013:3000::240[ips-si.domain.hu]
          si{413}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c5fd9cc5_i cce92764_o
          si{413}:   10.20.0.0/16 === 192.168.20.0/24
          si[39]: ESTABLISHED 6 hours ago, 2a01:4ff:c012:2000::153[ips-gd.domain.hu]...2a01:4ff:c013:3000::240[ips-si.domain.hu]
          si{435}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c36bdd92_i c7ceb7e7_o
          si{435}:   10.20.0.0/16 === 192.168.20.0/24
          si[34]: ESTABLISHED 6 hours ago, 2a01:4ff:c012:2000::153[ips-gd.domain.hu]...2a01:4ff:c013:3000::240[ips-si.domain.hu]
          si{421}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c541c8e1_i ce85eacb_o
          si{421}:   10.20.0.0/16 === 192.168.20.0/24
          si[33]: ESTABLISHED 6 hours ago, 2a01:4ff:c012:2000::153[ips-gd.domain.hu]...2a01:4ff:c013:3000::240[ips-si.domain.hu]
          si{430}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c069c53d_i c0459266_o
          si{430}:   10.20.0.0/16 === 192.168.20.0/24
          si[32]: ESTABLISHED 6 hours ago, 2a01:4ff:c012:2000::153[ips-gd.domain.hu]...2a01:4ff:c013:3000::240[ips-si.domain.hu]
          si{420}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c49e3ccc_i ce442666_o
          si{420}:   10.20.0.0/16 === 192.168.20.0/24
          si[31]: ESTABLISHED 6 hours ago, 2a01:4ff:c012:2000::153[ips-gd.domain.hu]...2a01:4ff:c013:3000::240[ips-si.domain.hu]
          si{416}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c5371a79_i cd90a37b_o
          si{416}:   10.20.0.0/16 === 192.168.20.0/24
          si[28]: ESTABLISHED 6 hours ago, 2a01:4ff:c012:2000::153[ips-gd.domain.hu]...2a01:4ff:c013:3000::240[ips-si.domain.hu]
          si{424}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c640fce2_i ca02677c_o
          si{424}:   10.20.0.0/16 === 192.168.20.0/24
          si[27]: ESTABLISHED 6 hours ago, 2a01:4ff:c012:2000::153[ips-gd.domain.hu]...2a01:4ff:c013:3000::240[ips-si.domain.hu]
          si{434}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c5c5304b_i c6ecb0d4_o
          si{434}:   10.20.0.0/16 === 192.168.20.0/24
          si[26]: ESTABLISHED 6 hours ago, 2a01:4ff:c012:2000::153[ips-gd.domain.hu]...2a01:4ff:c013:3000::240[ips-si.domain.hu]
          si{427}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: cd38c425_i c31d41c4_o
          si{427}:   10.20.0.0/16 === 192.168.20.0/24
          si[25]: ESTABLISHED 6 hours ago, 2a01:4ff:c012:2000::153[ips-gd.domain.hu]...2a01:4ff:c013:3000::240[ips-si.domain.hu]
          si{418}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c184a1b7_i c3c80d27_o
          si{418}:   10.20.0.0/16 === 192.168.20.0/24
          si[20]: ESTABLISHED 6 hours ago, 2a01:4ff:c012:2000::153[ips-gd.domain.hu]...2a01:4ff:c013:3000::240[ips-si.domain.hu]
          si{417}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c7104173_i c985657d_o
          si{417}:   10.20.0.0/16 === 192.168.20.0/24
          si[19]: ESTABLISHED 6 hours ago, 2a01:4ff:c012:2000::153[ips-gd.domain.hu]...2a01:4ff:c013:3000::240[ips-si.domain.hu]
          si{426}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c3495f02_i c9285dd9_o
          si{426}:   10.20.0.0/16 === 192.168.20.0/24

A kerdes az, hogy a fent emlitett auto parameterezesen kivul meg mi nem jo itt, ha a kapcsolat alapbol letrejon es stabil?

kis update: uniqueids=no eseten is ugyanez a szitu.

Sziasztok,

adott ket halozat (Hetzner internal network mindketto):

10.20.0.0/24 (GW 10.20.0.1, dhcp -n /32 -k vannak kiosztva; ARP -n csak a 10.20.0.1 latszik)
10.30.0.0/24 (GW 10.30.0.1, dhcp -n /32 -k vannak kiosztva; ARP -n csak a 10.30.0.1 latszik)

A ket halozat osszekotesere jott letre 1-1 gep IPSec tunnelel, 10.30.0.125, 10.20.0.126; ezek onmagukban mukodnek is, elerhetoek.

Az ARP hianya miatt csak ping erheto el network discovery ugyben.

A routing tabla igy fest 1-1 10.20.0.0/24 -ben levo gepen (csak az erintett routingok maradtak):

ip r
default via 172.31.1.1 dev eth0 
10.20.0.0/24 via 10.20.0.1 dev enp7s0 
10.20.0.1 dev enp7s0 scope link < ARP miatt feltetelezhetoen

Namost, itt ennek kellene bekerulnie elkepzeleseim szerint:

10.30.0.0/24 via 10.20.0.125 dev enp7s0 
10.20.0.126 dev enp7s0 scope link < ARP miatt

Azonban ez ugye nem mukodokepes, mert a 10.20.0.126 nem elerheto ARP -n, lasd fentebb. Tehat sem icmp, sem arp csomagok nem jutnak at a 10.20.0.126 -ra.

nft -vel a forward engedelyezve van a ket halozat kozott; SNAT a gateway -eken rendben.

10.30.0.125 -rol (a 10.30.0.0/24 -en levo gw) elerheto a 10.20.0.0/24 barmely gepe es viszont is a 10.20.0.126 -rol, DE bamrly, nem gateway geprol az ellentetes halozat semelyik gepe nem erheto el-

ping -c 1 -I 10.30.0.125 10.20.0.124
PING 10.20.0.124 (10.20.0.124) from 10.30.0.125 : 56(84) bytes of data.
64 bytes from 10.20.0.124: icmp_seq=1 ttl=62 time=16.9 ms

--- 10.20.0.124 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 16.895/16.895/16.895/0.000 ms
 

A kerdes:
Hogyan oldjam meg oda-vissza az atjarast a fentiek alapjan a ket halozat kozott? Lathatoan kellene routing, csak azt gyakorlatilag nem tudtam implementalni.

Üdv, olyan helyen vagyok belföldön, ahol lényegében az egészetlen ésszerű megoldás a korlátlan mobilnet. T-ről váltottam két One-ra, aztán május 1-én tapasztaltam először, hogy természetellenesen lelassult, kb. olyan szintre, mint amilyen volt a net az ADSL-dialup korában. (1.) mindegy, hogy mobil hotspotot használok vagy (2.) LTE-routert az is mindegy, hogy csak egy eszközön használnám vagy 10-nél többön, ugyanaz a helyzet. Két teljesen különálló SIM-ről van szó, amik gondolom én, azonos cellákat használnak. Van ötletetek azzal kapcsolatban, hogy mit lehet tenni ügyféloldalon? Pl. OpenCellid-ről lepuskázva az LTE-routerbe be lehet állítani, hogy mindig ugyanazt használja, de nem véletlenül nem alapértelmezés. A szolgáltató mennyire rugdosható v hogyan állapítható meg, hogy direkt lassítanak-e? Nem torrentezek vagy ilyesmi, csak egész nap használom a netet. 

Feltűnt, hogy Németországban, magyar Vodafone (bocsánat, One) előfizetéssel, "magyar IP címet" kap a telefon. Értem ez alatt, hogy az látszik a külvilág felé, nyilván a telefonon valami RFC-1918 cím van, így bukkan elő a CGNAT mögül. Oké.

Viszont másoknak, más országban meg helyit osztanak (lásd mint előbb).

Őszintén szólva pont ezt nem néztem, amikor más országokban jártam, hogy mit kaptam.

Szóval: mitől függ (APN? EU vs. !EU?), hogy hol bukkan elő az ember, és ehhez kapcsolódóan az is érdekelne, hogy milyen kombó (magyar szolgáltató + csomag + ország) hogy viselkedik?

Mint mindig, elsősorban a konkrét tapasztalatokra vagyok kíváncsi, nem arra, hogy az AI  vagy a kereső mit mond.

Előre is köszi.

Bár nem hálózat tech., de talán idefér.

Segítsetek irányba állítani, mi a hivatalos út, esetleges jogi lehetőségek ahhoz, hogy egy társasházba betelepült internet szolgáltatót kötelezni lehessen a lépcsőházban kiépített hálózatának rendbetételére? (Festenénk, nem matadhatnak a lógó kábelek, nyitott, törött dobozok és csatornák. Hozzá viszont elvileg nem nyúlhatunk - meg nem is szeretnénk finanszírozni - hiszen az a szolgáltató tulajdona)

- Kell-e keresnem valahol a múltból bármiféle írásos megállapodást arról hogy anno a szolgáltató megegyezett a TH-al, hogy jöhet, vagy ezek v.mi netsemlegesség, vagy ilyesmi jegyében jöhetnek, ha akarnak?

- Ha nincs ilyen megállapodás akkor mire lehet számítani?

- Nyilván lesz (lehet) vita belőle, hogy a szerelők, alvállalkozók igénytelen munkájáról van szó (egyébként igen), vagy az évek alatt a "lakók" által elkövetett vandalizmusról, károkozásról.

Még nem kerestem meg magát a szolgáltatót, de gondolom megértitek, hogy alapvetően nem sima, segítőkész, együttműködő ügymenetre számítok a kérdésben. (7 lh. x 5 szint - nem kevés újraszerelést kellene megcsinálniuk)