IPv6-on is kell portnyitás?

Hálózati eszközök

Sziasztok!

Az olyan szoftverekhez, mint  online gaming, P2P letöltések, Skype stb. IPv6 esetében is kézzel kell portokat nyitogatni? Tehát kell egy fix (belső)  IPv6 cím és meg kell nyitnom a tűzfalon a szükséges portokat, amiket használni szeretnék?  Alapból minden port zárva van IPv6-nál?

( uid_6201 v | 2023. 06. 16., p – 11:19 )

Otthoni tűzfal úgy van frankón beállítva normális esetben, hogy csak arra engedjen befelé a LAN-os cuccok felé forgalmat, amire előbb bentről ment kérés.
P2P és hasonló portokat viszont ki kell nyitnod azért, hogy a partner úgy tudjon csatlakozni hogy még te nem kezdeményeztél felé csatlakozést.

( _ventura_ v | 2023. 06. 16., p – 11:19 )

Mint ahogy IPv4 nél is, ez konfiguráció kérdése.

Fedora 38, Thinkpad x280

( theadam | 2023. 06. 16., p – 11:29 )

Szia!

 

Szó szerinti portnyitás igen, kell, ha normális tűzfal van közted és a világháló közt.

 

Kicsit bővebben: Az IPv4 címek fogyása miatt bevett gyakorlat, hogy előfizetésenként jellemzően egy IP-címet adnak és egy router irányítja és NAT-olja a forgalmat a belső hálózat és a világháló közt. A klasszikus portnyitás tulajdonképp egy DSTNAT, azaz a router IP-jén a 80-as portra érkező forgalmat meg kell adni kézzel, hogy hová akarod irányítani, melyik belső hosztra. A visszafele vezető utat, ill. a gépről kezdeményezett dolgokat pedig intézi a gép, router és túloldal.

 

IPv6 esetében nincs címhiány és címfordítás (bár lehet NAT-olni, csak az esetek zömében nincs értelmezhető haszna), csak routing van. Emiatt egy alap, tűzfal nélküli környezetben minden port ki van nyitva. Viszont a biztonság érdekében, amit IPv4-nél kieröltetett a NAT, v6-on is érdemes védeni a belső hálózatot, azaz szelektálni, milyen új kapcsolatok jöhetnek be és hová. Emiatt mindent tiltani és azt engedni, ami tényleg fontos. Meg ami related,established. Ez viszont, mivel változik az eszközök címe jóval nehezebb feladat, egyrészt az itthon divatos prefixváltogatás miatt, másrészt, mert jellemzően a cím második része is változik (második 64 bit), pláne, ha RA-val (Router Advertisement, a DHCP-től kicsit eltérően működik) van megoldva (és az esetek 99%-ában így van). Emiatt csak címszavakban, a portnyitás lépései, ha van csomagszűrő (L3-L4) tűzfal ami teszi a dolgát:

- Kell egy fix suffix a klienseknek, HA EUI64-gyel RA-val generálódik, akkor a privacy extension-öket, változó MAC-címeket le kell tiltani

- A routerben le kell követni a változó prefixet és ezt az első 64 bitet a kliens második 64-ével összefűzni és erre nyitni a portot, pl. ha DIGI, Telekom, ahol a heti PPPoE bontások új prefixeket adnak.

- A routeres részt automatizálni.

Ha a tűzfal mindent átenged (ASUS routerek néhány éve még így tettek) nincs teendő, de ilyenkor védelem sincs.

Erre a feladatra a routerek szoftverei igen eltérő mértékben alkalmasak.

- MikroTik-en script-elni kell, erre már van is megoldás

- OpenWRT tudja by default, a tűzfalnak a része, suffix + zóna páros elég jól szűkít kliensre. A gyakorlatban is működik szépen.

- A so-ho (ASUS, TP-LINK) gyártóknak tudtommal semmiféle válasza nincs a problémára (de fixme ha tévedek).

 

Nagyon címszavakban foglaltam most csak össze, de talán a kérdésedre sikerült válaszolnom. Ha IPv4 szintű tűzfalat akarsz, portnyitással, alapvető hálózati ismeretek birtokában, az az IPv6 alapjainak elsajátítását igényli.

TheAdam

Így első látásra ez a dobodel/köpödki. Ez valami T-home-os szolgáltatói cucc? Csak kicsit gyanús a színe a menünek :D Bridge módba tenni esetleg és mögé tenni bármi értelmeset?

(Bár ha működik és nincs benned nagy kísértés ilyenekkel mókolni, még akár lehet érdemes megbarátkozni vele...)

Esetleg kijelölni valami porttartományt, amit tuti nem használ más a hálódon csak azok az appok és azt engedni a tűzfalon IP cím nélkül?

Bár nem tudom mennyire enged pl csak végződést megadni. 

Hátha a másik kolléga látott már ilyen felületet és tudja mit lehet, meg mit nem.

