sipsza

Tag
  • Tartalmak

    24
  • Csatlakozás időpontja

  • Utolsó látogatás

sipsza a fórumon

  • Rang
    Tudományos főtag
    10+
    10+

    Népszerű

    Népszerű vagyok, a fórum indulásától a kérdéseimre, válaszaimra ennyi elismerést kaptam a fórumtagoktól.

  1. @Halacs "ONT csere nem segítene, ezt külön egyeztette a fejlesztőkkel (látta ezt a threadet). Ha nem lenne tiltva területileg az IPv6 akkor menne a nálam lévő ONT-vel is." Az én (megalapozatlan) feltételezésem az volt, hogy ha nincs aktiválva a központban az IPv6, akkor egy új sorozatszámú ONT felregisztrálása aktiválja. Ha a központban minden jó, akkor az ONT nem akadály. "Ezt követően jött az SMS, hogy ők nem találtak a saját hálózatukban hibát, ellenőrizzem a saját eszközeimet." Nem értem ezt a hibajegy lezárási kényszert. Miért nem lehet nyitva hagyni, amíg ténylegesen meg nem oldódik a probléma? Az őszi ETA nagyon kényelmes nekik, mert addigra a lezárt hibajegyedet már meg sem tudod nézni. Nem mintha lenne mire hivatkoznod, mert minden lényeges információt mellékcsatornákon kaptál tőlük. Így majd kezdhetsz mindent elölről. Olyan érzésem van, hogy a Telekomnak az internet csak a webből (IPv4, TCP/UDP, DNS/HTTP(S)) áll. Ha ezeken kívül működik más is, érezd magad megtisztelve.
  2. Nekem 3 hónapig mondogatták, hogy náluk minden rendben. Kértem, hogy nézze meg egy szerelő is, ha már nekem nem hisznek. Ő végül kicserélte az ONT-t (egy teljesen ugyanolyanra), és onnantól ment minden. Azóta többen is megkerestek, akiknél szintén csak az ONT csere volt a megoldás.
  3. @Halacs Igen, az ipv6cp filter mutatná a választ is. Nem tudom, hogy egy sima újraindítás után letölti-e újra az ONT a konfigot. Biztos, ami biztos alapon csinálj egy factory resetet.
  4. @Halacs Az fe80-as címet nem a Mikrotik generálja, hanem a szolgáltatótól kellene kapnod IPV6CP-n (Point-to-Point Protocol IPv6 Control Protocol) keresztül. Futtasd a Tools > Packet Sniffert a PPPoE interface-hez tartozó ethernet interface-en miközben újracsatlakozol. Azt fogod látni, hogy a routered küld egy IPV6CP konfigurációs kérést, de nem kap rá választ. Ha az ONT reset nem segített, kérj ONT cserét.
  5. Szia! Meddig jutottál el? Az első lépések nagy vonalakban: a PPPoE kapcsolathoz tartozó PPP profilban engedélyezni kell az IPv6-ot (use-ipv6 = yes) ezután már a PPPoE interface kapni fog egy v6 címet is, IPv6 > Addresses alatt tudod ellenőrizni, valószínűleg neked is fe80::b lesz DHCPv6-on keresztül kell kérned egy prefixet. Csak prefixet, címet nem, mert különben nem kapsz választ. ebből a prefixből kell címeket osztanod az eszközeidnek Ha a PPPoE interface nem kap címet (nem kapsz választ az IPV6CP kérésre), akkor a T-nél lesz valami. Jelezd nekik, hogy szeretnél IPv6-ot használni. Miután beállították csinálj egy 30+ másodperces ONT resetet. Ha ezután sem lesz jó, kérj egy ONT cserét. Az ONT elvileg nem befolyásol semmit, de az én esetemben a PPPoE szerverük addig nem akarta letölteni az új beállításokat, amíg egy másik ONT-t fel nem regisztráltak.
  6. @Halacs Szia! Úgy néz ki, hogy a Broadcom pktrunner nevű kernelmoduljában van a hiba. (A Sagemcom ONT-ben Broadcom SoC van.) A Broadcom a hibát már rég javította, de hozzánk valahogy még nem ért el. Írtam több emailt is a Telekomnak, bennük a hiba részleteivel és a feltételezett okkal. Egyikre sem kaptam választ. Felhívtam az ügyfélszolgálatot. Ott azt mondták, hogy ha kapnak új firmware-t a Sagemcomtól, akkor azt egyből megkapjuk mi is, de jelezni nem fogják a hibát a Sagemcom felé. Írtam a Sagemcomnak, hogy tudnak-e a hibáról, és, hogy a SG3G10000494-e a legújabb firmware. Megkérdezték, hogy ki a szolgáltatóm, majd ők sem válaszoltak többet. Ez volt február elején, azóta semmi fejlemény.
  7. Szia! Nem hiszem, hogy találsz ilyen beállítást. Biztos vagy benne, hogy csak a HGW gyorsítótáraz, és pl. az oprendszered nem? Lehet, hogy a HGW nem is a gyorsítótárat használja, hiába nincs interneted. Nálam az ONT akkor is válaszol a DNS lekérdezésekre (nem a cache-ből), ha nincs aktív PPPoE kapcsolat. Az általad említett heurisztika mennyire fix? Lehetne esetleg?: Pingelni a DNS lekérdezés helyett. Egyből egy távoli DNS szervernek küldeni a lekérdezést. Alacsony TTL-lel rendelkező rekordot lekérni, remélve, hogy a HGW tiszteletben tartja azt. Például raw.githubusercontent.com -nál 30 másodperc a TTL, de sok másik CDN esetén is <1 perc. Olyan domaint lekérdezni, ami biztosan nincs a cache-ben. Pl. [minden alkalommal más random string].com, vagy ha az NXDOMAIN válasz nem jó, [minden alkalommal más random string].tumblr.com
  8. @Tim András Nálam optikán a bekötés óta (2016) működik a PPPoE passthrough, IPTV és VoIP mellett, nincs szükség dupla NAT-ra. Api1977 problémáját szerintem VLAN-okkal lehet elegánsan megoldani: nem terheli a router processzorát, mint az IGMP Proxy, mert még a 10+ éves SOHO routerekben is van VLAN képes hardwares switch nem rakok egy olyan eszközt (az STB) a tűzfallal védett belső hálózatomba, ami felett semmi kontrollom nincs kevésbé érzékeny arra, ha a szolgáltató módosít valami beállítást. Semmi sem garantálja, hogy a T holnaptól nem fogja az öt legnézettebb csatorna adását broadcaston küldeni. A fentiek fényében szomorú, hogy a legtöbb SOHO routeren nem, vagy csak korlátozottan lehet hozzáférni a switch/VLAN beállításokhoz a gyári firmwarrel.
  9. @McBelaba Nálam Androidon van egy PPP interface a szolgáltató felől, és a wlan hotspot. Mindkettő ugyanabból a /64 prefixből használ egy-egy címet, és a hotspotra csatlakozott eszközöknek is ezt a prefixet hirdeti ki.
  10. DHCPv6-on szerintem nem fogsz címet kapni, legfeljebb prefixet. Ha cím kell, akkor használj SLAAC-et, mint a Windows és a Debian. Nekem PPPoE-n keresztül, Mikrotik routerrel stabilan megy az IPv6 (IPTV és Telefon mellett). Szívesen segítek, de sok apró beállítás kellhet, ezért jobb lenne, ha valósidőben tudnánk beszélni egymással.
  11. HTTP-nél, TLS-nél bevett szokás, hogy egy IP cím alatti szerver több oldalt szolgál ki. Hogy melyiket, azt a host/SNI mező alapján dönti el. Gondolom azt akarták, hogy a DoH/DoT könnyen integrálható legyen a meglévő rendszerekbe. Így egy URL-t vagy domain nevet mindenképp meg kell adnod. Firefoxnál te magad is megadhatod a DNS szerverek IP címeit. Androidnál szerintem nem akarták ezzel bonyolítani a felhasználói felületet. Amúgy semmi sem garantálja, hogy a domain mögötti IP cím nem fog változni. Főleg, ha az nem egy jól csengő IP, mint az 1.1.1.1 vagy a 8.8.8.8.
  12. A sima DNS-t nem tilthatod teljesen, mert valahogy le kell kérdezni a 1dot1dot1dot1.cloudflare-dns.com -hoz tartozó IP címet. Firefoxnál erre a tyúk vagy a tojás problémára a network.trr.bootstrapAddress volt a megoldás, de most már választhatsz. Ezek pontosan mit oldottak meg? Az SSL1, SSL2, SSL3, TLS1.0, TLS1.1 azért vannak tiltva alapból, mert törhetőek. Ha ezeket engedélyezed, nem az lesz a legnagyobb problémád, hogy megtudják, melyik oldalakat látogatod. Fontos megemlíteni, hogy a DoT/DoH nem teljes körű megoldás a weboldalak címének elrejtésére. Ha HTTP-t használ az oldal, akkor a teljes lekérdezés (többek között a host header is) titkosítatlan lesz. Ha HTTPS-t, akkor a TLS Server Name Indication (SNI) tartalmazni fogja a domaint. Ez a legtöbb esetben még titkosítatlan. A TLS1.3 óta van lehetőség titkosítani (Encrypted SNI), de jelenleg csak a Firefox támogatja, az is csak részben. Emellett a weboldalak üzemeltetőinek is tenni kell azért, hogy működjön az ESNI.
  13. Firefoxban sikerült összehozni? Azóta kijött a 74-es verzió, ezért elég a network.trr.mode-ot 3-ra állítani. Android: Settings → Network & internet → Advanced → Private DNS → Private DNS provider hostname = 1dot1dot1dot1.cloudflare-dns.com A többivel nem tudok segíteni.
  14. Leellenőriztem az UDP portokat is. Befele blokkolt: 520 - RIP 646 - MPLS LDP Kifele blokkolt: 520 - RIP 646 - MPLS LDP 711 - MPLS Cisco TDP? 1985 - Cisco Hot Standby Router Protocol 3222 - Gateway Load Balancing Protocol 4791 - IP Routable RocE A felsorolt protokollok egy részét a routerem nem is ismeri, de mindegy is, mert még azelőtt nézem csomagokat, hogy a tűzfal vagy egy protokoll daemon elkapná őket.
  15. Unicast: Van egy szerver egy IP címmel. Bárki bármikor bárhonnan küld egy csomagot arra az IP címre, akkor azt az a szerver fogja megkapni. Egyik hátránya, hogy az az egy szerver nagy terhelést kap (erre vannak megoldások). Másik, hogy az a szerver egy fix helyen van, emiatt lesznek olyan helyek a Földön, ahonnan magas lesz a válaszidő. Anycast: Van sok szerver szétszórva (pl. minden fővárosba), akik mind kihirdetik, hogy ők az 1.1.1.1. Ha küldesz egy csomagot az 1.1.1.1-re, akkor azt valamelyik megkapja, általában egy közelben lévő. Hátránya, hogy ha van két szerver hasonló távolságra, akkor lehet, hogy két egymás utáni csomagot két különböző szerver fog megkapni. Ez nem gond a klasszikus udp DNS-nél, ahol egy csomagba belefér ez egész lekérdezés. Azonban gond lehetne TCP, TCP+TLS esetén, ahol 3+ csomagot küldesz a szervernek csak, hogy felépüljön a kapcsolat. A gyakorlatban a rövid életű tcp kapcsolatok (dns, weboldalak forrásai) nagyon ritkán szakadnak meg emiatt, ha mégis, akkor a kliens újrapróbálja. A beállításokra visszatérve: Ha vannak mobil eszközeid, amiket nem csak a routered mögött használsz, akkor azokon mindenképp állítsd be a DoH/DoT-t. Érdemes magát az operációs rendszert beállítani, hogy használja ezeket. Android 9+ támogatja és elvileg a Win10 is. A Chrome linuxon nem engedi ezt böngésző szinten beállítani, ezért abban nem tudok segíteni. A Firefoxnál (mobilon is megy) nekem ezek kellettek: network.trr.mode=3, network.trr.bootstrapAddress=1.1.1.1 . A bootstrapAddress a network.trr.uri IP címe, Firefox 74-nél már nem fog kelleni. A routered nem ismerem, ha másképp nem, OpenWRT-vel (+stubby/unbound) megoldható, hogy a belső hálózatodon maradjon a klasszikus DNS, és csak azon kívül használj DoT-ot. Rekurzív címfeloldás röviden: autok.hu. esetén megkérdezzük gyöké_r authoritative szervereket (.) . Ezeknek a címe be van égetve és biztosan támogatják a DNSSec-et. Ezek megmondják, hogy a hu. -t melyik szerver szolgálja ki és azt, hogy az támogatja-e a DNSSec-et. Ezután megkérdezzük, a hu. -t kiszolgáló szervert, hogy az autok.hu. DNS szerverének mi a címe és, hogy az támogatja-e a DNSSec-et. Végül megkérdezzük az autok.hu. DNS szerveret az autok.hu címéről. Látszik, hogy ha egy domain nem támogatja a DNSSec-et, akkor annak az aldomainei hiába, mert a rekurzív szerver csak a gyöké_r szerverekben bízik feltétel nélkül és a bizalmi lánc megszakadt. Bár vannak próbálkozások a HTTPS megerősítésére DNS (és szükségképpen DNSSec) segítségével, a HTTPS-hez nem kell DNSSec. Fordítva is igaz, az interneten nem csak a webből áll, a DNS szervereken sokféle bejegyzést lehet tárolni, amiket ugyanúgy szeretnénk védeni.