Ugrás a tartalomhoz
  • 0

ssh ipv6 cimmel kivulrol


salt

Kérdés

Sziasztok,

Hogyan lehet kívülről elérni egy eszkozt ipv6 cimmel? Csatlakozik a Telekomos reouteremhez egy Raspberry Pi, amit ssh-val kezelek.

Helyi hálózatról elérem mind az ipv4, mind az ipv6 címével:

  • ssh pi@192.168.0.N
  • ssh pi@2001:...:...

Kívülről a public ipv4 cim elérhető port forwardinggal, viszont az ipv6-ot sehogyse tudom működésre bírni:

  • ssh pi@N.M.O.P
  • ssh pi@2001:...:... nem múködik :|

A kerdeseim:

  1. miert nem tudok be ssh-zni az ipv6 cimre kivulrol?
  2. a kiosztott ipv6 cim dinamikusan valtozik, akarcsak a publikus ipv4 cim?
Link kommenthez
Megosztás más oldalakon

13 válasz erre a kérdésre

Ajánlott posztok

  • 0

Szia @salt!

IPv6 eseteben kelleni fog az IPv6 Pin-Holing funkcio, amit sajnos nem minden Telekomos gateway(router) tamogat. Alapertelmezetten a gateway IPv6 tuzfala nem enged at forgalmat az internet felol IPv6-on, kulonben minden eszkozod elerheto lenne. Leegyszerusitve az IPv6 Pin-Holing az IPv4 Port Forwarding (=Port Mapping) megfeleloje, mivel IPv6 eseteben nincs NATolas.

Valasz az alabbi kerdesedre: "a kiosztott ipv6 cim dinamikusan valtozik, akarcsak a publikus ipv4 cim?"

  • Igen, sajnos ez fuggetlen a Fix IP szolgaltatastol tudtommal. A delegalt IPv6 prefix (amit a gateway oszt a LANra Router Advertisement-tel (SLAAC)), valtozhat.

Milyen eszkozod van konkretan ?

 

 

Link kommenthez
Megosztás más oldalakon

  • 1

Szia @Kohányi Róbert!

Egy peldakonfiguracio HTTPS (TCP:443) atengedesere Pin-Holinggal:

Screenshot 2022-01-24 at 12.26.24.png

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!

 

Szerkesztve ekkor: Szerkesztő: rmcz
pontositas
Link kommenthez
Megosztás más oldalakon

  • 1

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 :D). 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!

SharedScreenshot.jpg

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

Szerkesztve ekkor: Szerkesztő: Kohányi Róbert
Extra info
Link kommenthez
Megosztás más oldalakon

  • 0
Ekkor: 10/31/2021 at 15:18, rmcz írta:

Szia @salt!

IPv6 eseteben kelleni fog az IPv6 Pin-Holing funkcio, amit sajnos nem minden Telekomos gateway(router) tamogat. Alapertelmezetten a gateway IPv6 tuzfala nem enged at forgalmat az internet felol IPv6-on, kulonben minden eszkozod elerheto lenne. Leegyszerusitve az IPv6 Pin-Holing az IPv4 Port Forwarding (=Port Mapping) megfeleloje, mivel IPv6 eseteben nincs NATolas.

Valasz az alabbi kerdesedre: "a kiosztott ipv6 cim dinamikusan valtozik, akarcsak a publikus ipv4 cim?"

  • Igen, sajnos ez fuggetlen a Fix IP szolgaltatastol tudtommal. A delegalt IPv6 prefix (amit a gateway oszt a LANra Router Advertisement-tel (SLAAC)), valtozhat.

Milyen eszkozod van konkretan ?

 

 

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 :D

  • 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? :o 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!

Szerkesztve ekkor: Szerkesztő: Kohányi Róbert
Typo
Link kommenthez
Megosztás más oldalakon

  • 0

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

 

Link kommenthez
Megosztás más oldalakon

  • 0

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

 

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

 

Link kommenthez
Megosztás más oldalakon

  • 0

Koszi @Kohányi Róbert, jogos az eszrevetel a "Remote port" kapcsan! Uresen kell hagyni a mezot ha nem akarjuk korlatozni a forras portot!

18 perce, Kohányi Róbert írta:

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

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

address timers.png

 

Link kommenthez
Megosztás más oldalakon

  • 0

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

Link kommenthez
Megosztás más oldalakon

  • 0

Sziasztok!

Sagemcom 5670-esem a routerem egy 1/1-es nethez.

Próbálnék egy pinholing szabályt összekalapálni, de nagy az ellenállás.

így összeállítom az adatokat, de próbáltam már mindenféleképpen, csillaggal az üres helyett, vagy 0-val.

1185264067_Kpernykp2023-03-17230325.thumb.jpg.51a30a1cf8053d70b6d5e44cd6030530.jpg

De mindig ez az eredmény:

148623300_Nvtelen.thumb.jpg.f94650a35c8d103e734d1d95b4015c40.jpg

Ez most egy ilyen program hiba, vagy nálam rossz, vagy én rontok el valamit.

Amúgy akinek működik esetleg, a LOCAL IP-t is lehet üresen vagy csillagosan hagyni, mert nekem annyi kellene, hogy legyen egy port ami nyitva van, mivel ipv6-ról beszélünk az IP úgyis ismert, biztonságosabb ha csak egy ip-re jöhetnek be, de mivel a prefix változik, így nincs jelentősége.

Köszönöm előre is a válaszokat

Szerkesztve ekkor: Szerkesztő: Korcsi
Link kommenthez
Megosztás más oldalakon

Csatlakozz a közösséghez!

Posztolhatsz regisztráció előtt is. Ha már van regisztrációd, jelentkezz be itt.

Vendég
Válaszolj a kérdésre...

×   Formázással együtt illesztetted be a tartalmat.   Formázás eltávolítása

  Only 75 emoji are allowed.

×   A linkedet automatikusan beágyaztuk.   Linkként mutatás

×   Az előző tartalmat tároltuk. .   Itt törölhetsz

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Új...