Kohányi Róbert

@rmcz Szerintem nálam van valami bibi. A beépített Intel-es Wi-Fi adapterem alapból csak akkor volt hajlandó IPv6 címet felvenni a routertől, ha disable/enable kört futottam az adapter beállításaiban (macOS simán működött, meg Androidos teló is). ipconfig /all meg Get-NetIPAddress -AddressFamily IPv6 -InterfaceAlias Wi-Fi se dobott ki Deprecated címeket, csak Preferred-et, de az meg nem változott. Mindenesetre köszi az infót! Világos így hogyan kéne működnie, majd újraindítom vmelyik nap a router és figyelem mi lesz (úgy tudom akkor mindig új delegated prefix-t kapok).

Bocsi a megkésett válaszért, köszi az infókat @rmcz! > 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 Világos. Azt kipróbáltam, hogy a pinholing beállítás megy stable/temp címmel is. Azt nem, hogyha változik a temporary cím, akkor "követi-e" ezt a router a beállításokban (meglennék lepve ha megtenné xD). > emlekeim szerint csak akkor mukodik a pin-holing ha a szabaly "Accept in both ways" beallitasban lett felveve Leteszteltem és az "Accept from Remote" is működik. Plusz, vért izzadva, de azt hiszem értem hogyan működik a pinholing ebben a router-ben (lehet máshol másképpen, ennél csak logikusabb lehet - olyan ez, mintha általános iskolások csinálták volna internet órán) Amit korábban linkeltél képen a beállítás viszont nem jó (ha a Remote Port is 443 akkor kakukk, csak szökő évente működik majd). * A Local IP igen valóban egy global unicast cím, a stable vagy a temp, ez tök OK * A Local Port a helyi webszerver portja 80, 443, vagy amit csak akarunk, vagy másképp a küldő oldalról nézve a destination port a TCP csomagban headerben (tehát, ha mondjuk azt mondom egy távoli gépen, hogy "curl valami.com:12345", akkor 12345 a Local Port, ha a szerveren, célgépen az 12345-es porton figyel valami) * A Remote IP az a távoli gép IPv6 címe, global unicast megint csak (ahonnan kiadom mondjuk hogy "curl valami.com:12345") * A Remote Port pedig a küldő oldalról nézve a source /local port a TCP csomagban headerben, és elérkeztünk a lényeghez, ha én kiadom a forrás gépen, hogy "curl valami.com:12345" akkor hiába írom be a Local és Remote Port-okhoz az 12345-öt, ha a forrás gépen nem az 12345-es helyi port lett random választva a küldéshez. "curl --local-port 12345 valami.com:12345" formában működik a cucc, mert kierőszakolja a dolgot, hogy 12345 legyen a source port a csomagban. A pinholing beállíásokban egyébknt a Local IP, Remote IP, Local Port, Remote Port lehet üres, így mindent enged mindenhonnan (úgy tűnik ha *-ot vagy 0-át írok be kézzel akkor elfogadja, de mintha nem működne ilyenkor ... üresen kell hagyni ). Végülis így jöttem rá, hogy nem external/internal portokra kell gondolnom, mint IPv4 PAT esétben ... túl ráállt az agyam. Ez lentebb úgy működik ahogy kell. Csalóka, hogy ez az állapot akkor látszik ha meglévő szabályt szerkeszt az ember, a Remote IP és Port * és 0, de új létrehozásánál inkább ezek maradjanak üresek, mentés előtt ki kell törölni őket vagy jól kitölteni és úgy menteni. Magic! Pár PowerShell parancs az utókornak: Vágólapra dobja a stabil címet, ha az aktív hálózati interfész alias neve "Wi-Fi" (gondolom ez szokott lenni Windows-on). $(Get-NetIPAddress -AddressFamily IPv6 -InterfaceAlias Wi-Fi -PrefixOrigin RouterAdvertisement -SuffixOrigin Link).IPAddress | Set-Clipboard Ez a kettő meg létrehoz/töröl tűzfal bejegyzést, hogy bejusson a célig a TCP csomag (nincs szükség IPv6 varázslásra és csak admin promptból működik). New-NetFirewallRule -DisplayName "TCP 8080" -Direction Inbound -Protocol TCP -LocalPort 8080 -Action Allow Remove-NetFirewallRule -DisplayName "TCP 8080" Ami meg még ilyen watch out kategória, hogy újra indult a routerem áramszünet miatt a héten és más lett a delegated prefixem, de szemmel nem is tűnt fel (szia IPv6 xD) viszont a laptopomat se érdekelte a váltás és a Wi-Fi interfészemnek vígan megmaradt a korábban bekonfigurált IPv6 global unicast cím ...