Nem ismerem az említett eszközt, de Sagemcom-mal nem sikerült még értékelhető hatást elérni. Jelenleg ott tartunk, hogy sikerült kiütni az IPv6 tűzfalat és a mögötte lévő ASUS router (Tomato firmmel) kér prefix-et, azon pedig - révén koaxon alig-alig (soha) nem változik a prefix - lehet konfigurálgatni a szabályokat, de igazából ez sem jó megoldás, bár közelít valami elfogadható felé. Optikán, PPPoE-vel nincs ezzel gond. Koaxon viszont az IPTV miatt 10-ből 7 esetben nem jöhet szóba a bridge...

 

( bennyh | 2023. 06. 16., p – 11:46 ) Permalink

Netmap-ra van már valami értékelhető leírás? A MikroTik doksiban pár hónapja nem találtam:D

A címvisszahívás jó (lenne), a gond vele, hogy pl. az MS Windows-on hajlamos beragadni az előző cím és hiába megy 0-ra a preferred és valid lifetime, csak azért is azt akarja használni. Megoldás a hálózati csatoló újraindítása, v6-nál nincs igazi release + renew:D

 

A v6-ot az IPv4-et leváltó tömegterméknek tervezték, de a fukarkodás (a DIGI csak /64-et ad /56 helyett, sok szerverszolgáltató meg egy szabvány szerinti /64-et is sajnál), a technikai bonyolítás és az, hogy az IT-evolúció elejének mondható IPv4-hez képest egy teljesen új címzés, mindezekkel szerintem beleverték a szöget a koporsójába, mert megy a vekengés a változó nem változó prefix-eken, van NAT-olás de ha az UlA tartományba NAT-olok akkor ilyen címmel nem fogja default route-ként kezelni sok OS (akkor sem, ha beállítom), változó prefix-nél abszolút ignorálva a preferred és valid lifetime-okat kihúzzák a régi tartományt (PPPoE netek változó IPv6-tal).

Mindezekkel együtt szerintem az IPv4 NAT-olás lesz az alap amit sose fog senki elengedni, az IPv6-ból a geekek játszótere lesz, mint megannyi újításból (pl. a Wi-Fi nevének átírása sem alap). Ezzel baj nem is lenne, csak mivel a legtöbb router quick setup-pal, simán bedugva csak az IPv4-et kezeli, ezért ha valaki átlagfelhasználókat akar elérni, nem fog tudni spórolni azon, hogy csak IPv6-tal teszi ezt. Vagy is nem igazán látom, hogy egy a hozzáértőknek érdekes újításon túl milyen hozzáfűzött reményt váltott be. Vannak előnyös protokollszintű dolgai, nem vitatom, de alapvetően az, hogy a v4-et hivatott leváltani, legalább is háttérbe szorítani, az nem igazán jött össze.

TheAdam

# NAT szabályok
/ipv6 firewall nat
# NETMAP, a LAN-pri /64-es tartomány a szolgáltató /64-es tartományára átírni, kimenő forgalom
add action=netmap chain=srcnat comment=IPV6SNAT connection-state="" \
    out-interface-list=WAN src-address-list=LAN-pri to-address=\
    2001:xxxx:xxxx:xxxx::/64
# NETMAP, a WAN irányból érkező csomagok címeit átírni a LAN-pri tartományra 
# Én a LAN-on a 2001:db8::-as tartományokat használok, 
# nem csak a példa kedvéért áll itt, ULA esetén a kliensek gyakran inkább IPv4-et használnak
add action=netmap chain=dstnat comment=IPV6DNAT connection-state="" \
    dst-address=2001:xxxx:xxxx:xxxx::/64 dst-address-list="" dst-address-type=\
    !local in-interface-list=WAN to-address=2001:db8:xxxx:xxxx::/64
# minden más LAN-ból (pl vendég wifi vagy VPN tartomány) érkező kimenő csomagra MASQUERADE, 
# ha nincs, elhagyható	
add action=masquerade chain=srcnat connection-state="" out-interface-list=WAN \
    src-address-list=Local-range to-address=::/64

# az SRCNAT szabályok publikus címtartományainak frissítése a DHCP klienssel
/ipv6 dhcp-client
add add-default-route=yes interface=WAN-PPPoE pool-name=ISP-pool request=\
    prefix script="/ipv6 firewall nat set to-address=[/ipv6 pool get value-nam\
    e=prefix ISP-pool] [find comment=\"IPV6SNAT\"];\r\
    \n/ipv6 firewall nat set dst-address=[/ipv6 pool get value-name=prefix ISP\
    -pool] [find comment=\"IPV6DNAT\"];\r\
    \n/ipv6 firewall connection remove [find];" use-peer-dns=no

# Mikrotik példakonfigjában ajánlott a "documentation" tartomány tíltása, ezt kapcsoljuk ki, ha használnánk a LAN-on, 
# esetleg csak kívülről tíltsuk
/ipv6 firewall address-list
add address=2001:db8::/32 comment="defconf: documentation" disabled=yes list=\
    bad_ipv6	
	
	
# a végső trükk, a szolgáltatótol kapott tartomány címét a router WAN lábára pakoltam a LAN-on meg a documentary tartományból

