rmcz

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

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

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!

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.

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:

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

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

Kozben lecsekkoltam, nincs sajnos ilyen opcio az 5655v2-ben, hogy atird a LAN-on hiredett DNS szervert Maradnak ezek:

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.

Igazan nincs mit! Ha teheted, kerlek jelold megoldottnak a kerdesedet, masnak is segitve ha hasonlo problemaval szembesulnek.

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)?

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.

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

A Portscan eremeny alapjan nyitva vannak a portok az internet felol ("open ... incoming traffic allowed"), pontosan mi is a problema?

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.