sipsza

Tag
  • Tartalmak

    16
  • Csatlakozás időpontja

  • Utolsó látogatás

sipsza a fórumon

  • Rang
    Tudományos tag
    10+
    10+

    Telefon guru

    Otthon vagyok a telefon témakörben, az előző 90 nap alatt ennyit posztoltam

    10+
    10+

    Mobil guru

    Otthon vagyok a mobiltelefon témakörben, az előző 90 nap alatt ennyit posztoltam

    10+
    10+

    Egyéb guru

    Otthon vagyok a Telekom ügyintézéssel/ a Telekom fórummal kapcsolatban, az előző 90 nap alatt ennyit posztoltam

  1. @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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. Szia! Szerintem kicsit kevered a fogalmakat. A DNSCrypt, DNS over HTTPS, DNS over TLS többé-kevésbé különböző protokollok, de mindegyik célja a géped és rekurzív címfeloldó szerver (8.8.8.8, 1.1.1.1) közti kapcsolat titkosítása. Titkosítás alatt azt értem, hogy a lekérdezést más nem látja és nem is tudja meghamisítani. Ezeket a weboldalaknak nem kell támogatniuk, csak a kliensnek és a rekurzív címfeloldónak. DNSCrypt: nem elterjedt; 443-as portot használja, de nem TLS alapú DNS over TLS: elterjedt; 853-as portot használja; TLS-be csomagolt DNS DNS over HTTPS: elterjedt; 443-as portot használja, ezért jobban átmegy a tűzfalakon, mint a DoT; TLS-be csomagolt HTTP-be csomagolt DNS vagy TLS-be csomagolt HTTP-be csomagolt JSON; úgy látom, hogy a chrome és a firefox csak ezt támogatja A rekurzív és az authoritative szerverek közötti kapcsolat nincs a fenti módokon titkosítva, de említsünk meg 2 technológiát: DNSSec: így tudsz meggyőződni, hogy az authoritative szerver válaszát nem hamisították meg; a nagyobb rekurzív szerverek ezt leellenőrzik helyetted, ezért neked ezzel nem kell foglalkoznod (feltéve, hogy megbízol bennük és a kapcsolatod velük titkosított); a támogatottsága domainenként eltérő, van olyan TLD, ami egyáltalán nem támogatja Query name minimisation: a rekurzív szerver a lehető legkevesebb információt küldi az authoritative szervereknek; például piros.autok.hu esetén, a hu-t kiszolgalo szerver nem fogja megtudni, hogy te az autók közül a pirosakat szereted
  9. Köszönöm a választ! Végigmentem a TCP portokon 1-65535 4 különböző helyről: DigitalOcean VPS, U_P_C, egyetemi (HBONE) és céges hálózat. A következő portok egyik helyről sem elérhetőek. Befele: 639 - MSDP 646 - MPLS LDP 711 - MPLS Cisco TDP 7547 - TR-069 CWMP 8085 - DSLForum CPE Management 30005 - TR-069 (nekem másra kell, de gondolom a TR-069 az oka) 51005 58000 Kifele: 25 - SMTP (ezt megértem) 646 - MPLS LDP 711 - MPLS Cisco TDP Érdemes abban reménykednem, hogy kérésre feloldják a befele irányú blokkolást?
  10. Sziasztok! Más sem kapja meg a 30005/TCP-re érkező csomagokat? TCP 30004 és 30006 jó, de a 30005 nem. A mindenkori blokkolt kimenő/bejövő portok listája elérhető valahol? Sagemcom F@st 5655v2 AC ONT-t használok PPPoePassthrough módban, fw: SG3G10000494. Biztosan nem a routerem tűzfal/nat beállításaival van gond, mert még azok előtt, közvetlenül az ethernet interface-en nézem a csomagokat.
  11. Azt azért érdemes lenne megemlíteni, hogy a szolgáltatók nem puszta kiszúrásból nem engedik, hogy saját ONT-t használj. A GPON nem DSL, itt nincs egy dedikált vonalad a központig, hanem van egy gerincvonal, amire több tucat előfizető csatlakozik. A leagázásokat prizmákkal és tükrökkel oldjak meg, nincs semmi aktív védelem. A központi eszköz (OLT) mondja meg az ONT-nek, hogy mikor küldhetnek jelet, hogy egymást ne zavarják. Ha valaki egy inkompatibilis ONT-t próbálna használni, lehet, hogy az egész utcában szolgáltatáskiesést idézne elő. Megjegyzem, nem tudom, hogy mekkora különbség van ONT és ONT között. Tekintve, hogy a Telekom is 2 féle ONT-t használ. Én annak örülnék, ha a Telekom is moduláris CPE-t (pl.: Bell Home Hub 3000) adna. Így akinek nem kellene a körítés (a velük járó bugokkal együtt), annak lenne egy biztosan kompatibilis SFP ONT-je.
  12. Frissítés 2. Cseréltek nálam ONT-t (egy másik hiba miatt). A típusa és a fw nem változott, és sajnos a hiba sem. Észrevettem, hogy a következő hibaüzenet jelenik meg a logok között az ONT-n, amikor megérkezik egy ACK a szervertől: [ERROR pktrunner] add_fwd_commands,502: Unable to determine if the flow is routed/bridged (502) Valaki meg tudná mondani, hogy milyen csatornán érdemes az ilyen jellegű hibákat bejelenteni?
  13. Ha a HGW és a STB más alhálón van, akkor elsősorban IGMP Proxyra lesz szükség. Az IGMP Snooping csak a többi eszközt védi a kéretlen multicasttól. @Sanyi85 Ha nem feltétlenül akarod a STB-ot a LAN oldalra rakni, csak nem akarsz egy külön vezetéket húzni a HGW-ből, akkor érdemesebb a router egyik sárga portját átkapcsolni a WAN oldalra, és abba dugni a STB-ot. Nem ismerem a te routeredet, de a VLAN (nem WLAN) vagy a switch beállításokat keresd.
  14. Pontosan mi is akarna lenni ez a bridge mode? Nálam semmin nem változtat, PPPoE Passthrough ide vagy oda. Nekem ezek a beállítások váltak be saját router használatához: - PPPoePassthrough: bekapcsolva - Log-In: üresen hagyva - Password: üresen hagyva - Connection Trigger: manual Nem kellet hívnom az ügyfélszolgálatot, és az újraindítást is túléli.
  15. Egy kis frissítés, hátha jól jön még valakinek. Szereztem egy VPS-t natív IPv6-tal, hogy lássam, hogy a szerver melyik csomagokat kapja meg. - a 3-way handshake megtörténik sérülésmentesen, ha otthonról indítom a TCP kapcsolatot; de a fordított esetben nem kapom meg a VPS-töl az ACK-ot - a VPS minden csomagot megkap a klienstől - a PSH, RST, FIN csomagok megérkeznek a klienshez - az üres ACK-ok nem érkeznek meg a klienshez Ezután megnéztem, hogy mi történik a router ONT felőli ethernet interfészén. (Nem tudom, hogy ez korábban miért nem jutott eszembe.) Az üres ACK-okat tartalmazó csomagok is megérkeznek, de a PPPoE headerben a csomagméret eltér a valóstól (pl.: 106 helyett 2123, 94 helyett 1915), ezért a router PPPoE drivere eldobja. Kíváncsiságból csináltam egy pár GB-os IPv4 packet capturet, amiben volt web, torrent, tcp, udp, de a PPPoE header sehol sem volt sérült. Megpróbáltam a Hurricane Electric helyett a VPS felé kiépíteni tunneleket: - 6in4 tunnel esetén az eddigi hibát tapasztalom - 4in4 = IPIP: minden ok - GRE-n belül nekem az IPv4 és az IPv6 is ok, mással ellentétben Találtam valakit, akinek ugyanilyen problémája volt, de másik szolgáltatónál: Problem with 6to4 inside PPPoE