/ipv6 pool
add name=lan-pool prefix=2001:db8:xxxx:xxxx::/64 prefix-length=64
/ipv6 address
add address=::1 from-pool=lan-pool interface=LAN

add address=::1 advertise=no from-pool=ISP-pool interface=WAN

Én azt tudom megmutatni, ahogy én használom a netmap-ot, konstruktív javaslatokat szívesen elfogadok, ha láttok benne hibát vagy valami egyszerűsítési lehetőséget. Kimaradtak még tűzfalszabályok, de elvileg ezekkel már el lehet indulni IPv6 netmap irányába.

Amúgy lehet az IPv6-ot is NAT-olni, pl RouterOS-en megy a prefix translation (netmap szabálynál meg lehet adni a tartományt valamint elég csak a kimenő tűzfal szabályt frissítgetni, ha változna a szolgáltatói prefix, nem kell a klienseket b'zergálni, de már elvileg vissza tudja hívni a kliensektől az elévűlt prefixet valamelyik 7-es alverzió óta szkript nélkül is) 

Tudom, nem ajánlott a NAT, de én most ezzel kísérletezgetek :) olyan nagy bajokat nem vettem észre.

Az is megy, hogy az egyik alhálóból netmap, a többinél meg csak masquerade és akkor a fő alhálóból rendesen minden kliens külön címről látszik a többi alhálóból meg a router címéről, ha pl csak /64-et kapnánk.

Ezeket a /64-eket, meg /56-okat sosem értettem. Minek, mi a francnak nekem az egyetlen szottyadt szerverhoteles gépemre komplett /64?
Értem én, hogy "végtelen", de maximum annyira, mint amennyire az IPv4-re is azt mondták/gondolták évtizedekkel korábban. Éppen csak "kicsit" több, mint az összes IPv4 cím. Sokszor.... Minek, mi célból? Főleg minek, mikor ezt is ugyanúgy variálják, és változtatják, mint az IPv4-en DHCP-vel!? Hát bazz, akkor mit érek vele!? Ilyen alapon elég lenne egy /112 mindenkinek, de akkor az legalább tényleg legyen fix és állandó (legelső technikai leírásokban erről is volt szó, igaz azokban még azt írták, hogy NAT sem lesz).

( Nem, köszönöm nem kell levezetni és elmagyarázni, tudom miért... de attól még faszságnak tartom. Ugyanígy azt is, amikor meg egyetlen egy nyomorult IPv6 címet adnak a szerveremhez. Kenjék a hajukra, pusztulna meg ez ilyen is.... Miért kell nekünk mindig végletekben gondolkodni, miért nem létezik egy elfogadható és élhető középút? Az ember hülye, nem képes tanulni a saját hibáiból... :( )

Tudom, ne magyarázzam, de ott van pl a MAC cím alapú címzés (EUI), ott vannak az ideiglenes címek valamint olyat is olvastam, hogy a cím az egy nyílt kulcs lett volna (nem tudom, ez mennyire van használatban) Ezekhez kell a /64. /48 meg /56 meg azért van, hogy tovább tudd osztani /64-es alhálókra otthon is, ami szerintem is már túlzás, ha nem céges a kliens.

Meg ugye most már arra is fel vannak készülve, ha még a zoknidnak is kell IP cím.

 hogy tovább tudd osztani /64-es alhálókra otthon is, ami szerintem is már túlzás, ha nem céges a kliens.

Pont a minap szembesültem vele, hogy ez jó dolog, és van gyakorlati haszna. Itt a fórumon többször feljött a téma, hogy a wifi router hatókörét, legegyszerűbben egy másik wifi routerrel lehet megoldani. IPv4 nél ez dupla NAT, viszont IPv6 nál nem. 

Én otthonra /60 at kapok, ekkor a második router már az elsőtől /62 kapott így ott is lett rögtön élő v6. Szóval jól ki van ez találva ...

Fedora 38, Thinkpad x280

Vidéki ISP ...

Máshol most mi van nem tudom, azt tudom hogy 1x éve ADSL korban teszt időszak alatt  a telekom /56 adott, és azt is fixen. Utána mikor véget ért a tesztidőszak már nem is adott mindenhova, és ha jól tudom már nem is fix ...

Fedora 38, Thinkpad x280

Nekem csak annyi, hogy a DHCP-nél tudsz intervallumokat kiosztani, esetleg fix IP-t adni (ha a MAC állandó) illetve látod egy közös LAN/WLAN listában, hogy milyen eszközök kértek, kaptak IP címet a hálózaton.  Ha az Androidnak nem lenne ez a hülyesége, akkor a SLAAC -ot le is tiltanám. 

( dorsy v | 2023. 06. 16., p – 22:48 )

Szerkesztve: 2023. 06. 16., p – 22:49

Ha van a vegeszkozodon FW, abban biztosan.
Egyebkent a routinggal tudod megfogni/atengedni. (mar felteve, hogy nem ipv6 nat van, de az lamasag :D)
Hogy ezt a szolgaltato eszkozen hogy tudod megtenni, arra nyiss nekik egy ticketet, biztos megmondjak. Vagy van valami doksi/FAQ-juk rola.