-
Szeretne hasonló avatart használni? A profilképként felhasználható avatarokat az alábbi linkről tudja letölteni.
rmcz
-
Tartalmak
39 -
Csatlakozás időpontja
-
Utolsó látogatás
Tartalomtípus
Profil
Fórumok
Blogok
Galéria
Articles
Bejegyzések, amit rmcz posztolt
-
-
Szia @Kohányi Róbert!
Orulok, hogy sikerult!
Ekkor: 16/03/2022 at 21:42, Kohányi Róbert írta:Az RA-val kapott IPv6 cím mellé, ha jól tudom (ez alapján a kiváló cikk alapján: https://www.networkacademy.io/ccna/ipv6/ipv6-on-windows), minden jól működő kliens randomizálja a prefix után eső részét az IPv6 címnek (MAC-ből derivált EUI-64 cím helyett), plusz Temporary Address-t is használ (azt még nem derítettem ki, hogy ez Windows specialitás vagy valami RFC definiálja ...).
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 - stableEkkor: 16/03/2022 at 21:42, Kohányi Róbert írta:Kérdésem: van-e értelme/lehet-e egy ilyen Temporary címre Pin-hole-t nyitni? Gondolom nem sok: ahogy most értem, a PC-m addig tart meg egy Temporary címet a) amíg nem jár le, b) vagy ha lejárt, akkor addig amíg valami processz vár egy response-t arra a címre, stb. (tehát kb. "átkerül" a PNAT okozta fejfájás a kliensre a router helyett kicsit - ez elég pongyola, tudom :D).
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).
Ekkor: 16/03/2022 at 21:42, Kohányi Róbert írta:Másik kérdés: nem próbáltam ki, de működne ez a Pin-hole dolog TCP portra akkor is, ha csak "Accept from remote"-ot állítok be? Nyilván kipróbálom, költői a kérdés. Ugye NAT-nál az outbound forgalom esetében "megjegyzi" a router egy ideig, hogy "kifelé kiküldött és ha válasz jön hova kell visszaküldeni azt", de mivel itt nincs NAT, ezért ha egy remote host TCP csomagját beengedi a gépemig a GPON router a Pin-hole miatt, akkor ... az én gépem elvileg már nem tud válaszolni? Mert nem Both way a beállítás ... na mindegy, ki kell próbálni, de a feltételezésem, hogy csak az odavissza beállítás lesz *****a.
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..
Ekkor: 16/03/2022 at 21:42, Kohányi Róbert írta:> 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.
Ezt totálba nem értettem: az világos, hogy annyi ICMPv6 forgalmat beenged a router (még Pin-hole nélkül is), hogy menjen a SLAAC ... erre gondoltál?
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!
-
Ekkor: 20/01/2022 at 13:56, Mothertrucker19 írta:
Huh, ez nagyon király!
Akkor majd ránézek jövőhétenBocsi 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:
-
Ekkor: 04/01/2022 at 14:40, Mothertrucker19 írta:
Köszi.
Tervben sincs ezen funkció engedélyezése?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
-
7 perce, rmcz írta:
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.
Kozben lecsekkoltam, nincs sajnos ilyen opcio az 5655v2-ben, hogy atird a LAN-on hiredett DNS szervert
Maradnak ezek:
7 perce, rmcz írta: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).
-
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.
-
1 órája, horseface írta:
Köszönöm szépen a segítségeteket. Végül magam sem tudom miként, de a plex szervert és a nas-t sikerült elérni. Az nvr-t nem, de akkor ott nyílván más gond lesz. Köszönöm mégegyszer.
Igazan nincs mit! Ha teheted, kerlek jelold megoldottnak a kerdesedet, masnak is segitve ha hasonlo problemaval szembesulnek.
-
7 perce, horseface írta:
Természetesen belső ip-ről elérhető. Köszönöm szépen a segítséget, nyomozok tovább. Szép napot nektek!
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)?
-
1 perce, horseface írta:
Természetesen így van beírva port számmal együtt. Az ont logja ezt a permission denied bejegyzést készíti ha próbálom nyitni az ip címet.
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.
-
2 perce, horseface írta:
Mutatom.
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
-
3 perce, horseface írta:
Szia! Portok természetesen szerver oldalról nyitva vannak. Fontos ezeket elérnem és nincs több ötletem... Jelentsem hibának?
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.
-
2 órája, tkarika írta:
Lenne még egy harmadik lehetőség, saját DNS kiszolgálót (pi-hole) telepíteni, viszont ez még azért nem működik, mert az ipv6-os DNS szervert nem lehet módosítani ebben a szutyokban, így az mindig kifelé mutat.
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.
3 órája, tkarika írta:Illetve, lenne még egy negyedik megoldás, pppoe passthrough-val hagyni a francba ezt a csodát, és használni egy rendes routert, de amikor ezt kipróbáltam, akkor nem volt adás a mediaboxon...
Erre a megoldas pontosan igy van ahogy @uzman leirta:
1 órája, uzman írta:Járható út ez is, csak a boxot a HGW-re kell csatlakoztatni. A dhcp szervert hagyd bekapcsolva, a PPPOE passthrough módot aktiválod és azután a saját routereddel építed fel a kapcsolatot.
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.
-
2 perce, uzman írta:
Sajnos ez egy hibas mukodese az eszkoznek
Szerintem ez nem hiba. Nem támogatja a hairpin NAT-ot.
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.
-
Szia
Sajnos ez egy hibas mukodese az eszkoznek, igy jelenleg 2 lehetoseged van:
-
Hasznalod a privat cimeket az elereshez a LANrol:
2 órája, uzman írta:
Szia
Belső hálózaton a LAN IP (192.168.xxx.xxx) címmel tudod elérni a szervert/szolgáltatást.
-
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.
-
Hasznalod a privat cimeket az elereshez a LANrol:
-
12 órája, Jamal írta:
Minimális előrelépés történt. A routerben az upnp fül alatt látom a program által létrehozott portokat de egyiket sem érem el tesztoldalakról. se tcp, se udp. Érdekes módon viszont mikor bekapcsoltam a laptopot, megjelent itt kettő port, (ami kiderült hogy az utorrenté) és azokat látják a külső ellenőrző oldalak. De semmi mást amit létrehozok.
(a képek küldönböző időpontokban készültek, ezért nincs teljes átfedés a porok között)
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).
-
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!
-
Ekkor: 11/11/2021 at 23:39, Jamal írta:
Őszinte leszek, fogalmam sincs hogy kell ezeket a programokat használni. Viszont kipróbáltam két gépen is és két játékkal is, egyiknél sincs eredmény.
A Wreckfesthez találtam egy programot ami UPnP-vel ki tudja nyitni elvileg a portokat de az sem akar működni. Bekapcsoltam a routeren az UPnP-t, újraindítottam és "Error: UPnP is not working" üzenetet dob a program ha futtatom.(holnap elutazok, legközelebb hétfő este leszek majd itthon)
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
-
15 órája, krs írta:
Szia
Köszönöm, megpróbálom.
A Technicolort nem lehet "modem" módba tenni?
Csak a routeremet érinti, nem voltam egyértelmű, nem a technicolort, hanem az asus-t kell rebootolni.
Üdv
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 ?
-
4 órája, Jamal írta:
Az UDP port tesztelésénél "Open or filtered" üzenetet kapok minden esetben, akkor is ha általam nem konfigurált portot adok meg neki.
TCP esetén "Connection timed out" az eredmény. A Wreckfest szerver a tesztek alatt futott a célgépen. A Windows tűzfalon is nyitva vannak a portok, sőt kipróbáltam kikapcsolt tűzfallal is.DHCP alapból be volt kapcsolva a routeren, így az osztotta, de próbáltam magam is beírni az IP-t és az se segített.
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.
-
2 órája, Jamal írta:
Itt a screenshot.
Az WAN IP-m jelenleg 46.107.x.x és minden router újraindításkor változik, valamint IP checknél is stimmel.
Porttesztelésre azt az oldalt is használtam amit küldtél és ezt is: https://www.yougetsignal.com/tools/open-ports/
sajnos mindkettő azt mutatja hogy zárva van.Köszi hogy foglalkozol vele!
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.
-
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).
ssh ipv6 cimmel kivulrol
itt: Hálózat
Posztolva:
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".