rmcz

Tag
  • Tartalmak

    39
  • Csatlakozás időpontja

  • Utolsó látogatás

Minden, amit rmcz posztolt

  1. Koszi @Kohányi Róbert, jogos az eszrevetel a "Remote port" kapcsan! Uresen kell hagyni a mezot ha nem akarjuk korlatozni a forras portot! Igen sajnos erre nincs garancia, hogy ugyan azt a delegated prefixet kapod mindig . Viszont erre (is) van kitalalva a preferred lifetime es az ONT ebben az esetben a regi prefixet csak azert hirdetni, hogy ezt az erteket 0-ra csokkentse. Ezzel ugymond jelzi a LANon, hogy az nem hasznalhato tovabb. Ezt az uj prefixxel egyutt hiredeti, termeszetesen az uj prefix preferred lft erteke > 0. Windows eseteben talan nem jelzi alapbol csak mondjuk ha ipconfig /all parancsot adsz ki (az ervenytelenitett prefixek mogott ott lesz, hogy "Deprecated"). Szoval amig a valid lifetime ertek le nem jar, addig ott lesz a cim az interfacen, de csak mint "Deprecated".
  2. Szia @Kohányi Róbert! Orulok, hogy sikerult! Ez a ketto RFC irja le, a temporaryt es a nem EUI-64 alapjan eloallitott cimeket: https://datatracker.ietf.org/doc/html/rfc4941 - temporary https://datatracker.ietf.org/doc/html/rfc7217 - stable Erdemes a nem-temporaryt hasznalni pin-holing eseteben. Bar letezik olyan implementacio is ami NDP alapjan koveti, hogy milyen MAC cim van a pin-holingnal beallitott IPv6 GUA mogott es dinamikusan huzza utana a pin-holing szabalyt ha a GUA valtozik. (Ez a kepesseg nem kovetelmeny a HGW-k eseteben, csak erdekesseg). A szoban forgo eszkoznel (Sagem 5670), emlekeim szerint csak akkor mukodik a pin-holing ha a szabaly "Accept in both ways" beallitasban lett felveve. Logikailag persze mukodhetne ugy mint az IPv4 port mapping eseten, mert attol meg hogy nincs NAT, a router ugyanugy trackeli a kapcsolatokat mint a NAT4 eseten (ezert van pl. az, hogy alapbol nem talal be csomag, csak ha a LAN-rol elotte megtortent a kezdemenyezes = solicited a kapcsolat). de a gyarto igy implementalta.. Nem teljesen... SLAAChoz legingabb Router Solicitation/Advertisement kell, ezeket a WANrol nem engedi be. Inkabb az egyebb operativ ICMPv6 uzenetekre gondoltam pl.: "Time Exceeded", "Destination Unreachable", "Packet too big", "Parameter problem". Az ICMPv6 pingget oszinten szolva most igy fejbol nem tudom, meg kell neznem...
  3. Szia @Kohányi Róbert! Egy peldakonfiguracio HTTPS (TCP:443) atengedesere Pin-Holinggal: Local IP = a laptop IPv6 Address: 2001:4c4e:CCCC:DDDD:YYYY:YYYY:YYYY:YYYY, fontos hogy a Global Unicast cim legyen! ICMPv6 eseteben minden az IPv6 mukodesehez szukseges csomag betalal a tuzfalon, nincs direkt szures solicited kapcsolat eseten (az oldal allitasaval ellentetben), ezzel kapcsolatban nincs tovabbi teendo. Ketfele IPv6 prefixuk van a gatewayeknek. Van egy un. framed prefix amit az eszkoz WAN interfacen hasznal (SLAAC-cal hoz letre belole cimet) es egy un. delegated prefix, amit a LAN oldalon hasznal(hat) es hirdet (DHCPv6-PD-vel kapja meg es SLAAC-cal hirdeti a LANon), a ketto ezert kulonbozo. A LAN oldali delegated prefix egy globalis prefix, amibol egy globalis cimet eloallitva (GUA) barminemu cimforditas nelkul tudsz IPv6 tartalmakat elerni az interneten direktben az eszkozeidrol. Tehat vegulis a meglatasod helyes: "a delegated prefix "alól" tudok magamnak kiosztani címeket amik rögtön nyilvános global unicast címek lesznek rögtön" annyi kiegeszitessel, hogy a gateway csak a delegated prefixet tudja hirdetni a LAN-on, az eszkoz framed prefixebol alkotott cime (GUA) mas celt szolgal. Remelem tudtam segiteni!
  4. Bocsi pontositanom kell magamat, az elterjesztes tobb ido mint gondoltam, az utolso informaciom szerint 3-4 het mulva lesz esedekes ha nincs a firmwareben egyeb elterjesztest blokkolo hiba.
  5. Szia! A gyarto fele jelezve lett mar korabban az altalad is tapasztalt hiba (Port forwarding (mapping) nem mukodik LAN-LAN kozott, az eszkoz public IP cimet hasznalva). A gyarto a legujabb firmwareben mar javitotta a hibat, ennek a releasnek jelenleg a pilotozasa/alkalmassagi vizsgalata folyik. En azt az infot kaptam, hogy ha a pilot soran nem jelentkezik vele nagyobb problema az elterjesztes varhatoan 3-4 het mulva tortenik meg, ezutan fogod tudni hasznalni ahogy leirtad. Addig is mint workaround en azt javaslom hasznalj IPv6-ot. Az eszkozben elerheto mar az IPv6 Pin-holing funkcio, ennek segitsegevel tudod engedelyezni, hogy a kivant portokon eljusson a forgalom a kiszolgalo geped fele WAN iranybol. Ehhez kelleni fog az, hogy a domained rendelkezzen AAAA rekorddal. Igy kell konfiguralni:
  6. A gyarto javitotta a hibat, a szoftver az alkalmassagi vizsgalatok utan varhatoan elterjesztesre kerul es mukodni fog a NAT loopback, viszont csak statikus beallitasban (kelleni fog port-forwarding rule). Erdemes ranezned majd jovo heten, sajnos konkretabbat nem tudok mondani
  7. Szia @eszgabor, Az ARP(IPv4)/NDP(IPv6) alapbol engedelyezve van es nem lehet kikapcsolni sem a szoban forgo ONT-n, el kellene tudnod erni az eszkozeidet. Az FGA2233 a DHCP szerver a halozatodban? A felhasznaloi feluleten a "Devices" csempenel latod azokat az eszkozoket amiket irsz? Az eszkozeidet a privat cimukon probalod elerni, vagy esetleg IPv6-on? Induljunk el ezektol es megprobaljuk kitalalni mi lehet a gond
  8. Kozben lecsekkoltam, nincs sajnos ilyen opcio az 5655v2-ben, hogy atird a LAN-on hiredett DNS szervert Maradnak ezek:
  9. Szia @huan! A "Ez a hálózat blokkolja a titkosított DNS-forgalmat." uzenetre tudok erdemben reflektalni. Az ujabb iOS, iPadOS verziokban elerhetove valtak az un. DoH, DoT funkciok (DNS-over-HTTPS)&(DNS-over-TLS). Ez a hibauzenet azert jelenik meg pl. az adott iPhone-on, mert a halozatodban (valoszinuleg) a telekomos gateway latja el a DNS "szerver" szerepet es a benne implementalt DNS proxy nem tamogatja a DoH/DoT megoldasokat. Ennek a figyelmezteto uzenetnek, vagy maganak a DoT/DoH tamogatas hianyanak nem kellene gondot okoznia, de egy probat mindenkepp megerne ha mondjuk atirnad a gatewayben a a DHCP-vel hirdetett DNS szervert mondjuk a Cloudflare DNS szerver cimere: 1.1.1.1 (ez tamogatja a DoH/DoT-t), a router sajat privat cimerol. Ha nincs ilyen opcio a gatewayben, esetedben celszeru megadni az erintett klienseken statikusan ezt a DNS szervert (vagy mondjuk az asust betenni nem AP modban es azon futtatni a DHCP szervert + PPPoE PT - ebben az esetben majd a NAS-t is at kell tenned az asus-ra). A Synology leszakadas problemaval en is azt tanacsolnam, hogy cserelj UTP kabelt, mert a logok mind arra a portra panaszkodnak, vagy dugd at a NAS-t az asus AP-ba.
  10. Igazan nincs mit! Ha teheted, kerlek jelold megoldottnak a kerdesedet, masnak is segitve ha hasonlo problemaval szembesulnek.
  11. Bocsi, hogy nem tudok erdemben segiteni Teljesen furcsa es ellentmondasos amit tapasztalsz. Nalam ugyan ez a funkcio hibamentesen mukodik... Megnezned meg1x a portot, mondjuk ezzel a tesztoldallal is? https://portchecker.co Osszedobtam itthon egy hasonlo kornyezetet tesztnek en is, hatha segit rajonni mi lehet a gond: DHCPvel kap egy reservalt cimet a kliensem, ezen a kliensen futtatok egy HTTP szervert a TCP:8080-as porton Beallitottam egy Port Forwarding szabalyt a TCP 8080-ra: Ellenoriztem, hogy az internet felol a port elerheto-e: Nyitottam HTTP kapcsolatot a bongeszombol a publikus IP cimet, portot megadva (Ez mukodik a LAN-rol es egy masik geprol/telefonrol is egy masik internet kapcsolat felol) Van esetleg valami amiben elter a Te halozatod es erdemes lenne megnezni (a konkret privat IP cimektol eltekintve)?
  12. Koszi! Nem hiszem, hogy az oDHCP daemon IPv6 dolgainak a guest WLAN-on barmi koze lenne a problemahoz. Azt meg nezned meg, hogy az adott gepen vagy egy masik LAN kliensrol elered-e a dolgokat amiket szeretnel a bongeszon keresztul, a privat IP cimet hasznalva - 192.168.1.3:8080 ? A port forwarding szabaly valoszinuleg mukodik, mert a portscan eredmenyebol latszik, hogy a TCP handshake ki tudott epulni. En a szerverre gyanakszom, vagy az adott gep tuzfal beallitasaira.
  13. Itt az URL mogott specifikalva van a port? Alapbol a bongeszo a TCP:80 (HTTP), vagy a TCP:443(HTTPS)-re akarna csatlakozni. Portot igy tudsz megadni pl.: 188.X.X.X:8080
  14. A Portscan eremeny alapjan nyitva vannak a portok az internet felol ("open ... incoming traffic allowed"), pontosan mi is a problema?
  15. Szia! Elso korben ellenorizd, hogy nem vagy-e CG-NAT mogott. Ennek a legegyszerubb modja ha osszeveted az IPv4 cimeket mit mutat mondjuk a https://whatismyipaddress.com oldalon es mit mutat az eszkozben. Ha a ketto nem egyezik -> NATolva van a kapcsolatod (altalaban az eszkozben ilyenkor valamilyen 100.X.X.X IPv4 cimet kellene latnod). Ennek kikapcsolasat az ugyfelszolgalaton tudod kerni. Ha nem vagy NAT mogott, akkor legyszi toltsd fel milyen Port Forwarding szabalyokat hoztal letre es megprobalunk segiteni.
  16. Az IPv6 DNS-t a stateless mivoltabol nem lehet modositani (pl.:mi van ha valtozik a global prefix, stb esetek). A DHCPvel hirdetett v4 DNS-t at tudod allitani, utana a klienseken kell vagy torolni, vagy pedig atpriorizalni a DNSv6 szerver bejegyzeseket. Erre a megoldas pontosan igy van ahogy @uzman leirta: Annyi kiegeszitest tennek, hogy a PPPoE felhasznalo keruljon ki ebben az esetben a Technicolor ONT-bol elso korben, mert 2 helyrol nem tud bejelentkezni egy user/pwd kombinacio. Mivel ez szerencsere az eredeti problema egy eszkoz hiba, varhato majd ra javitas! Ami jelenleg megoldast kinalhat meg az az, hogy megprobalod felvenni a szukseges url-t/IP-cimet egy "whitelist rule"-kent a Telekom App-on keresztul, ha elerheto mar szamodra valahol ez a menupont.
  17. Igazad van, de jelenleg nem hairpin NAT-rol van szo, hanem statikus LAN-LAN port mappingrol, amit viszont tamogat az eszkoz (lasd pl. a TCP 8000 eseteben) kiveve ugy tunik a fentebb emlitett 2 portot.
  18. Szia Sajnos ez egy hibas mukodese az eszkoznek, igy jelenleg 2 lehetoseged van: Hasznalod a privat cimeket az elereshez a LANrol: Felveszel meg egy port forwading szabalyt a belso TCP:443-ra, viszont a kulso port valami mas legyen, pl: Igy el tudod erni a belso halozatrol is a publikus IP cimet hasznalva, csak ebben az esetben meg kell adnod a masik WAN portot, pl: publikusIP:8000 vagy sajatdomainem.com:8000. A kulso halozati eleres valtozatlanul mukodni fog a TCP:443-mon.
  19. Az UPnP / NAT-PMP alkalmazas csak portot nyit, ahhoz hogy ezeken valaszoljon is valami futnia kell az alkalmazasnak is. Futtasd a szerveredet azon a gepen ahol kinyitod a portokat (ergo ahol fut az upnp wizzard is = 192.168.1.16) es ellenorizd az egyik korabban javasolt tesztoldalon, hogy elered-e oket (ha lehet a TCP-t probald, elso korben kikapcsolt tuzfallal). Ha nem mukodik, akkor most mar tenyleg nem lehet mas, csak a szervered, vagy annak konfiguracioja a hibas. (Az hogy a torrent kliensed nyit maganak UPnP/NAT-PMP-vel portot es el is tudod erni kivulrol, az is azt igazolja hogy az eszkoz rendben van).
  20. Szia! Adj meg egy kezdeti IPv4 cimet a domainedhez namecheap oldalan ("A" record). Sajnos az eszkozben levo DDNS kliens DNS feloldasra hagyatkozik, hogy frissitenie kell-e az IP cimet vagy sem (ha a feloldott IP cim megegyezik az aktualis IP cimevel, akkor nem frissit). Ebbol adodoan, amikor letrehozol egy domaint, nem fogja tudni updatelni mivel ahhoz alapbol nem tartozik IPv4 cim... amint ezt athidalod mukodni fog!
  21. Furcsallom ezt az egesz dolgot, nalam mind a port mapping, mind az upnp es a nat pmp is mukodik... Tesztnek probalj portot nyitni UPnP-vel ezzel a programmal: https://www.xldevelopment.net/upnpwiz.php
  22. Szia, Tudtommal nincs "modem" mod, de a PPP-PTval kb. ugyan ott vagy, mivel ahogy az elottem szolo irta, ebben a modban a Technicolor transzparensen tovabbitja az Asus forgalmat a kiepitett PPP csoben. En is az Asusra gyanakszom, nincs valami log amit le lehet kerdezni az eszkozbol ?
  23. Hat igen, sajnos az UDP tesztelese nem annyira trivialis... Ha meg kikapcsolt tuzfallal sem megy, akkor a szerverre, vagy annak konfigjara tudok gyanakodni... Azt tudnad meg kiprobalni, hogy egy masik appal kinyitod ugyan ezeket a portokat (mondjuk ncat, vagy TCP-re python - http.server / UDP-re python - udp-test vagy barmi egyeb...) Ezzel ki lehetne zarni, hogy nem-e szerver oldali a problema.
  24. Hali! Akkor tuti, hogy nem vagy NAT mogott Ahhoz, hogy sikeresen lemenjen egy ilyen port test tobb dolognak is teljesulnie kell: Kell a megfelelo tool. Mivel javareszt UDP portokat szeretnel megnezni lehet hogy a fenti oldalak nem megfeleloek, mivel nem lehet kivalasztani, hogy UDP vagy TCP portot akarsz vizsgalni. Probald ki ezzel is: https://check-host.net/check-udp?lang=en (IP cim utan kettospont, majd a port - 46.107.X.X:27015, stb.) Futnia kell a celgepen annak az alkalmazasnak ami kiszolgalja az adott kapcsolatokat, UDP eseteben kuld is valamit vissza*. Nalad ez a gep a 192.168.1.224 IP cimu. Az alkalmazasnak kell hogy legyen jogosultsaga a geped tuzfalan portokat nyitni, a megfelelo halozati interfacen/kapcsolaton (ha mondjuk tobb is van aktiv). Ha mind a 3 pont teljesul, akkor sikeres lesz a teszt. Persze konnyen lehet, hogy nalad csak a megfelelo tool hianya miatt nem "sikerultek" a tesztek, de ettol fuggetlenul a port mapping szabalyok jok lehetnek! *Az UDP port teszteles egy kicsit bonyolultabb mint a TCP. Elkepzelheto, hogy az alkalmazas nem kuld vissza semmit ha megszolitjak azokon a portokon es ettol a teszt oldal tekintheti zartnak (filtered) vagy akar nyitottnak is, bovebb info itt. Ha a TCP portot sikeresen le tudod tesztelni akkor igazabol mar jo vagy, mert a tobbi port forwarding szabaly is ugyan arra a gepre mutat.
  25. Szia @Jamal! Tudnal egy screenshotot kuldeni a beallitott port forwarding szabalyokrol? Milyen port forwarding tester-t hasznalsz? (en ezt ajanlom https://portchecker.co) Legegyszerubben ugy tudod megnezni, hogy NAT mogott van-e az eszkozod, hogy osszehasonlitod az IP-t, amit a eszkozben latsz es amit mondjuk ezen az oldalon https://portchecker.co vagy itt https://whatismyipaddress.com (ha 100.X.X.X latsz IPv4 cimnek, akkor NATolva vagy).