Hálózatok általános

Telekom Mobilnet - csak roamingban csatlakozik, honos halozaton nem [ workaround found ]

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?

ipsec lámaizmus

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.

[MEGOLDVA] L3 (?) routing internal networkok kozott

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.

Korlátlan mobiletes feketelyuk

Ü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. 

Mobilnet + külföld: milyen IP?

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.

Internet szolgáltatók vs. Társasház (szerelési mód, minőség)

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)

One IPv6 hiba kezelés

Elnézést, ha nem jó fórum.

Tegnap 15:20 -tól nem működik a volt Digi-n az IPv6- om.
Az eszközük brige módban van.
A saját router kap IPv6-os IP-t - látszolag korrekt.
Ha kivelé mennék akkor ezt látom:
traceroute to google.com (2a00:1450:400d:808::200e), 30 hops max, 72 byte packets
1  2a01-036c-0104-430b-6de0-7bae-9b0d-fafa.pool6.digikabel.hu (2a01:36c:104:430b:6de0:7bae:9b0d:fafa)  14.413 ms  13.815 ms  13.007 ms
2  2a01:368:104:1000::1 (2a01:368:104:1000::1)  2.234 ms  2.438 ms  2.353 ms
3 * * * 
4 * * * 

A hibát letefonon majd weben is bejlentettem.
A kabaré a webes bejelntkezés válasza:
"

Tisztelt Ügyfelünk!
Az Ön internetes szolgáltatásában beállításokat hajtottunk végre. Kérjük, ez után tesztelje huzamosabb ideig.
 
Abban az esetben, ha továbbra is tapasztaltja a hibát, kérjük jelezze felénk válasz e-mailben.

"

A  levél "One <no-reply@one.hu>" címről érkezett.
Hogyan vákaszoljak rá :-O.

Bocs, kicsit kidühöngtem magam.

Digi eszközcsere után lehalnak az AP-k

Sziasztok!

Adott egy régi Digi-s előfizetés ahol jött a One és le akarta cserélni az eszközt valami digitális átállás miatt, mert csak. Korábbi felállás:
ZTE 2 ETH portos router (padláson) - 5 portos Tp-link switch (padláson) - 4db D-Link Covr 1100 wifi AP (AP üzemmódban használva a földszinten a szobákban).
Pár éven keresztül minden rendben működött. Majd jött a ONE és lecserélte a régi eszközt egy új ZTE F6600R -re. Összedugta a szerelő az új technikát majd távozott. Innentől az AP-kon keresztül nem jött net többet. Az történik, hogy a router fogja magát és lekapcsolja a LAN portját amin a switch van. Ha egy notebookot csatlakoztatok a routerra közvetlen akkor ott működik minden rendben.

Teszteltem kicsit. Lereseteltem az eszközöket és elkezdtem újra konfigurálni. Alapból a D-Link eszközök Router üzemmódban indulnak. Indítom az első eszközt, 
felkonfigolom, megy minden rendben. Csatlakoztatom a másodikat, csatlakozik, megy minden rendben. Itt megpróbálom átkapcsolni Router üzemmódból AP üzemmódba. Ekkor az eszközök újraindulnak, majd 1-2 perc múlva amikor már majdnem kész az újraindulás akkor fogja a ZTE router és lekapcsolja a portot. Ha kikapcsolom az eszközöket akkor visszakapcsolja a portot a ZTE. Ezt eljátszottuk párszor, de csak nézek, hogy mi lehet ez.
Az új ZTE eszköznek már 4db gigabites ETH portja van. Rákötöttem közvetlen - switch nélkül - az eszközöket, akkor is folyamatosan lekapcsolta a portokat.

Nézzük mi van ha a ZTE mögé berakunk egy TP-Link routert (ez volt kéznél, dupla NAT-olás). ZTE - Tp-Link Archer C6 - 4db AP.
Amíg router üzemmódban van a 4 Dlink addig látszólag jól mennek. Amint átkapcsolom AP üzemmódba akkor a legelsőnek felcsatlakoztatott eszköz látszóag normálisan működik (az ilyen cuccoknál mindig van egy fő AP, a másik 3 pedig 1-2 percenként újraindul. Látszik, hogy megszakad a ping is, valamint a tetején a fehér led sárgára vált 20-30 másodpercre majd vissza fehérre. És ez így megy a végtelenségig.

A ZTE eszköz jelenleg a padláson van (és az 5 portos switch is itt volt), a D-link eszközök pedig a földszinten a szobákban. Ezen nem is nagyon tudunk változtatni, mert így van kábelezve, a padlásra futnak össze az ethernet és a koax kábelek.

Mi történhet itt ? Lehet e valamit kezdeni a helyzettel, hogy működjön a jelenlegi technika ?

Most ideiglenesen odavittem 2db Tp-link Deco eszközt. Felkonfigoltam őket AP üzemmódba és működnek elsőre.