Köszi @rmcz! Sikerült véghez vinni a dolgot, el tudtam érni "kívülről" IPv6-os cím alapján a gépem. Azért van egy-két kérdésem még, illetve észrevételem. > fontos hogy a Global Unicast cim legyen 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 ...). 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). 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. > 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? Ide kapcsolódóan: ICMPv6 pinget nem tudtam életre kelteni, sehogy, hiába nyitom meg a Pin-hole beállításokban. Lehet tudni a Telekom szűr bizonyos csomagokat? Vagy a router "ilyen és kész"? Fontos: hogy Windows tűzfalat vagy le kell kapcsolni, vagy átengedni rajta adott TCP portra a forgalmat, különben ugrik minden (azoknak írom, akik rátalálnak erre a thread-re). Annyira kell figyelni, hogy külön nem lehet megmondani a Windows-nak a Windows Defender tűzfalban, hogy mondjuk CSAK az IPv6-os TCP forgalmat engedje be (legalábbis nekem nem sikerült). > 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. Hmm, framed prefix, máris okosabb vagyok, köszi. Így, hogy "működik" a cucc, már kezd világosodni. Amíg hinni kell abban, hogy működik ezaz egész, addig > a gateway csak a delegated prefixet tudja hirdetni a LAN-on, az eszkoz framed prefixebol alkotott cime (GUA) mas celt szolgal. Got it, köszi. Minden világos(osabb mint tegnap :D).

Szia @rmcz, hasonlóval próbálkozok, mint korábban @salt!. Nekem Sagemcom F@ST 5670-esem van, van IPv6 Pin-holing funkcióm. Delegated Prefix: 2001:4c4e:AAAA:BBBB::/64 Lan IPv6 Address: fe80::12d7:b0ff:feb7:bcf2 Wan IPv6 Address: 2001:4c4e:AAAA:BBBB:XXXX:XXXX:XXXX:XXXX A laptopom ezeket kapja: IPv6 Address: 2001:4c4e:CCCC:DDDD:YYYY:YYYY:YYYY:YYYY Temporary IPv6 Address: 2001:4c4e:CCCC:DDDD:ZZZZ:ZZZZ:ZZZZ:ZZZZ Link-local IPv6 Address: fe80::a05f:f91e:25f9:d10e Gateway: fe80::12d7:b0ff:feb7:bcf2 (a Lan IPv6 cím fentről) Pár kérdés a teljesség igénye nélkül Mit kell beállítani a Pin-holingban, hogy kívülről betaláljanak a csomagok a gépemre? ICMP-nál világos, hogy nem kell port: mi az Internal és External cím? Próbáltam Internal-nak a laptopom címeből mindet belőni, de semmit ... az External-nál pedig hagytam üresen vagy próbáltam a fenti Wan IPv6 címet, de mindhiába Accept Both Ways választottam a tiltás/engedélyezés irányánál Próbáltam ICMP helyett TCP-t is (indítottam a 8000-es porton egy webszervert, de semmi: ezzel próbáltam csekkolni miújság: http://www.ipv6scanner.com/cgi-bin/main.py) Miért van, hogy a delegated prefix-be nem esik bele a Wan cím? Nekem ez furcsa, (még) nem vágom hogyan működik ez az egész IPv6-osdi, de nem az lenne a lényeg, hogy a delegated prefix "alól" tudok magamnak kiosztani címeket amik rögtön nyilvános global unicast címek lesznek rögtön? Mi a célom? Szeretném ha ICMPv6 üzeneteket nem szűrné a routerem (https://ipv6-test.com/, itt azt kapom szűri) Szeretnék a hálózatomban futó PC-n elérni IPv6-on keresztül egy-két webszerver, tesztelés a cél De legfőképp, szeretnék végre kiokosodni IPv6-ból, mert az IPv4-et nagy nehezen kitanultam (2 bukott félév Hálózatokból az egyetemen és 10 év IT után már tudok eleget, amivel boldog vagyok, de az IPv6-hoz csak most kezdtem szagolni) Köszi minden infót!

Köszi szépen! Ez alapján azt látom, hogy a Broadcom bikább, mint ami ami a Deco-ban van. Itt van részletesebb infó a BCM68360-ről: https://wikidevi.wi-cat.ru/Broadcom/SoC Itt meg a Deco M4R-ről http://en.techinfodepot.shoutwiki.com/wiki/TP-LINK_Deco_M4R, illetve itt van infó a benne lévő chipről: https://compex.com.sg/wp-content/uploads/2019/01/wpj564-6a01-v1.3-wh-180.pdf Ha bárki olvassa ezt, annak még tudom ajánlani a Deco M4R-t mesh AP-nek, arra kiváló (a Sagemcom antennái nem tudnak áthatolni a beton födémen).

Sziasztok! Keresgételm a neten, de nem találtam semmi datasheet/technikai paraméterekhez hasonlót. Olyan adatok érdekelnének, mint, hogy milyen chipset van benne, CPU teljesítmény, memória mennyisége, stb., ami van. Tud valaki ezekről bármit? (Miért érdekel: van egy Deco M4-em, és ha ezt használom fő routernek, ez végez "mindent", olyan mintha nem bírná, míg a Sagemcom igen és szeretném látni mik az utóbbi paraméterei, kíváncsiságból.)